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.
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.
Solution
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.
When to use
- The agent must authenticate to real services with passwords, MFA, or session cookies.
- Web automation requires typing credentials into forms or clearing emailed/SMS one-time codes.
- The agent needs a stable, governed identity whose access can be scoped, rotated, and revoked.
- Credentials must stay out of the prompt, traces, and the model provider's infrastructure.
Open the full interactive page →
Diagram, neighbourhood map, code examples, related patterns and full provenance.