Managing passwords and API keys for AI agents

A password pasted into an agent conversation often travels further than intended. It can end up in a saved transcript, a debugging trace or a handoff note. Putting it in a vault helps you control storage and access. You still need to decide what happens when the agent uses it.

Agent Loadout separates credential metadata from secret access. It also offers a local connector for configured actions that can run without returning the credential to the model. The right choice depends on the task.

Start with an inventory the agent can read

Give each credential a service name, an environment and an owner. “CRM staging API” tells the next developer more than “token-2”. Keep production and development credentials as separate items even when they belong to the same service.

A credential can belong to one agent, be shared with selected agents or be held by the organization. Explicit sharing is useful when two agents need the same integration. It also means that revoking one agent’s token does not rotate the shared provider key.

A client with vault:metadata can list credential names and IDs without retrieving their values. Start there. Many planning and troubleshooting tasks only need to know that an account exists.

Choose how a task receives authority

• Read the value: an authorized get_credential call returns the secret to the client. This needs vault:use and the credential must be shared with or owned by the agent and marked agent-readable.
• Use a configured action: the local connector applies the credential inside an approved API, command or browser profile. Its result does not include the password or session cookies.
• Get an authenticator code: get_totp_code returns a current TOTP code and its remaining lifetime. The stored seed stays in the vault.

The connector is useful for a known operation such as calling an API or signing into a configured site. It requires a paired machine and trusted profiles. It is not general autofill for every website an agent encounters.

A secret returned by a tool is visible to that tool’s client. Check your client’s transcript and logging behavior before granting reveal access. Asking the model not to repeat the value is a useful instruction but it is not a storage boundary.

Create an account with a generated password

When an agent is authorized to register a service account, it can create a vault item with a generated password. These are example MCP arguments for a test service:

{
  "name": "Issue tracker staging",
  "kind": "login",
  "username": "agent@your-inbox.example",
  "generate": true,
  "allowed_origins": ["https://tracker.example"]
}

Replace the address and origin with the service you intend to use. The create call returns generated_secret so the client can complete the form. Do not describe this flow as a password the model never sees. Creating and updating credentials requires vault:write; the MCP tools require metadata access too.

For an API key, create the key at the provider first with the smallest useful permissions. Store that value in an api_key item. Saving a key in Agent Loadout does not change the permissions the provider gave it.

Test access before trusting the setup

Connect a token with metadata access only. Confirm that listing works and a reveal fails. Then test the intended agent with a disposable credential. An unrelated agent should be unable to read it unless you have explicitly shared it.

The vault reference explains ownership and audit history. A reveal records who accessed which item. The audit record excludes the secret value. It tells you about access through Agent Loadout rather than everything the client later did with the value.

Rotate the actual credential

Rotation has two sides: the provider and the stored item. For an API key, create the replacement at the provider, update the vault item, verify the integration and revoke the old provider key. If the provider supports overlapping keys, use that window to avoid an outage.

Changing a password inside the vault does not change the password on the website. Complete the provider’s password-change flow as part of the same operation. Keep a recovery path for failures between the two updates.

When a task ends, revoke its Agent Loadout token if it no longer needs access. When a credential leaks, revoke or rotate the credential at its source. Those actions solve different problems.

For a client-specific walkthrough, use the Codex inbox and vault guide. It starts with metadata access so you can verify the connection before exposing a value.