Agent-scoped credentials

An agent-scoped credential lets one registered AI agent use an approved upstream identity. The credential binding names that agent with an immutable agentSubject, limits where the credential can be used, and keeps the secret outside the MCP client.

Use this mode when the organization needs to answer:

• Which agent used the upstream credential?
• Which tools, servers, and environments could it access?
• Can security revoke that agent without disrupting other agents?

The problem with a shared service account

Suppose five AI agents access Salesforce through one MCP server. If every agent uses the same service account, Salesforce sees one upstream identity. The gateway can still apply policy, but the shared credential creates a large revocation boundary and weakens agent-level accountability.

An agent-scoped binding narrows that boundary. The customer registers and approves an agent, then binds a credential reference to that agent. A different agent cannot resolve the binding.

Four identities in one request

These identities have separate jobs:

Identity	Example	What it tells the gateway
Human	Alice	Who initiated or delegated the work, when present.
Agent	Contract Review Agent	Which approved AI agent is acting.
Client surface	Claude Code, Cursor, or a custom MCP client	Where the request entered. The client is not automatically the agent.
Upstream identity	Salesforce integration identity	What the upstream service receives.

The signed runtime identity can carry an agent ID, an optional agent instance ID, and an optional human delegator. The gateway keeps these identities distinct in policy and audit.

↗ Expand

The gateway is the credential boundary. The MCP client carries identity and intent, but never receives the upstream secret.

− 100% +

Close ×

The gateway is the credential boundary. The MCP client carries identity and intent, but never receives the upstream secret.

What the customer configures

1. Register the agent. Record its owner, purpose, allowed environments, client surfaces, credential mode, and any instance rules.
2. Approve the agent. Security reviews the operating boundary before the agent becomes eligible for a binding.
3. Create the credential binding. Select agent_scoped, choose the approved agent, reference the customer secret manager, and select the permitted MCP servers or API operations.
4. Attach policy. Policy still decides whether this agent may discover and call each tool in the current context.
5. Activate the binding. Activation produces an approved runtime projection. Data planes do not infer access from an unapproved control-plane draft.

See Create a credential binding for the UI, API, and CLI workflow.

What happens during a tool call

The authorization server signs the runtime identity before the request reaches the data plane. A normal tool call does not require the MCP client to open an interactive login for every invocation.

During the call, the data plane:

1. Verifies the token signature, issuer, audience, time bounds, and signed actor claims.
2. Resolves the registered agent and optional agent instance.
3. Evaluates policy for the agent, human delegator, client surface, environment, server, and tool.
4. Matches the binding’s agentSubject exactly.
5. Resolves the referenced upstream credential through the credential broker.
6. Injects the credential into the approved upstream request.
7. Returns the tool result and emits metadata-only audit.

↗ Expand

Credential resolution happens inside the gateway. The client receives the tool result, not the upstream credential.

− 100% +

Close ×

Credential resolution happens inside the gateway. The client receives the tool result, not the upstream credential.

Agent scoped does not mean one new token per call

The credential mechanism depends on the binding and upstream provider. The gateway may resolve a secret-manager reference, exchange a token, or use another supported credential type. The stable guarantee is ownership: only the matching approved agent can resolve the binding.

How the modes differ

Credential mode	Upstream identity represents	Use it when
service_account	A shared application or integration	Agent-level credential ownership is not required.
user_delegated	The signed-in person	The upstream action must use the person’s delegated authority.
agent_scoped	One registered agent	The agent needs an independent credential and revocation boundary.
workload_mapped	A registered runtime workload	Infrastructure identity, rather than a human or agent, owns access.

An agent can still act for a human. In that case, policy and audit retain both identities. The human delegation does not change ownership of an agent_scoped binding. A person signing in without a signed agent identity uses user_delegated instead.

Enforcement outcomes

Condition	Result
Agent is approved and matches agentSubject	Continue to policy and credential resolution.
Agent claim is missing	Deny before credential resolution.
Agent is unknown, disabled, or revoked	Deny before the upstream call.
Agent is approved for another environment	Deny the binding activation or runtime request.
Required agent instance is missing or not allowed	Deny before credential resolution.
Policy denies the tool or surface	Hide the tool from discovery or deny the call.

The gateway fails closed when identity, registry state, policy, or credential resolution is uncertain.

What appears in audit

Audit records safe metadata needed for investigation:

• authenticated human or service principal;
• agent ID and agent instance ID, when present;
• human delegator, when present;
• client surface and OAuth client ID;
• credential mode and binding ID;
• policy decision, reason code, server, tool, and upstream outcome.

Audit does not contain the secret, access token, private key, or raw credential material.

Revocation and incident response

If an agent is compromised, security can disable or revoke that agent. If only one upstream credential is affected, security can disable or revoke the binding. After the change reaches the runtime projection, new calls fail before credential resolution while unrelated agents and bindings continue operating.

This gives security a smaller incident boundary than a service account shared by every agent.

Customer example: contract review

A legal team registers contract_review_agent and binds it to a Salesforce credential stored in the customer’s Vault. Policy allows two tools:

• salesforce_read_account
• salesforce_create_case

The agent cannot use salesforce_delete_account. Another agent cannot reuse the credential binding. If security revokes contract_review_agent, its next governed call fails while other Salesforce agents continue using their own bindings.

Source truth

• Agent contract
• Authentication context contract
• Credential binding contract

Next

• Read Credential broker and modes for the complete mode model.
• Follow Create a credential binding to configure a binding.
• Read Agents for registration, discovery, and revocation.