At 9:12 on Monday morning, customers at a fictional retailer begin reporting failed orders.
The platform team has an AI operations agent connected to its support queue and cloud environment. An engineer gives it a short instruction:
Find why checkout is failing and fix the problem.
The agent reads the incident ticket, searches application logs, compares recent deployments and checks the health of the payment service. It finds an expired certificate, generates a replacement, updates the configuration and deploys the change.
Checkout recovers in twelve minutes. The team is impressed.
Then the security lead asks:
- Which identity changed production?
- Was the agent allowed to investigate, or also to deploy?
- Whose authority did it use?
- If it had changed the wrong certificate, could the team prove what happened?
The audit log has one answer: platform-automation-service.
That account is also used by deployment pipelines, maintenance scripts and two older automation tools. Its credential proves that an approved account made the call. It does not reveal which system chose the action, which person initiated the work, what outcome was approved or when that authority should have ended.
The agent fixed the outage. It also exposed an old architectural weakness: a credential had become a substitute for identity, authority and accountability.
Agents change the security question
Applications have always needed credentials. A service may use a token to call another service. A deployment pipeline may use a service account to update cloud resources. A scheduled job may use a certificate to read from a database.
These patterns are not automatically unsafe. The problem begins when one long-lived credential stands in for several actors and purposes.
Traditional automation is usually narrow. A pipeline follows code written in advance. A backup job runs a known sequence. An AI agent is less predictable: it receives a goal, examines its environment, selects tools and changes its next step according to what it finds.
The model may not be deterministic, but its tool calls have real consequences.
For a conventional script, we often ask:
Can this process call the API?
For an agent, that is only the first question. We must also ask:
Why is it calling the API, whose authority is it using, and is this action still inside the task that was approved?
An API key cannot answer those questions by itself.
A credential proves less than we think
A credential is evidence used during authentication. It may help a service prove which principal is making a request. It does not, by itself, explain why the request is allowed.
Five ideas need to remain separate:
- Identity: which actor is making the request.
- Authentication: how the system verifies that claim.
- Authorization: what the verified actor may do.
- Delegation: what one actor is permitted to do for another, for a stated purpose and period.
- Accountability: whether the organisation can reconstruct the request, decision, policy, action and result.
A valid token can prove that a request came from an authenticated principal. It cannot prove that the request matches the user’s current intent. An engineer may be allowed to deploy, but that does not mean every agent the engineer invokes should inherit the same power.
This is why “the agent is authenticated” is not a complete security conclusion.
One action can involve four identities
In the checkout incident, one cloud API call may involve at least four identities.
| Identity | What it represents | Question it answers |
|---|---|---|
| Human | The engineer who requested or approved the task | Who asked for this work? |
| Agent | The software choosing the next action | Which autonomous system selected it? |
| Workload | The process, container or pod making the call | Which deployed runtime sent it? |
| Target | The service or resource accepting the call | Which system executed it? |
These identities can overlap. A small internal agent with fixed behaviour may reasonably use an existing workload identity. But the model becomes harder to govern when agents are created dynamically, act for different users, call many tools or exist only for one task.
If a pipeline and an operations agent use the same principal, the audit trail cannot reliably distinguish predetermined automation from a model-directed decision. If twenty agents share one key, disabling a compromised agent may disrupt all twenty. If an agent uses a person’s token, its reach may silently expand to the person’s full access.
The point is not to create an identity merely to give the agent a name. The point is to make its access separable, containable and traceable.
The cloud market is moving in the same direction
During the past year, several platforms introduced controls that treat agents as visible actors rather than anonymous users of a shared secret.
Microsoft’s Entra Agent ID separates agent identities from human and conventional application identities. It supports access assigned directly to an agent and authority delegated by a user, while recording supported authentication as agent activity.
Google Cloud announced a SPIFFE-based Agent Identity with agent-aware IAM policies and gateway enforcement. As of 6 May 2026, the core runtime identity and IAM Allow and Deny support were generally available; several related gateway and contextual controls remained in preview or were planned.
AWS took a different route. Amazon Bedrock AgentCore became generally available in October 2025. AgentCore Policy reached general availability in March 2026 and evaluates gateway tool calls outside the agent’s reasoning loop. The managed AWS MCP Server also uses IAM controls and provides separate visibility into server activity.
The services differ, and their feature states will change. Their shared direction matters more than their product names:
Give the agent a distinguishable identity, limit its authority, and enforce policy before a proposed action becomes a real operation.
These services are useful building blocks. None removes the need to design what the agent is allowed to do for a particular task.
The harder problem is authority drift
Return to the incident. The engineer asks the agent to investigate checkout failures. The agent reads logs and discovers the expired certificate.
It then calls a certificate tool. That tool calls a deployment service. The deployment service asks another agent to validate the rollout. Every component may have a valid identity, and every call may be permitted by a broad access policy.
But where was the decision made that “investigate” included “replace a production certificate and deploy it”?
Authority can drift as work moves through tools, agents and services. Authentication remains valid while the connection between the original request and the eventual consequence becomes weaker.
This exposes the difference between access authorization and action authorization.
Access authorization asks:
May this agent call the deployment API?
Action authorization asks:
May this agent perform this deployment, on this resource, for this task, using authority that is still valid now?
A unique agent identity improves visibility and makes policy easier to apply. It does not close this gap on its own.
This is still an evolving area. NIST launched its AI Agent Standards Initiative in February 2026 and is researching agent authentication and identity infrastructure. Its National Cybersecurity Center of Excellence is separately exploring standards-based identity and authorization for access and actions taken by software and AI agents. As of this review, that work was still in progress rather than a settled architecture standard.
Put policy immediately before consequence
A prompt such as “never make a dangerous change without permission” may influence model behaviour. It is not an authorization control. The model interprets prompts; a separate system must enforce permissions.
The strongest control point is usually the boundary immediately before a consequential tool or API executes.
The safe flow has four gates:
- Identify the request. Record the person, agent, running workload, task, time and intended outcome.
- Bound the delegation. Give the agent only the resources, actions and duration required for that task.
- Decide outside the model. Evaluate the proposed target, action, environment, risk and approval rules in an external policy service.
- Execute and prove. Issue a short-lived credential for the approved operation, enforce policy again at execution, and record the result.
The important boundary is between proposal and execution:
The model can propose. It should not be able to approve its own proposal, mint its own authority or bypass the enforcement point.
Human approval must mean something
Adding an approval button can create false confidence. People approve too quickly when prompts are frequent, vague or difficult to understand.
“Allow agent to continue” is not an informed decision. A useful approval shows the actual consequence:
Replace certificate
payment-internalin production, deploy revisioncheckout-1842, monitor for ten minutes and roll back if payment errors cross the agreed threshold.
Approval should also be risk-based. An operations agent may read health metrics without interruption. It may restart a failed development workload under an approved runbook. A production certificate change, database permission update or deletion should cross a stronger boundary.
Some actions should remain prohibited even when a user requests them. An agent should not be able to grant itself permissions, disable its audit trail or rewrite the policy that evaluates its own actions.
Human involvement is most useful after the system has reduced the question to one specific, understandable decision.
The workload still needs a strong credential
Agent identity does not replace workload identity. The agent still runs as a process, container or pod, and that runtime needs a secure way to authenticate.
Bearer tokens work like tickets: whoever holds a valid copy can present it. Kubernetes is strengthening this layer through Pod Certificates, introduced in beta in version 1.35 and moved to general availability in version 1.37. They support proof of possession and platform-managed rotation rather than sending a complete bearer credential to every peer.
This is not a universal answer. Applications must use rotated material, and organisations still need a certificate signer and a carefully designed trust model. The durable principle is to prefer short-lived, workload-specific credentials over static secrets copied across systems.
The agent’s logical identity and its runtime identity should be connected in the audit trail without collapsing into the same shared account.
Do not solve the fashionable problem first
Agent authorization must not distract from basic security. Mandiant’s M-Trends 2026 report, based on its 2025 investigations, says exploits remained the most common initial infection vector at 32 percent. It also says the vast majority of successful intrusions still came from fundamental human and systemic failures, even as attackers used AI to accelerate parts of their work.
An organisation that creates sophisticated agent identities while leaving internet-facing systems unpatched or long-lived secrets in repositories has solved the new problem before the urgent one. Keep patching, hardening, monitoring and testing recovery—and do not add autonomous access through identities that make actions impossible to distinguish or contain.
Rebuild the incident around bounded authority
Now replay Monday morning.
The engineer asks the operations agent to investigate checkout failures. The platform records the task and grants short-lived, read-only access to checkout logs, metrics and deployment data.
The agent finds the expired certificate. Because its investigation authority cannot change production, it creates a proposal with the target, deployment, validation checks and rollback condition.
An external policy service checks the target, operation and approval requirement. The engineer approves the exact change, and an execution service receives a temporary credential restricted to that operation and resource. Policy is checked again immediately before execution.
The final record connects the engineer, agent, running workload, policy version, approved action, changed resource, validation result and expiry time.
The agent still fixes the outage quickly. The difference is that speed no longer depends on an account with unexplained power.
Ten questions before giving an agent cloud access
- Can we distinguish the agent from its user, runtime and other automation?
- Who owns and sponsors the agent identity?
- Is the agent acting independently or using delegated human authority?
- Can that delegation be narrower than the user’s full access?
- Are credentials short-lived, resource-scoped and audience-bound?
- Which actions are read-only, pre-approved, approval-required or prohibited?
- Is policy enforced outside the model and immediately before execution?
- Can another tool or agent bypass that same policy boundary?
- Can the audit trail connect the request, decision, action and result?
- What automatically ends the authority when the task is complete?
If the answers reduce to “the agent uses our automation account,” the design is not finished.
The principle to carry forward
AI agents are making an old cloud-security weakness harder to ignore. Autonomous tool selection creates more ways to use the authority hidden inside shared credentials and broad service accounts.
A unique identity is only the beginning.
The complete boundary must connect the person, agent, running workload, delegated purpose, proposed action, policy decision and final consequence.
Before asking whether an agent can perform a task, ask three sharper questions:
Whose authority is it using? What exactly does that authority permit? Where is that decision enforced before the action becomes real?
Those answers—not the fluency of the model—determine whether an agent belongs in production.
References and further reading
These primary sources provide a path into the platform details, standards work and security evidence behind the article. Product states should be checked again before implementation.
- What are agent identities — Microsoft Entra Agent ID — Explains agent identity, autonomous access, delegated access and the difference from human and application identities. Last updated 15 June 2026.
- What’s new in IAM: Security, governance, and runtime defense — Google Cloud — Lists the May 2026 availability states for Agent Identity, agent-aware IAM policy, gateway enforcement and related controls. Published 6 May 2026.
- Introducing Amazon Bedrock AgentCore — AWS — Introduces AgentCore’s runtime, identity and gateway capabilities; updated for general availability on 13 October 2025.
- AgentCore policy controls and evaluations — AWS — Describes policy enforcement outside the agent reasoning loop and before gateway tool execution. Published 2 December 2025; Policy reached general availability on 3 March 2026.
- The AWS MCP Server is now generally available — AWS — Covers IAM-based agent access, separation of human and server permissions, sandboxed execution and audit visibility. Published 6 May 2026.
- Kubernetes v1.35 release — Announces Pod Certificates in beta with native key generation and automated rotation. Published 17 December 2025.
- Kubernetes v1.37: Pod Certificates and Cluster Trust Bundles — Explains bearer-token limitations, proof-of-possession credentials, general availability and implementation caveats. Published 28 August 2026.
- NIST AI Agent Standards Initiative — Tracks NIST work on secure, interoperable agent standards and identity infrastructure. Created 17 February 2026; updated 14 August 2026.
- Software and AI Agent Identity and Authorization — NIST NCCoE — Explores standards-based approaches for identifying agents and authorizing their access and actions. Status reviewed 11 September 2026.
- M-Trends 2026 — Mandiant — Provides evidence from 2025 investigations about exploitation, attacker handoff speed and the role of AI in observed intrusions. Reviewed 11 September 2026.