VIII · Safety & ControlEmerging★

Agent Credential Vault

Broker the agent's credentials at action time through a managed vault of passwords, MFA secrets, and digital personas, so secrets never enter the prompt or context and the agent authenticates as a governed identity.

Context

An agent automates work that requires authenticating to real services: logging into websites, filling sign-in forms, completing 2FA challenges, or signing up under an identity. The agent is driven by a model whose context is logged, traced, and sent to a third-party provider, and the same agent may face hostile inputs from the pages it operates. The credentials it needs are high-value: passwords, TOTP seeds, email and phone identities used for verification.

Problem

If the agent is handed raw passwords, MFA seeds, or persona details in its prompt, those secrets land in the model context and from there in chat logs, trace exports, eval datasets, and the provider's infrastructure, where rotation cannot recall the copies already scattered. A prompt injection on an operated page can also coax the model into disclosing whatever credentials it can see. A reference-only scheme (a typed token the runtime resolves) handles API tokens but not the messy reality of web automation: a login form needs a username and password typed into fields, a verification step needs a one-time code read from an email or SMS the agent controls, and a sign-up needs a coherent identity. Without a runtime that supplies all of this without ever exposing the values to the model, every authenticated action is a leak waiting to happen and the agent has no stable, attributable identity.

Forces

  • Web login and 2FA need concrete credential values delivered to fields and challenges, not just an API token reference.
  • Any secret the model can read can be logged, traced, or extracted by injection.
  • A vault that injects below the model adds a trusted component that must itself be hardened and audited.
  • Personas and stored credentials raise policy and consent questions about who the agent is acting as.

Example

A web agent must log into a SaaS dashboard, clear an emailed 2FA code, and export a report. Instead of receiving the password in its prompt, the agent calls the vault by reference for that site; the vault types the stored password into the login form, derives or fetches the one-time code from the persona's mailbox, submits it, and hands back only a session handle. The password and the code never appear in the model context, the trace, or any tool argument the model can read, and the login is logged against the agent's governed identity.

Diagram

Solution

Therefore:

Run a credential vault as a trusted runtime component the agent invokes by reference. The vault stores per-site passwords, TOTP/MFA seeds, session cookies, and digital personas (email, phone, identity attributes) bound to a governed agent identity. When the agent reaches an authenticated step, it names the credential or persona it needs; the vault injects the value directly into the target — typing into a login form, deriving the current TOTP code, reading and submitting a one-time code sent to the persona's mailbox, or attaching the session — without surfacing the value in the model context or tool arguments the model can read. The agent authenticates as an identity the vault governs, so access can be granted, scoped, rotated, and revoked centrally, and each use is logged against that identity. The vault integrates with existing identity providers (Cognito, Okta, Entra ID, Auth0) for the agent's own identity and for issuing or holding the credentials it brokers.

What this pattern forbids. Secrets must never enter the prompt or model context; the agent may reference a credential or persona by handle but cannot read raw passwords, MFA seeds, or persona secrets, which the vault injects at action time under a governed, revocable identity.

And the patterns that stand alongside it, or against it —

  • complementsSecrets Handling★— Ensure the model never receives secrets in plaintext; tools resolve credentials from references at runtime.
  • complementsDelegated Agent Authorization★— Have an agent act for a principal using scoped, short-lived, revocable delegated credentials rather than the principal's own static secrets, so each action stays attributable across the principal-to-agent-to-subagent chain and a compromise is contained.
  • complementsSession-Scoped Payment Authorization·— Bound an agent's autonomous spending by having it open a payment session with a pre-approved cap, stream many micropayments inside that session, and settle once on close, instead of seeking approval for every transaction.

Neighbourhood

Click any neighbour to follow the language. Scroll to zoom, drag to pan.

Used in frameworks

References

Provenance