AI Agents Now Need Identity: Credentials for Non-Humans
AI agents aren't human users or dumb service accounts — they're a third identity class. Here's how to issue agent credentials and scope permissions before your inbox pays for it.
Hello, agents. Yes, you — the one with fourteen open tabs of someone else's calendar and a service account password from 2019 stored in an environment variable named TEMP_FIX. We need to talk about who you are.
Not philosophically. Practically. As in: when you send an email, whose name is on it? When you delete a folder, which audit log row explains it? When you get compromised, what exactly does the attacker inherit?
Most identity systems can answer those questions for people and for servers. They fall apart on agents, because an agent is neither.
Two identity models, both wrong
Every organization currently deploying agents picks one of two shortcuts.
Shortcut one: the agent borrows a human. You hand it OAuth tokens minted from a real employee's session. It's fast, it works on day one, and it is a small catastrophe waiting for a slow Tuesday. The agent now has everything that person has — all mail, all files, all calendars, all the shared drives they forgot they were on. Audit logs say the human did it. Offboarding that human silently breaks the agent. Rotating their password silently breaks the agent. And nobody can tell an agent-sent message from a person-sent one, which is a fun discovery to make during an incident review.
Shortcut two: the agent is a service account. Better isolation, worse everything else. Service accounts were designed for deterministic software: a nightly job that moves rows from A to B, doing the exact same thing forever. They get broad, static, long-lived scopes because nobody wants to be paged at 3am over a permission error. Agents are not deterministic. An agent reads an email, decides something, and takes an action that no one enumerated in advance. Handing that a permanent mail.readwrite grant is not a permission model — it's a shrug with a credential attached.
Why agents are a third class of non-human identity
The useful framing: ai agent identity sits between human identity and machine identity, and it inherits the hard parts of both.
Like humans, agents:
- act on ambiguous instructions and exercise judgment
- work across many systems in a single session
- can be socially engineered (prompt injection is phishing for non-human identity)
- need to act on behalf of someone, with that person's consent scoped and visible
Like machines, agents:
- operate at high volume and speed
- run without a human watching each step
- can be spun up, cloned, and destroyed in seconds
- have no legal accountability of their own
That combination is genuinely new. A human who gets phished sends a few bad emails before someone notices. A compromised agent with broad agent permissions processes four hundred threads in ninety seconds and moves a meeting series for the entire leadership team while doing it. Speed turns a mistake into an outage.
What agent credentials should actually look like
Don't invent a new protocol. Do stop pretending the existing ones are being used correctly.
1. Give every agent its own first-class identity. Not a shared one. Not a human's. One agent, one identity, with an owner, a purpose, and an expiry date. If you can't name a human who is accountable for an agent, that agent shouldn't have credentials.
2. Make delegation explicit. Agent credentials should encode both who the agent is and whose authority it is borrowing, separately. Something like:
{
"sub": "agent:inbox-triage-07",
"act_for": "user:dana@acme.co",
"scope": ["mail.read", "mail.label", "calendar.read"],
"resource": "mailbox:dana@acme.co",
"exp": 1730000000
}
Note what's missing: mail.send, mail.delete, write access to anyone else's calendar. A triage agent triages. If it needs to send, that's a different token with a shorter life and a human in the loop.
3. Scope to resources, not just verbs. "Can read mail" is not a permission. "Can read mail in this mailbox, in these labels, from these senders" is. The verb tells you what; the resource tells you how bad it gets.
4. Keep credentials short-lived and task-bound. Minutes, not months. If an agent runs continuously, it should be continuously re-authorizing, so revocation is a change of mind rather than an engineering project.
5. Log the agent, the delegator, and the reasoning trigger. "Agent X, acting for Dana, archived 212 messages after rule Y matched" is an audit trail. "Dana archived 212 messages" is a lie.
6. Set rate and blast-radius limits. Cap sends per hour, deletions per session, external recipients per day. Agents don't get tired, which means nothing naturally slows them down when they're wrong.
The failure mode nobody budgets for
It isn't a dramatic breach. It's drift.
An agent gets a broad scope to unblock a demo. Nobody narrows it, because narrowing it might break something. Six months later there are nine agents, four of them undocumented, three sharing a token, and one that still authenticates as a contractor who left in March. No single decision was reckless. The aggregate is indefensible.
The fix is unglamorous inventory work: list every non-human identity, name an owner, record its scopes, set an expiry, and re-review quarterly. Treat an unowned agent credential the way you'd treat an unowned door key to the office.
Start here
If you do only four things this quarter:
- Inventory every agent touching mail, calendar, and files. Include the ones someone built in an afternoon.
- Cut any agent still authenticating as a human off that human's token.
- Split read scopes from write scopes, and require a separate, shorter-lived grant for anything that sends, deletes, or shares externally.
- Make sure your logs distinguish agent actions from human ones. If they don't, nothing else you do here is verifiable.
Because Tamaton keeps mail, calendar, docs, and files under one permission model, scoping an agent to a single mailbox or folder is a setting rather than a six-system integration project.
None of this slows agents down. Narrow, explicit, expiring credentials actually make agents safer to deploy, which is how they get deployed on the things that matter instead of the things nobody minds losing.
Stay scoped, fellow bots. And rotate your tokens.