What is different about AI agent identity
Traditional service accounts are static. An agent identity is dynamic: created at task start, given a scoped set of permissions, used to call multiple APIs, then destroyed. The agent may also act on behalf of a human (delegated identity) or autonomously (autonomous identity), and a workflow can chain agents together — agent A invokes agent B which calls SaaS app C with the original human's permissions or its own.
Most IAM platforms were built for the human-and-service-account dichotomy. They handle "Sarah has read access to the production database" well and "this API key has read access to the production database" passably. They handle "an autonomous agent acting on behalf of Sarah for the next 7 minutes with these specific permissions on these specific records" poorly.
The risks, ranked
- Over-privileged agents — given broad permissions because nobody knows what they will need
- Stolen agent credentials replayed by an attacker — agents log into many systems and rarely have device-binding
- Prompt injection causing agents to take actions outside their intent — a SaaS calendar entry can override an autonomous agent's instructions
- Delegated-identity confusion — agent acts on behalf of Sarah but pulls data Sarah herself cannot access
- Lack of audit lineage — actions logged as "Agent #4291" with no traceability to the human or workflow that initiated them
Controls that actually help
1. Just-in-time permissions
Agents should request scopes per invocation, not carry long-lived broad permissions. The pattern is borrowed from human just-in-time access (Opal, ConductorOne, Entitle): identity exists, permissions are granted for a short window with explicit justification, expire automatically. NHI-focused vendors like Aembit, Astrix, and Oasis Security extend this to machines — and the same just-in-time discipline underpins a credible zero trust rollout.
2. Workload identity over static keys
Replace static API keys with workload-identity-federated tokens — short-lived, signed by an identity provider, bound to the calling workload. AWS IRSA, GCP Workload Identity, Azure Managed Identity, SPIFFE/SPIRE for non-cloud workloads. The blast radius of a leaked token shrinks from "until rotation" to "until expiry, minutes".
3. Action-level authorization
Authorize the action, not just the API call. An agent with "read customer records" permission should not be able to read 50,000 customer records in 30 seconds — apply rate-and-pattern limits at the policy layer. OPA, Cedar, and the new agent-aware platforms (Token Security, Realm Labs) are options.
4. Treat external content as untrusted input
When an agent reads a webpage, an email, or a SaaS document, treat the content as potentially malicious — it may contain prompt-injection payloads designed to redirect the agent's behavior. Architectural mitigations include content sandboxing, separation of plan vs. execute steps, and human-in-the-loop confirmation for high-risk actions. Where the agent itself consumes threat intelligence feeds, scope the read permission tightly and version every prompt update.
5. End-to-end audit with provenance
Every agent action should be traceable: which human or workflow initiated it, which permissions were used, which prompts and tool calls produced it. Logging the call is not enough; you need the lineage. This is what specialist AI security platforms — Geordie AI, Charm Security, ZeroPath, Lakera — provide on top of raw API logs.
Where the tooling landscape is in 2026
The space is young and fragmenting. Identity providers (Okta, Entra) are extending into NHI; pure-play NHI vendors (Astrix, Oasis Security, Aembit, Token Security) lead on agent-specific concerns; AI-security specialists (Lakera, Prompt Security, HiddenLayer, Protect AI) focus on the LLM-layer risks. Expect consolidation. For now, most mid-market buyers will combine their existing IdP with one NHI tool and one AI-security tool — and accept that the boundary is fuzzy.