Giving an agent credentials
An agent-identity agent needs its own credentials, and a userPassthrough agent needs
yours. Either way, OAP describes credentials as named, typed references — never a pile of secret
bytes the process inherits.
AgentIdentity — a named credential set
An AgentIdentity is the set of credentials an agent acts as: reusable, typed descriptors that toolkits and
MCP servers request by name. It carries references to Secrets, never the token bytes themselves — the actual
values are resolved at runtime, just-in-time, by the token broker.
Credential types
Each credential declares a type, and the type decides how it's stored and refreshed:
static— a fixed secret value (a key in a Secret): a PAT, an API key, a kubeconfig.oauth— an OAuth credential (access + refresh token, expiry, endpoints), proactively refreshed before it expires.federated— no stored token at all; minted on demand from the user's enterprise identity. Passthrough only. (See Enterprise managed auth.)githubApp— a short-lived installation token minted from a stored GitHub App private key. The agent-identity mirror offederated.
Guided setup flows
Getting a credential in place is a guided flow, not a raw secret paste. OAP ships curated flows for the common cases — creating a GitHub fine-grained PAT, capturing Claude Code's setup token, importing a kubeconfig, an OAuth + PKCE dance against an MCP server, minting a Tailscale auth key — each of which walks you through the provider's own UI and then verifies the credential is live before storing it. A credential that doesn't verify is shown back to you, not silently saved. For providers without a curated flow, an LLM-driven flow reads the provider's docs and guides you through.