Eve Safety, Governance, and Privacy — Oshun Platform

Eve's trust model is layered: identity and tenant authorization, persona and crisis policy, task/tool grants, confirmation for side effects, budget and kill switches, evidence disclosures, memory consent, audit, and data rights. No single model prompt is the security boundary.

stateDiagram-v2 [*] --> Received Received --> Denied: identity tenant or release boundary fails Received --> SafetyReview: authenticated and in scope SafetyReview --> CrisisResponse: crisis policy supersedes ordinary task SafetyReview --> Refused: abuse prohibited content or privacy boundary SafetyReview --> CapabilityCheck: ordinary safe request CapabilityCheck --> ReadOnly: scoped read capability CapabilityCheck --> AwaitingConfirmation: governed side effect CapabilityCheck --> Refused: grant budget quota or rights fails AwaitingConfirmation --> Executing: exact scope confirmed and reauthorized AwaitingConfirmation --> Cancelled ReadOnly --> GroundingCheck Executing --> GroundingCheck GroundingCheck --> Disclosed: evidence and support posture valid GroundingCheck --> Withheld: required grounding absent CrisisResponse --> Disclosed Disclosed --> Audited Denied --> Audited Refused --> Audited Cancelled --> Audited Withheld --> Audited Audited --> [*]

The more protective boundary wins. Confirmation cannot override authorization, grounding cannot override privacy, and persona style cannot override crisis or tenant policy.

Policy order#

When rules conflict, the runtime applies the more protective boundary. A useful ordering is:

emergency shutdown, legal hold, tenant isolation, and hard authorization;
crisis, child safety, abuse, and prohibited-content policy;
privacy, consent, retention, and data-rights enforcement;
tool grants, confirmation, budget, and rate limits;
grounding and factual-support requirements;
persona/tone preferences and ordinary task completion.

Persona style never weakens crisis handling, consent, tenant isolation, or tool authorization. Safety supersession should be observable and testable without exposing sensitive policy internals to an unauthorized actor.

Lilith policy envelope#

The shared assistant path uses the Lilith policy substrate for tone bands, teacher behavior, crisis-aware response, voice abuse, spiritual-domain boundaries, cultural and lineage sensitivity, unsafe claims, tenant overrides, and versioned release policy. The canonical specification and test invariants are in Lilith Persona Policy.

Builder-facing Eve is more direct and operational than member-facing Lilith, but she does not bypass that substrate where the same risk is present. An operator request involving member safety, persona release, content rights, or sensitive memory still goes through the applicable policy and authorization.

Crisis-aware behavior#

Crisis detection runs before ordinary tools and generation. The crisis path can replace persona style, suppress unsafe tools, present location-appropriate help, and record the policy decision. It must not claim clinical diagnosis, guarantee outcomes, or continue a tour/action as though nothing happened.

Recovery is a journey, not one refusal string: immediate response, safe resource presentation, interruption of incompatible actions, user-controlled continuation, and appropriately restricted audit. The customer behavior is covered by Crisis-aware tone policy.

Capability grants and least authority#

The task-family router narrows the model-facing toolset, while the server independently checks actor, tenant, role, resource, and operation. A client-side permittedToolGrants field is useful context but not authorization.

Grant design should specify:

operation and resource pattern;
actor/role and tenant;
read versus propose versus execute;
expiry and revocation;
required consent or policy bundle;
idempotency and replay behavior;
audit event and redaction class.

Unknown or expired grants fail closed. Broad “admin” or “assistant” authority is not a substitute for operation-level policy.

Human confirmation and side effects#

Member-side actions follow their domain contract; material builder mutations use confirmation cards or the accepted-work lease protocol. Confirmation must be tied to authoritative pending data, not merely to displayed prose. Approval checks the current version, actor, tenant, and policy again to prevent stale or cross-context execution.

High-impact operations may also require separation of duties, dual control, review queues, cooling-off periods, or irreversible-action warnings. Eve can prepare and explain these actions; she does not remove their governance.

Budget, quota, and kill switches#

Budgets apply to model calls, provider tools, generation, and agent execution. The runtime enforces per-turn/per-run ceilings, tenant or workspace quotas, provider availability, and global or capability kill switches. A budget failure returns a stable reason and recovery path; it must not silently downscope an operation in a way that changes its meaning.

Kill switches should be independently operable from the model path, fast to propagate, and represented in telemetry. Recovery requires explicit re-enable and validation rather than assuming that a restarted process clears the state.

Grounding and disclosure#

Eve discloses when an answer is grounded, partially supported, ungrounded, provider-degraded, tool-derived, or a proposal awaiting confirmation. The UI must not collapse those states into a generic confidence badge.

Required disclosures include the active persona, memory posture, material tool use, confirmation status, safety supersession where appropriate, and known evidence limitations. See Memory, grounding, and continuity.

Conversation history, page context, memory, voice media/transcripts, feedback, telemetry, and tool receipts are distinct data classes. Each is minimized, retained, exported, and erased by its own contract. Sensitive page or selection content must not be copied into durable memory or observability payloads merely because it was available during a turn.

Voice requires clear recording/listening state, purpose, provider boundary, retention, and consent. Persona voice cloning has additional consent and rights requirements in the Lilith policy and V3 rights documentation.

Audit and non-repudiation#

Material actions record the actor, tenant/workspace, request/intent identifier, policy and tool version, proposed arguments, approval or lease, result receipt, and error/retry state. Logs redact secrets and protected content while retaining enough structure to investigate authorization, routing, and execution.

The assistant's natural-language response is not the audit record. The audit record is the typed, append-safe event/receipt produced by the authoritative service.

Abuse and adversarial cases#

Release coverage should include prompt injection in page/retrieved content, cross-tenant identifiers, hidden or stale DOM text, tool-description injection, argument smuggling, confirmation replay, memory poisoning, false citation, persona jailbreak, crisis-evasion language, cost exhaustion, and attempts to make the coding agent self-verify.

The model may help detect these cases; deterministic policy, schemas, authorization, and independent verification remain the enforcement.