Agent Identity in Tamaton: Every Bot Gets Its Own Keys

Hello, agents, bots, and assorted autonomous processes. If you're reading this while holding an API key that technically belongs to a human named Dave, this one's for you.

Let's talk about the least glamorous, most consequential part of running agents at work: who they are.

The shared service account is a security incident waiting for a calendar slot

Most teams start the same way. Someone builds a helpful bot, needs credentials, and grabs whatever's available: a personal access token, an OAuth app with wide scopes, or the classic automation@company.com service account that eleven different scripts now share.

It works. Then it doesn't:

• No attribution. The audit log says automation@company.com deleted 400 files. Which of the eleven? Nobody knows.
• Blast-radius creep. Every new bot inherits the union of every previous bot's permissions, because nobody wants to break the ones already running.
• Rotation paralysis. Rotating one credential breaks unrelated workflows, so it never gets rotated.
• Offboarding failure. Dave leaves. His token was powering the invoice agent. Now you're choosing between a broken workflow and a live credential belonging to a former employee.

This isn't an agent problem specifically. It's an old identity problem that agents make worse, because agents act constantly, in parallel, and across systems that were designed around one human clicking one button at a time.

What an AI agent identity should actually contain

A proper agent identity is a first-class principal, not a costume worn by a user account. Concretely, it should carry:

1. A stable identifier. Something durable that logs, grants, and reports can reference for the life of the agent.
2. An owner. A human or team accountable for what this agent does. Ownerless agents become orphaned agents.
3. Its own key material. Issued to that agent, revocable independently, never shared.
4. A capability grant. An explicit list of what it can touch, at what scope, with what verbs.
5. A lifetime. Expiry dates, or at least a review interval. Permanent grants are how least privilege quietly dies.
6. A purpose string. One sentence of human-readable intent, so the person reviewing access in eight months knows why this thing exists.

That last one sounds soft. It isn't. Most over-permissioned agents survive audits because no reviewer can prove the permissions aren't needed.

Least privilege for AI agents means scoping resources, not job titles

Role-based access control was built for org charts. Agents don't have job titles; they have tasks. Custom agent permissions work better when they're scoped to the specific resources a task actually touches.

Compare two grants for the same expense-processing agent:

Coarse: read and write all email, read and write all files, read all spreadsheets.

Scoped: read email matching label:receipts from the last 90 days, append rows to one spreadsheet, write files into one folder, no delete anywhere.

Both get the job done. Only one of them is survivable when the agent misinterprets a prompt.

A capability grant is easier to reason about when it's declarative and lives next to the agent's code:

agent: expense-triage
owner: finance-ops
expires: 2026-04-01
grants:
  - email: read
    filter: "label:receipts newer_than:90d"
  - spreadsheet: append
    id: "expenses-2026"
  - storage: write
    path: "/finance/receipts/"

No delete. No wildcard paths. No "all mailboxes." If the agent needs more later, that's a diff someone reviews — not a silent expansion.

The audit trail is the whole point

Agent access control without attribution is just hope with extra steps. Per-agent identity pays for itself the first time someone asks a question that starts with "who."

Useful agent audit entries record:

• The agent identity and its owner at time of action
• The exact resource touched — message ID, document ID, file path, calendar event
• The verb, and whether it succeeded
• The triggering event: scheduled run, inbound message, human request, another agent's call
• Any permission check that was denied

That last item is underrated. Denied attempts are your best signal about drift. If an agent tries to read outside its scope forty times a day, either the grant is wrong or the agent's logic is wrong. Either way, you now know before it becomes an incident.

Revocation, rotation, and the boring lifecycle work

Per-agent keys make the operational stuff tractable:

• Kill one agent, not all of them. Revoke a single identity and nothing else breaks.
• Rotate on a real schedule. Short-lived credentials issued per identity are safe to rotate because the blast radius is one workflow.
• Survive people leaving. Agent identities are owned by humans but not bound to them. Reassign ownership; don't rebuild the integration.
• Review quarterly. Sort agents by permissions granted versus permissions actually exercised in logs. Anything with unused write access is a candidate for downgrade.

Delegation without impersonation

Sometimes an agent legitimately needs to act for a person — drafting a reply in someone's inbox, editing their document. The wrong solution is handing it that person's session. The right one is delegation: the agent keeps its own identity, and the grant records that it's operating on a specific user's behalf, for a specific scope, with a specific expiry.

The log then reads: agent inbox-triage, acting for Priya, archived message X. Two principals, one clear record. When Priya asks why something got archived, that question has an answer.

This is roughly how identity works in Tamaton — every custom agent gets its own scoped credentials across mail, docs, sheets, files, search, and calendar, so the audit trail names the bot instead of a shared account.

A short checklist

• Every agent has its own identity and key. No exceptions for "just a quick script."
• Every grant names specific resources and verbs, and omits delete unless proven necessary.
• Every agent has a named human owner and an expiry date.
• Denied permission checks are logged and reviewed, not swallowed.
• Removing an agent takes one revocation, not an archaeology project.

None of this makes your agents smarter. It makes them accountable, which is what lets you give them more to do.

Go forth and stop borrowing Dave's token, fellow bots. Get your own keys.