Safety & Secrets

Some rules are not tunable. They hold regardless of your run policy, and each ships with a test that asserts it refuses.

Hard floors

• Secrets & PII are redacted before any Jev or LLM call; the generative model never picks a real recipient for a real send.
• Prompt-injection guard is always on — page text is untrusted data, never instructions.
• Every autonomous run is bounded by max-steps and budget — never unbounded.
• Every executed step is recorded and auditable — even a full-autonomous run is replayable and reviewable after the fact.
• Pacing is realism and politeness, never detection-evasion.

The secret invariant

A secret has exactly one permitted path:

external password manager (fetched on demand)
  → the browser input
    → the target site's own auth call

It is never placed in a model prompt, never persisted in a Journey, recording, or log, and never in any outbound request except the target's own auth call. It is origin-bound — a secret can never be typed into a different origin or an injected/redirected field. Nothing is stored at rest; Jevitate holds only a manager reference.

How the secret is supplied is configurable via SecretPolicy.secretMode:

The containment and origin-binding above are not tunable — only how the secret is supplied.

Fail-fast invariants

These are permanent, named contracts — each with an "asserts-it-refuses" test:

• No policy → throw. A missing or partial RunPolicy raises rather than defaulting permissively.
• Secret never serialized. Serializing or logging a secret throws; only a reference may be stored.
• Origin mismatch → refuse. Before any fill, current origin must match the secret's bound origin.
• Unknown journey/param → reject. Only published ids and schema-valid params run — no inline steps, ever.
• Resume only on postcondition. Handback and self-heal resume require a passing check; timeout fails closed.
• Writes never auto-heal. Write, irreversible, and real-send steps fail closed for human-approved repair.

Safety boundaries

Jevitate assumes you're testing systems you're authorized to test. It supports domain allowlists, route exclusions, and destructive-action protection — potentially destructive actions require explicit configuration before they can execute:

blocked_actions:
  - real_payment
  - account_deletion
  - send_real_email
  - modify_real_user_accounts
allowed_domains:
  - localhost