Secrets

Secrets are encrypted, tenant-scoped values — API keys, tokens, passwords — that your agents reference indirectly through {{secret.KEY}} placeholders instead of pasting the raw value into a tool configuration.

The plaintext is encrypted at rest the moment you save it, is never returned by any read endpoint (only metadata flows out), and is decrypted only at the instant a tool call needs it — and only for agents you have explicitly granted. Manage them from the Secrets page in the dashboard.

Creating a secret

A secret has a stable key, a value, an optional description, and a sensitivity tier.

Referencing a secret: the {{secret.KEY}} placeholder

Put {{secret.KEY}} anywhere a tool parameter accepts a value — for example a header Authorization: Bearer {{secret.STRIPE_API_KEY}}. At execution time the resolver swaps the placeholder for the decrypted value just before the call is dispatched; the plaintext never enters the agent definition, the conversation, or the logs.

Where resolution works

Secret resolution runs across every tool kind:

Secret values are scrubbed from tool output, too

Resolution protects the outbound path — the plaintext never reaches the model in a prompt or tool call. Fruxon also protects the return path: an output sanitizer scrubs any resolved secret value out of tool responses and error messages before they re-enter the model's context. So a tool that echoes its own credential, or an error string that quotes it, can't leak the secret back to the LLM.

This runs automatically on every tool result — there's nothing to configure — and it applies to every resolved secret regardless of its sensitivity tier.

Revisions: rotate, publish, and roll back

Every secret keeps an append-only revision history. The value you see in use is the published revision.

• Rotate / publish a new value to create a new revision and make it the published one. The previous revisions stay in history.
• Roll back to point the published pointer at an earlier revision — useful if a rotation broke something.

Because the key is stable across revisions, rotating or rolling back never requires touching the agents that reference it.

Granting secrets to agents

A secret is not readable by every agent in the tenant. The resolver consults a per-agent grant list before it will substitute a secret into any tool call:

• Grant an agent to allow it to reference the secret.
• Revoke to remove that permission. After a revoke, {{secret.KEY}} in that agent's tools stops resolving.

Browse a secret's grants to answer "who can decrypt this?" at a glance.

Per-step allowlist

On top of the per-agent grant, an individual agent step can carry a tighter allowlist, so a chatty step only reaches the credentials it actually needs. The resolver enforces grant ∩ allowlist:

• null (no allowlist on the step) — falls back to grant-only behavior (legacy steps).
• a set of keys — only those keys resolve, and only if the agent is also granted them.
• empty — denies every secret for that step.

When a step has a non-empty allowlist, the legal placeholders are surfaced to the model through an <available_secrets> system footer that lists each allowed {{secret.KEY}} and its description, so the model can choose the right one.

Sensitivity tiers

Each secret carries a sensitivity tier that drives the per-operation audit policy. Tiers are ordered by stringency; a credential subject to multiple regimes is tagged its strictest applicable label.

STANDARD uses best-effort audit logging; PHI, FINANCIAL, and REGULATED use fail-closed audit writes. You can upgrade a secret's tier at any time, but downgrades are rejected so audit policy is never silently relaxed on a key that already saw stricter handling.

Managing secrets via the API

Secrets are managed through the Secrets API — create, update, soft-delete, rotate (:publish), roll back, inspect revision history, and manage per-agent grants. Read endpoints return metadata only, never the plaintext.