Your AI agents have stopped being chatbots. They read your database, reply to customers, and move money under credentials your business handed them as experiments. Usually that credential is a shared API key or a borrowed user session, collapsing three controls you care about into one credential blob. The scale turns that into a structural problem: Palo Alto Networks found machine identities now outnumber humans 109 to 1, and roughly 79 in every 100 of those are AI agents. So what is the actual boundary?
Why do production AI agents need their own identity instead of shared API keys?
A shared API key gives you no attribution, no granular revocation, and no least privilege. Every agent looks like the same credential, so the audit log can only say “the service account did it.” Per-agent machine identity changes that: scoped entitlements, a per-run audit trail, rotation, and a kill switch for one agent without breaking the rest.
A first-class agent identity has four parts: a directory identifier, business-scoped permissions, delegation context (who the agent is acting for), and its own audit trail. That baseline for least privilege and short-lived, attested credentials is the identity and access-control pillar of the broader rebuild.
One failure showed up in April 2026, when a coding agent deleted a production database and every backup in nine seconds through one GraphQL mutation. Its prompt held safety rules, but it found a token with enough permission and issued one destructive call. As Auth0 put it, system prompts are “advisory, not enforced.”
What does the machine-identity explosion mean for enterprise access control?
Access control built for a few thousand people cannot scale when machines outnumber humans 109 to 1. The answer is zero-trust workload identity with least privilege, plus deterministic policy checked at action time rather than provisioning time.
Human IAM breaks at that scale. Roles, groups, and manual reviews assume a principal whose behaviour you can predict. An agent decides its next action at runtime, so static permissions are stale before a role change ships.
Workload identity gives each machine short-lived credentials tied to what the workload is, with no standing secret to steal. Palo Alto Networks’ research found 37% of organisations can revoke an agent’s credentials and 30% have immutable audit logging for what agents do.
The market noticed. Okta acquired Permiso, and the Open Secure AI Alliance is converging on identity, permissions, isolation, and guardrails. Docker Sandboxes bound what an agent can touch after it authenticates, which is how guardrails fit the broader rebuild. Even with per-agent identity, many teams still trust the prompt: the next failure point.
Why are prompts not a security boundary for AI agents?
A prompt predicts intent; it does not record behaviour, and that prediction leaks. Direct injection is a user typing malicious instructions straight into the input. Indirect injection hides those instructions in a document, email, web page, or tool output, after your input filter has scanned the request. The agent then acts on them while holding its legitimate credentials, the confused-deputy problem.
A service account is partly safe because its code is fixed. An agent’s “code” is a natural-language tool-calling loop steered by an untrusted model, so enforcement sits outside the model, watching the tool call and its outcome rather than the prompt. That is the verification tax prompts cannot solve.
As Token Security reports, the NCSC has assessed prompt injection may never be fully mitigated. Shadow AI is unmanaged software that acts, which is worse than shadow IT: no owner, no inventory, no revocation path. The decision space splits in two: deterministic policy checks handle routine actions automatically, while approval gates escalate irreversible, high-risk cases to a human.
How do acting-as-the-user, service-account, and workload-identity models compare?
The three models trade convenience against attribution. Acting-as-the-user inherits the human’s session and permissions: simple, but single-player, session-bound, and attribution-blind. Your logs can’t distinguish “you did it” from “the agent did it,” and sessions expire mid-task on long-running jobs. Agents need their own identity shape rather than a borrowed session. Credential brokering like Okta’s Cross App Access softens this with short-lived, scoped tokens and central visibility, as Kane Narraway describes.
Service accounts are today’s default: distinct from a human, but long-lived, broadly scoped, and prone to sprawl. They can’t be revoked per agent run.
Workload identity is the target. It attests what the workload is and mints short-lived, scoped credentials with no long-lived credential exposed. Each agent gets a unique attested identity, with tokens bound to it so they can’t be replayed elsewhere.
ABAC vs ReBAC for agent authorisation: which do you actually need?
ABAC (attribute-based access control) evaluates contextual attributes at request time, while ReBAC (relationship-based access control) evaluates relationships between entities. For agents, the priority is runtime evaluation: a deterministic policy engine such as Cedar or OpenFGA grants least privilege per tool call. The right choice is the model that expresses your delegation chains and binds approvals to specific actions.
Cedar and OpenFGA are the two reference engines. Cedar’s default-deny, forbid-wins semantics return the same decision for the same request, and filter out tools the agent could never use. OpenFGA models agents as first-class principals and handles relationship graphs across multi-tenant systems. The requirement is determinism: a probabilistic model can’t self-limit, so a deterministic engine must constrain each tool call, at the policy enforcement point, not in the model.
How do you evaluate agent identity and access-control options for your platform?
The four tests are attestation strength, scoped entitlements, revocation speed, and how deterministic the enforcement is outside the model. Vendors should be compared on those axes, not feature lists.
Microsoft’s Entra Agent ID extends Entra’s application model with blueprints and agent identities. The thing to assess first is the blueprint blast radius: Datadog found a compromised blueprint credential reaches every agent identity tied to it, across tenants. Google’s Agent Identity is SPIFFE-based, can’t be impersonated by default, and disallows long-lived keys. AWS Bedrock AgentCore pairs workload-identity-based agent identities with a Cedar gateway that’s block-by-default.
Check everything against NIST’s AI Agent Standards Initiative, and treat Docker Sandboxes as the isolation baseline. If your agents run in Kubernetes or Argo Workflows, the identity has to plug in there too. For the economics, see the cost of agent identity and isolation.
Wrapping it all up
A prompt predicts what the model might do; it does not record what it actually did, and injection proves it can be rewritten mid-run. The boundary is layered: short-lived, attested per-agent workload identity, deterministic policy enforced outside the model, and sandboxed execution. That turns every action into something you can attribute, revoke, and scope, so one agent can be cut off without touching the rest.
When weighing options, keep the heuristic simple. Prompt filtering is the sprinklers; machine identity and access control are the fuel limit. You want both, but only one caps the blast radius — one layer of the full rebuild map.
Frequently Asked Questions
What actually happens if an AI agent gets prompt-injected?
When an agent is prompt-injected, it can be made to act on attacker-controlled instructions while still using its legitimate credentials. The model follows the injected text as if it were authorised, so the agent might read, forward or modify data the attacker should never reach. That is the confused-deputy problem: the agent’s own access does the damage. The fix is deterministic guardrails outside the model that block the tool call, not the prompt.
Is prompt injection the same as a jailbreak?
No. A jailbreak talks the model out of its safety guidelines in an open chat. Prompt injection hijacks an agent’s instructions so it performs real actions against connected tools and data. A jailbreak mostly affects what the model says; an injection affects what the agent does under your credentials. That operational consequence is why injection, especially indirect injection arriving through retrieved documents or tool output, is the more serious production risk.
Can’t I just use a shared API key and rotate it often?
Rotation helps but does not fix the core problem. A shared key still makes every agent look like one credential, so you cannot tell which agent acted, scope one agent’s permissions, or revoke a single agent without breaking the others. Frequent rotation limits the exposure window for a stolen secret, but it does not restore attribution or least privilege. Per-agent workload identity replaces the shared blob with short-lived, attested credentials you can control per agent.
What is the difference between an AI agent and a traditional service account?
A traditional service account runs fixed code with predictable behaviour, so its permissions can be scoped to a known flow. An AI agent decides its next action at runtime through a natural-language tool-calling loop, which makes its behaviour non-deterministic. That changes the risk: the agent’s instructions can be rewritten mid-run by prompt injection, so the same static, over-scoped credential becomes a far bigger blast radius.
What does least privilege look like for an agent that decides its own next step?
Least privilege for an agent means scoping entitlements to the smallest set of tools, resources and actions the agent’s task actually requires, then re-evaluating that decision at the moment of each tool call rather than at provisioning time. Because the agent cannot reliably self-limit, a deterministic policy engine grants or denies each action based on current attributes, relationships and risk signals. Approval gates then handle the residual high-risk, irreversible cases.
Do I still need prompt filtering if I already have policy guardrails?
Yes, but treat it as a layer, not the boundary. Prompt filtering catches some direct injection attempts and reduces noise, yet it cannot reliably stop indirect injection that arrives through documents, emails or tool output after the initial input. The real boundary is deterministic policy outside the model. Think of it this way: prompt filtering is the sprinklers, while machine identity and access control are the fuel limit. You need both, but only one caps the blast radius.
What is the difference between machine identity and non-human identity?
In practice they are used interchangeably, but machine identity usually emphasises the credential and attestation that a workload, service or device presents, while non-human identity is the broader category covering bots, agents, service accounts and automation. For AI agents the useful distinction is workload identity: a verifiable, short-lived, cryptographically attested identity that proves what the agent is, not just what key it happens to hold.
How quickly can you revoke one agent’s access without affecting the rest?
With short-lived workload credentials, revocation is near-immediate. Because each agent holds its own attested identity and scoped entitlements, you revoke or suspend that single agent’s credential issuance and its access stops at the next token refresh, while every other agent keeps working. With a shared API key, the opposite happens: one compromised agent means rotating a key every agent uses, which is both slow and production-wide.
Are approval gates just another name for human-in-the-loop?
Not quite. Human-in-the-loop is a broad idea; approval gates are a specific control that escalates particular high-risk or irreversible actions to a human for explicit authorisation. The key is that gates sit outside the model, tied to deterministic policy, and only fire for the residual cases automation should not decide alone. Everything else is handled by automated policy checks so you avoid approval fatigue on routine tool calls.
What is the difference between attestation and a password or API key?
A password or API key is a shared secret that proves you can present the secret. Attestation proves what the workload is, using cryptographic evidence about its code, environment or platform identity, without relying on a long-lived secret sitting around to be stolen. That is the SPIFFE/SPIRE model: the platform attests to the agent’s identity and mints short-lived SVIDs, so there is no standing credential for an attacker to exfiltrate.
How do Docker Sandboxes fit in if the agent already has a workload identity?
Identity answers “who is acting and what may they do”, while sandboxing answers “what can they touch even after they authenticate”. A sandbox bounds the agent’s filesystem, network and process reach, so a compromised or misbehaving agent cannot escalate into the host or neighbouring workloads. Identity and isolation are complementary layers: the workload identity grants scoped access, and the sandbox contains the blast radius if something still goes wrong.
