How do I keep secrets out of an agent's context?

An agent that holds a real password or API key can leak it in a prompt, a log, or a hallucinated tool call. Enforgate's secrets vault lets an agent reference a secret by name and never see the value, and short-lived session tokens limit how long and how widely a credential can be used.

The secrets vault

On Connected Tools → Secrets (/dashboard/secrets), store a named secret once: an API key, a database password, anything a downstream tool call needs. The value is encrypted at rest (AES-256-GCM) and never shown again after creation.

In a tool call's arguments, reference it with a placeholder instead of the real value:

{ "connectionString": "{{secret:prod-db-password}}" }

The gateway expands {{secret:name}} to the real value after hashing the original arguments for the audit log, and just before forwarding the call to the upstream tool. The agent only ever sees the placeholder string it sent; the plaintext value is never logged, never hashed into the audit trail, and never returned in any response.

Grants: a secret does nothing until you allow a key to use it

Creating a secret does not expose it to anything. Each API key needs an explicit grantbefore its calls can reference that secret. Manage grants from the key's detail drawer on /dashboard/keys. This is a fail-closed design: if a call contains a {{secret:name}} reference and the calling key has no grant for that name, the gateway blocks the call rather than forwarding the literal placeholder text.

Rotating a secret's value keeps the same name and grants, so agents referencing it by name keep working without a config change on their end.

Session tokens: short-lived, scoped credentials

A long-lived API key (bwb_...) is meant to live in your server environment, not in an agent's working memory for an entire conversation. From a key's detail drawer, mint a session token (bws_...) instead:

Time-boxed. Set a lifetime from 1 minute up to 24 hours; it stops working the moment it expires, no revocation step needed.
Optionally scoped. Restrict it to a list of tool-name globs (for example db_query or github__*) so the token can do less than the parent key, never more.
Independently revocable. The Sessions page (/dashboard/sessions) lists every active session across your keys; revoking one blocks it immediately without touching the parent key or any other session.

The practical pattern: hand an agent a session token scoped to just the tools it needs for the task at hand, sized to how long the task should take. If the token leaks, the blast radius is small and time-limited, unlike a permanent key.

How this fits with policies and approvals

Secrets and session tokens narrow what an agent can hold; policies and approvals govern what it's allowed to do. They're independent layers: a session token still goes through the full policy evaluation on every call, and a require_approval verdict on a secret-bearing call still holds for a human decision before the secret is ever expanded. See writing policies and setting up approvals.