Machine Identity and API Security for Agentic Systems

Material update: 2 September 2026

An agent should not inherit a user's broad authority or operate behind a shared, static API key. Every runtime that performs work needs a short-lived identity of its own, while every delegated action needs a separate authorization decision that accounts for the initiator, the executing workload, the target resource and the purpose. Without that separation, an organisation may know that “the agent made the call” but cannot reliably establish who empowered it, how far that authority extended or where a chain of tool calls should have stopped.

RFC 9700, published in January 2025, and the 25 November 2025 MCP authorization specification now provide useful protocol foundations: restrict token privileges, bind tokens to the intended resource, reduce replay risk and do not pass unrelated tokens downstream. Those controls are necessary, but they are not an operating model. The harder decisions concern identity inventory, delegation boundaries and the ability to stop an unsafe action quickly.

Inventory actors before selecting a secrets platform

Start by separating four roles: the human or system initiating an objective, the client application, the agent constructing a plan and the workload making an API call. A single conversation can start several processes, functions and tools. Each is a technical actor. A service account called ai-agent-prod collapses those boundaries and soon becomes a general-purpose pass into unrelated systems.

The machine identity register should name a business and technical owner, environment, permitted resources, credential issuance method, maximum lifetime and shutdown procedure. It should include cloud service accounts, certificates, OAuth clients, API keys, CI/CD robots, SaaS integrations and local tool servers. For every entry, an operator should be able to tell whether it is still used and which deployment created it.

Useful measures include the percentage of active identities with a named owner, the number of orphaned identities, the age of static secrets and the interval between workload retirement and access removal. Key rotation alone does not fix an identity with no owner or excessive privileges.

Issue identity to the running workload

A secret embedded in a container image, environment variable or repository proves only who has learned the secret. It does not prove which process is presenting it now. A stronger pattern attests the runtime from properties of its execution environment and then issues a short-lived credential. The SPIFFE standard defines portable workload identifiers, SVID identity documents and a Workload API for dynamic environments without tying the identity model to one cloud provider.

Implementation still requires explicit trust-domain boundaries, workload registration rules and authoritative attestation attributes. A pod or machine name is inadequate if an attacker can recreate it. Policy should bind an identity to a controlled deployment, runtime account and environment. Certificates or tokens should renew automatically; applications should not receive a durable private key to copy and retain.

Prioritise migration for agents that can read sensitive data or change state. A legacy API key may remain as a transitional control, but give it one owner, the narrowest practical scope, network constraints, monitored use and a removal date. A “temporary” credential without an exit condition normally becomes a permanent dependency.

Separate authentication, authorization and business approval

A valid credential answers who is calling. It does not decide whether that actor may perform this operation. The authorization layer should evaluate at least the workload identity, initiating user or system, target resource, requested operation, environment and delegation context. NIST SP 800-207 treats authentication and authorization as discrete functions performed before access to an enterprise resource; being on an internal network is not a basis for implicit trust.

An OAuth scope called write is too coarse to decide whether an agent may change a supplier's payout account. The API must still enforce object, function and workflow rules: which record the actor can reach, which fields it can change and whether the action needs additional approval. Permission to analyse a document should never be interpreted by the agent as permission to release a payment.

Create a deliberate approval point for irreversible or high-impact operations. The confirmation should identify the target, the proposed change and expected effect. Bind consent to one operation identifier and make it expire. Approval of a broad plan must not become an indefinite power of attorney.

Bind each token to its recipient and delegation

A token for server A must not work at server B. The client identifies the intended resource; the API validates audience, issuer, lifetime and required privilege. The MCP authorization specification requires resource indicators and forbids servers from accepting or transiting tokens intended for other resources. That is a critical boundary when an agent discovers tools dynamically.

When an agent calls a service for a user, do not forward the user's original token unchanged. Exchange it under policy for a credential with a narrower audience, scope and lifetime. Preserve both the executing actor and the delegating party in the audit record; otherwise every downstream event appears to be an autonomous act by the agent.

RFC 9700 recommends sender-constrained access tokens through mechanisms such as mutual TLS or DPoP to reduce the value of a stolen token. The suitable mechanism depends on client and infrastructure capabilities, but the choice should be explicit. At minimum, negative tests should cover the wrong audience, an expired token, insufficient privileges and replay from another runtime.

Protect APIs from an authenticated mistake

An agent can authenticate correctly and still send a dangerous request because it misunderstood an instruction or treated hostile content as a command. API enforcement cannot end at token validation. Use strict input schemas, size and rate limits, idempotency keys for retries, field allow-lists, workflow-state validation and safe defaults.

Separate read, simulate, prepare and execute operations. The agent can first obtain a preview, then apply the change through a distinct call only after policy requirements are satisfied. Where a tool offers broad capabilities, expose narrow domain operations instead of a generic execute endpoint or shell access. This limits both model error and deliberate abuse of an integration.

Measure the proportion of state-changing calls protected by object and workflow checks, idempotency coverage and denials by reason. A rise in rejected calls after a prompt or model change is evidence of a regression to investigate, not a reason to weaken the policy.

Build revocation and investigation into the first release

Incident responders must be able to stop one agent, operation type, tool or delegation class without disabling the whole platform. The emergency path should still work when the primary administration console or identity provider is partly unavailable. Exercise credential revocation, policy rollback and restart with minimum authority as operational procedures rather than documentation-only scenarios.

An audit trail should connect the user request, agent session, plan or task, workload identity, policy decision and API call. Do not retain complete tokens, prompts or sensitive data merely because they might be useful later. Define redaction, retention and evidence access. Events such as scope elevation, audience change, repeated denial or use after a deployment was retired should create an operational signal.

The strongest outcome measures are revocation time after a decision, the share of calls with a complete audit chain, the number of live static secrets and the percentage of wrong-audience attempts stopped at the first boundary. They show whether the system contains failure, rather than merely describing itself as zero trust.

Sources

• NIST SP 800-207: Zero Trust Architecture — 10 August 2020
• IETF RFC 9700: Best Current Practice for OAuth 2.0 Security — January 2025
• IETF RFC 9728: OAuth 2.0 Protected Resource Metadata — April 2025
• SPIFFE Standard — current version, accessed 2 September 2026
• Model Context Protocol: Authorization — 25 November 2025 revision