Non-Human Identity for AI Agents: Who Did That?

A record changed in your ERP at 2:14 a.m. The audit log says the change came from svc-integration. Was that the nightly sync job, an AI agent a developer set up last month, or a person who borrowed the service account’s key to fix something quickly? If you cannot answer that in a few minutes, you have a non-human identity problem, and AI agents are about to make it larger.

The short answer: non-human identity for AI agents follows the same rules as any service account, applied more strictly. Treat every AI agent as a distinct identity with its own credentials, a named human owner, permissions scoped to its job, and logs that tie each action back to the request that started it. Route its traffic through one controlled path, keep an inventory, and make revoking it a routine operation. None of this is new security thinking. What is new is how many of these identities an organization can create in a week.

What Is a Non-Human Identity, and Why Do AI Agents Change the Math?

A non-human identity is any credentialed actor in your systems that is not a person: service accounts, API keys, CI/CD pipelines, scheduled jobs, integrations. OWASP thought the category important enough to publish a dedicated Non-Human Identities Top 10 in 2025, and its list reads like a description of the average integration estate: improper offboarding, secret leakage, overprivileged identities, long-lived secrets, one identity reused across many workloads, and people using non-human identities as if they were their own.

Service accounts already had those problems. AI agents change the math in three ways:

• Volume. A team that ran a dozen integrations can now start agent workstreams by the hundred, or more, each one able to call your systems.
• Discretion. A scheduled job does the same thing every night. An agent decides what to do next, so its permissions describe what it could do, not what it will do.
• Delegation. Agents usually act on someone’s behalf. A single action can involve a person, the agent working for them, and the tool the agent called.

OWASP’s guidance for language-model applications names the failure this produces. Its Excessive Agency entry traces damaging actions to excessive functionality, excessive permissions and excessive autonomy, and it recommends enforcing authorization in downstream systems rather than trusting the model to decide what is allowed.

The Question You Need to Answer: Agent, Person, or Process?

Every control below exists to answer one question after the fact: when something happened, which agent did it, on whose behalf, and as part of which request? Attribution is what you reach for during an incident, an audit, a customer dispute, or a budget review. It also matters for cost: AI usage is bought and billed in tokens, and if every agent shares one key, nobody can say which team or workflow spent the budget.

Attribution has to be designed in. It cannot be reconstructed from logs that never recorded it.

1. Give Every Agent Its Own Identity

Not a shared service account. Not a developer’s personal token pasted into a config file. Each agent, or each agent type in each environment, gets its own identity in your identity provider, so its actions show up under a name that means something.

This is the cheapest control on the list and the one everything else depends on. Without it, scoping, logging and revocation all apply to a crowd rather than to an actor. It also closes two of OWASP’s NHI risks directly: reuse of one identity across workloads, and humans operating under a machine identity.

Where an agent acts for a person, keep both identities visible rather than letting the agent impersonate the user. OAuth already distinguishes the two: RFC 8693, OAuth 2.0 Token Exchange, describes delegation, where the actor keeps its own identity separate from the subject it acts for, and defines an act claim that records the acting party in the token. A log line that says “agent X, acting for user Y” answers the question. A log line that says “user Y” alone does not.

2. Scope Credentials Narrowly and Make Them Short-Lived

An agent that summarizes support tickets does not need write access to the CRM. Grant each agent the smallest set of permissions its job requires, and enforce them in the system being called, not in the agent’s instructions. A prompt is not an access control.

Then shorten the credential’s life. Long-lived secrets are on OWASP’s NHI list for a reason: a key that never expires is a key that will eventually leak somewhere you cannot see. Prefer tokens issued per task or per session over static API keys, and where a static key is unavoidable, rotate it on a schedule someone actually owns.

3. Name an Owner of Record for Every Agent

Every agent should have a person, not a team alias, who is accountable for what it is allowed to do and who answers when it misbehaves. The owner approves its permissions, reviews them when its job changes, and is the one who decides it should be retired.

Ownership is what makes offboarding possible. Improper offboarding is the first item on OWASP’s NHI list, and agents make it easier to get wrong: the developer who created an agent changes roles, the project ends, and the agent keeps its credentials and its access indefinitely because nobody knows it is theirs to turn off.

4. Log the Request, Not Just the Call

An audit entry that records “agent called the orders API” is half an answer. Each action an agent takes should carry the identifier of the request that started it, whether that was a person’s prompt, a ticket, or a scheduled trigger, so you can follow one piece of work across every system it touched.

The W3C Trace Context recommendation defines a standard way to carry a trace identifier across service boundaries, so you do not need a homegrown format. Record the agent’s identity, the person it acted for, the request identifier, and what it was allowed to do at the time.

5. Route Agent Traffic Through a Gateway

When agents call your systems directly, each system sees a different slice of their behavior and enforces its own rules, or none. Sending agent traffic through one controlled path, such as an API gateway, gives you one place to authenticate the agent, apply rate limits, enforce scopes and write the log described above.

It also gives you a choke point when something goes wrong. Throttling or blocking one agent at the gateway is, in practice, a quick change. Finding and changing every system it could reach is not. We go deeper on this pattern in putting an MCP server behind an API gateway.

6. Keep an Agent Inventory

You inventory applications, laptops and vendor contracts. Inventory agents the same way: what each one is, who owns it, which identity it uses, what it can reach, where it runs, and when its access was last reviewed. If an agent is not in the inventory, it should not have credentials.

The inventory is also where cost attribution starts. When each agent has its own identity and an owner, usage can be traced to the workflow and the budget that paid for it.

7. Make Revocation Boring

Every agent needs a way to be switched off quickly, and someone should practice using it before it is needed. Revoking one identity at the identity provider, or blocking it at the gateway, should stop that agent everywhere without touching anything else. If disabling a misbehaving agent means rotating a key that six other integrations share, the first control on this list was skipped.

Where MCP Makes This Concrete

The Model Context Protocol (MCP), an open protocol agents use to reach tools and data, has already written several of these controls into its specification. Its authorization section (in the June 2025 revision) treats a protected MCP server as an OAuth 2.1 resource server. The server must check that each access token was issued specifically for it, must not pass a client’s token through to the APIs behind it, and the authorization server should issue short-lived access tokens.

In other words, an MCP server is expected to know which client is calling and on whose behalf, and to keep that boundary when it calls further downstream. Authorization is optional in the specification, so a server that skips it is still compliant on paper. Whether yours does it is a question to ask before an agent connects to anything that matters.

Where to Start

If your organization is moving its first agents toward production, these controls cost the least now, while the number of agents is still small enough to count. Start with three: a distinct identity per agent, an owner of record, and logs that carry the originating request. The rest builds on them.

This is the kind of work we take on with IT teams as an engineering partner: taking an AI use case into production under your own governance, with its security, its support and its running cost named before the build. If your team is weighing where agents fit, our AI strategy and implementation page describes how we approach it, and our guide to whether an AI-built app is ready for real customers covers the basics that come before identity. When you are ready to talk it through, get in touch.