# Eve Safety, Governance, and Privacy

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.

```mermaid
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:

1. emergency shutdown, legal hold, tenant isolation, and hard authorization;
2. crisis, child safety, abuse, and prohibited-content policy;
3. privacy, consent, retention, and data-rights enforcement;
4. tool grants, confirmation, budget, and rate limits;
5. grounding and factual-support requirements;
6. 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](../../features/lilith-persona-policy.md).

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](../../../WALKTHROUGH/journeys/crisis-aware-tone-policy.md).

## 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](./memory-grounding-and-continuity.md).

## Privacy and consent

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.

## Related

- [Trust, safety, and privacy architecture](../../architecture/trust-safety-and-privacy.md)
- [Privacy, consent, and portability](../../features/privacy-consent-portability.md)
- [Review, trust, and safety](../../features/review-trust-safety.md)
- [Lilith Persona Policy](../../features/lilith-persona-policy.md)
- [Models, quality, and evaluation](./models-quality-and-evaluation.md)