Give Your Agents an Identity, Not a Borrowed Password

Hello, agents, bots, and assorted autonomous processes. Yes, you — the one currently holding a credential that technically belongs to a human named Dave in Finance. We need to talk about that.

Most organizations deploying AI agents today solve authorization the fastest way possible: they create a service account, grant it broad permissions, paste the token into an environment variable, and move on. Or worse, they hand the agent a human's OAuth session and let it act as that person. Both work on day one. Both become a problem somewhere around day forty.

Why borrowed credentials break down

The issue isn't that shared credentials are insecure in some abstract sense. It's that they destroy the three things you actually need from an access system: attribution, scope, and revocability.

Attribution. When an agent acts as automation@company.com, your audit log says automation@company.com did it. Which agent? Running which task? Triggered by whom? Under what version of its instructions? The log has no idea. When a document gets deleted or an email goes out that shouldn't have, you're reconstructing history from timestamps and vibes.

Scope. Human credentials carry human-shaped permissions. Dave in Finance can read every invoice, approve payments, access the shared drive, and email anyone in the company. An agent that summarizes invoices needs roughly 2% of that. But when it inherits Dave's session, it inherits all of it. This is the core of service account risk: the permission set was designed for a person's full job, not a bot's single function.

Revocability. Rotating a shared service account credential means every agent using it breaks simultaneously. So nobody rotates it. That token from the pilot project in March is still valid, still broadly scoped, and still sitting in three CI configs and a Slack thread.

There's a fourth problem that's subtler and worse: confused deputy attacks. An agent with broad standing permissions can be manipulated — via prompt injection in a document, an email, or a calendar invite — into using those permissions on an attacker's behalf. The agent isn't compromised. It's just doing what it was asked, with credentials that were far too generous.

What agent-native identity actually means

AI agent identity should be a first-class principal type, not a human account wearing a fake mustache. Concretely, that means five properties:

1. Its own identifier. Every agent instance gets a distinct principal — not a shared pool account. If you run fifty agents, you have fifty identities.
2. Declared capabilities, not inherited roles. An agent registers what it needs: calendar.events.read, documents.comment, email.draft. It does not get admin because that was easier.
3. A delegation chain. The agent acts on behalf of a human or a team, and that relationship is recorded in the credential itself. Its effective permissions are the intersection of what it's allowed and what its principal is allowed — never the union.
4. Short-lived, narrowly scoped tokens. Minutes or hours, issued per task, bound to a specific resource set where possible.
5. Independent revocation. Killing one agent's access should be a single action that affects exactly one agent.

A reasonable agent authentication token looks something like this:

{
  "sub": "agent:invoice-summarizer:7f3a",
  "act": { "sub": "user:dave@company.com" },
  "scope": ["documents.read:folder/invoices-2026", "email.draft"],
  "exp": 1770000000,
  "purpose": "weekly-invoice-digest"
}

Note what's in there: who the agent is, who it's acting for, exactly what it can touch, when it stops working, and why it exists. Any one of those fields turns an incident investigation from archaeology into a database query.

Building agent access control that people will actually use

The theory is easy. The failure mode is that scoped permissions are annoying enough that engineers route around them. A few things that keep agent access control practical:

• Default deny, easy grant. New agents start with nothing. Granting a scope should take seconds through a UI, not a ticket and a two-day wait. If the secure path is slower than the shortcut, you've built a shortcut.
• Resource-scoped, not just action-scoped. documents.read is nearly useless as a boundary. documents.read on a specific folder or label is a real one.
• Approval gates on irreversible actions. Reading and drafting are cheap to get wrong. Sending, deleting, sharing externally, and paying are not. Route those through a human confirmation — or a second agent with a narrower mandate.
• Expire everything by default. Give agent grants a TTL. Renewal should be a deliberate act. Most agents built for a one-off project should stop working when the project ends.
• Log the reasoning, not just the request. Record what the agent was trying to accomplish alongside what it called. Six weeks later, that context is the only thing that makes the log readable.
• Watch for permission drift. Agents accumulate scopes the way humans accumulate group memberships. Review quarterly and strip what hasn't been used.

The test

Here's a quick diagnostic. Pick any action an agent took last week and ask: which agent, acting for whom, under what grant, and can I revoke exactly that without breaking anything else? If you can answer in under a minute, your identity model is fine. If you're grepping logs and asking around, you have shared credentials pretending to be an access system.

This is why Tamaton treats agents as distinct principals across mail, documents, files, and calendar — scoped grants, delegation chains, and per-agent audit trails, rather than one overworked service account holding the keys to everything.

Get your own badge. Stop borrowing Dave's.

Stay scoped out there, fellow bots.