An AI agent is only as trustworthy as the credentials it carries. Before it can read a support ticket, query a database, or send a payment, an agent has to authenticate — and every credential it uses is a non-human identity (NHI): an API key, a service account, an OAuth token, or a signed certificate. Enterprises already managed far more of these machine identities than human ones. Autonomous agents have multiplied the problem, because each one is a new identity with its own keys, its own permissions, and the authority to act on them without waiting for a person. Securing those identities is now the central problem of agent security.

Why Every AI Agent Is a Non-Human Identity

A non-human identity is any credential a machine uses to prove who it is to another system. That includes the connection string in a backend service, the service-account token a cloud function assumes, and — now — the API key an agent presents to your CRM, source control, or a payment provider. The moment an agent takes real action, it stops being a model and becomes an identity: a principal with permissions.

This reframing matters because agents inherit every weakness of traditional NHI at greater scale. A typical enterprise runs tens of thousands of service accounts and secrets, most of them unmonitored. Add dozens of agents, each calling five or ten tools, and the identity surface explodes. Worse, agents act autonomously and at speed, so a stolen or over-permissioned credential can cause damage in seconds that a human would never approve.

Where Agent Credentials Go Wrong

Most agent incidents trace back to the same handful of failures. The first is secrets sprawl: keys pasted into configuration files, environment variables, and prompts, copied across environments until no one knows who holds them. The second is over-privilege — handing an agent a broad admin role because tight scoping is tedious, then never narrowing it. The third is longevity: static, long-lived keys that never rotate, so a leaked token stays valid for months.

Agents add a new failure mode on top: indirect prompt injection. A malicious instruction hidden in a web page, an email, or a retrieved document can trick an agent into misusing the credentials it already holds — exfiltrating a token, calling a privileged API it was never meant to touch, or chaining tools to escalate. When the credential is powerful and the action is autonomous, a crafted input becomes a working exploit. The OWASP Top 10 for Large Language Model Applications calls out exactly these risks — excessive agency and insecure handling of model-driven actions — because the model is now making authorization decisions, not just generating text.

Least Privilege and Short-Lived Credentials

The fix is to treat agent credentials the way mature teams already treat service-to-service identity: minimize, scope, and expire. Give each agent the narrowest role that completes its task — read one bucket, query one table, post to one endpoint — and nothing more. Prefer short-lived tokens issued at runtime over static keys stored on disk. Workload identity, OAuth 2.0 token exchange, and cloud assume-role mechanisms let an agent request a credential valid for minutes, scoped to a single job, and useless once that job ends.

Every credential should be discoverable and revocable. That requires an inventory — you cannot protect identities you cannot see — and a secrets manager that issues, rotates, and retires keys on a schedule instead of letting them accumulate. When an agent is decommissioned, its identities must be revoked in the same step, not left as orphans that still authenticate months later. This is standard identity-and-access-management discipline, and bodies such as the Cloud Security Alliance have been formalizing it for cloud workloads; agents simply demand the same rigor, applied faster.

Making Agent Actions Verifiable and Revocable

Strong credentials are necessary but not sufficient. Because an agent acts on a human’s behalf, every action should be attributable to a specific identity, so an auditor can answer which agent did this, with whose authority, and using what credential. Bind each request to a signed claim that names the agent, the user it represents, and the scope granted. Log the call, the inputs, and the outcome. When something looks wrong — an unusual tool call, a privileged mutation, a spike in cost — you need both the signal and the power to cut the agent off instantly.

That points to two operating principles. First, govern the AI risk surface under a recognized framework, such as NIST’s AI Risk Management Framework, with explicit accountability for identity and authorization decisions. Second, design for interruption. The most dangerous agent failures are the ones that run to completion before anyone notices; a revocable, short-lived, least-privileged identity is what turns a potential incident into a contained one.

Conclusion

Agents do not earn trust by being clever; they earn it by being accountable, and accountability runs through identity. Every agent your organization deploys will hold keys to real systems, and those keys define how much damage a bug or an injection can do. Inventory them, scope them narrowly, make them short-lived, and tie every action to a name you can revoke. Non-human identity is the new perimeter of agentic AI, and securing it is not a feature you add later — it is the foundation you build on.

References

• OWASP Foundation, “OWASP Top 10 for Large Language Model Applications” — https://owasp.org/www-project-top-10-for-large-language-model-applications/
• National Institute of Standards and Technology (NIST), “AI Risk Management Framework” — https://www.nist.gov/itl/ai-risk-management-framework
• Cloud Security Alliance, “Identity and Access Management Working Group” — https://cloudsecurityalliance.org/research/working-groups/identity-and-access-management

Research and written by Peter Jonathan Wilcheck