What Your Manager Means When They Say 'Agent Identity'
In 2024, the question "should we let an AI agent take an action in production?" was theoretical. In 2025, the answer was "we already are, please don't tell anyone". By 2026, every company of meaningful size has half a dozen agents running real work — answering tickets, opening pull requests, querying customer data, refilling Slack channels with summaries nobody reads.
All of those agents need identities. The IAM stack was designed for people. Reconciling those two facts is the actual IAM work of 2026, and it is — to use a technical term — not entirely smooth yet.
Why "just use a service account" doesn't work
The reflex from any IAM-adjacent person is: agents are non-human, service accounts are non-human, problem solved. This reflex is wrong, but for interesting reasons.
A service account is designed for a process that always does the same thing — a nightly backup job, a webhook receiver, a database replication worker. The work is predictable. The required permissions are static. The owner is well-defined.
An agent is designed to do different things every time, often in response to natural-language instructions that the agent itself partially decides how to interpret. The required permissions are dynamic. The owner is fuzzy ("the team that runs the agent"). The blast radius of a wrong action is unbounded in a way that "the nightly backup ran a second time" simply is not.
The three concepts you'll keep hearing in 2026
If your manager has started saying "agent identity" in meetings, here is the translation:
- Non-Human Identity (NHI). Umbrella term for "an identity in our IAM system that isn't a person". Covers service accounts, OAuth apps, API keys, and now agents. Vendors love this term because it lets them sell a single product to cover everything.
- Scoped credentials / capability tokens. Instead of "this agent has read access to the customer-data table", you issue a credential that says "this agent, in the next 15 minutes, can read records matching THIS query, returning at most 100 rows". Permissions shrink to the minimum needed for the immediate task. When the task is done, the credential is dead.
- On-Behalf-Of (OBO) flows. When a human asks the agent to do something, the agent inherits the human's permissions for that operation. The audit trail then shows "Chiamaka asked the assistant to refund this customer" instead of "the assistant refunded this customer", which makes the post-incident review significantly more pleasant.
The actual hardest part: revocation
Granting access to an agent is mostly a solved problem. Revoking it under pressure is not.
When an agent does something it shouldn't have, you need to revoke its access in single-digit minutes. Service-account credentials with hour-long token TTLs don't cut it. Long-lived API keys are worse — once a key leaks, you have to find every place it's been cached, which (it turns out) includes a vector database, three monitoring dashboards, and a Slack bot from 2024 nobody admits to writing.
The patterns that actually work in 2026 production:
- Short-lived tokens with short TTLs (5-15 minutes), refreshed against an identity provider that you control.
- One credential per agent, per task — not one credential per agent forever. Easier to revoke; easier to audit.
- A "kill switch" runbook tested quarterly. The exercise: revoke agent X in under 5 minutes, measure how long it actually took. The first time you run this, the answer is "longer than you'd like to admit".
What this means for your job
If you sit in IAM, agent identity is the most interesting work on your plate in 2026. The vendors are scrambling. The standards (OAuth 2.1, SPIFFE/SPIRE, the FIDO non-human profile drafts) are real but immature. The hiring market for people who can speak fluently about NHI is already tight, and it will tighten further.
If you sit on a service desk, this is the conversation your IAM team is having one floor up. Learn the vocabulary. The next promotion in your track probably involves one of these meetings.