AI Agent Identity and Least Privilege: Own Every Non-Human Actor

Most early AI agents do not have identities. They borrow one. A shared "ai-bot" service account, a developer's personal API key pasted into a secrets file, or a long-lived token that every prototype in the squad reuses. That works until the agent writes a record it should never have touched, spends against someone else's budget, or keeps running after the person who launched it has left the company.

Identity and least privilege are the first two controls in any serious AI agent governance checklist. This spoke is the practical pattern: a unique non-human identity, a named owner, a purpose statement, and credentials that expire before they become folklore.

Shared accounts fail in ways that look like success until audit day.

• No attribution. When five agents share one principal, logs cannot tell you which agent changed a CRM field or called a payment API.
• Blast radius. Compromising or mis-scoping one agent compromises every workload on that account.
• No offboarding. Revoking access for a retired agent means breaking the ones that still matter — so teams leave the account alive forever.
• Permission creep. Someone grants "temporary" write access for a demo. Months later every agent on the account can delete.

Agents multiply faster than human accounts. Treating them as interchangeable bots under one login is how organisations discover, too late, that they cannot answer who did what.

The failure is organisational as much as technical. Security reviews a shared account once and assumes the risk is bounded. Product ships three more agents onto the same principal because provisioning a new identity "takes too long." Finance sees one line item and cannot tell which workflow is burning tokens. By the time someone asks for an access review, the account has write rights that nobody remembers approving.

Treat every production agent as a non-human identity (NHI) — closer to a tightly governed service account than to a chatbot persona.

Each agent should have:

• A unique ID in your IAM, CMDB, or agent register — not a shared label like prod-agent.
• A named human or team owner who is accountable for behaviour, spend, and access reviews.
• A written purpose statement: what the agent may do, for whom, against which systems, and what is explicitly out of scope.

You do not need a new vendor product to start. An inventory spreadsheet that becomes an IAM register is enough for the first dozen agents. Products that mint agent identities and bind them to secrets managers help once you are past that scale — the pattern matters more than the logo.

Ownership must be real. "Platform" or "AI COE" with no named person is how agents become orphans after the first reorganisation. Pair the owner with an engineering co-owner who can rotate credentials and shut the runtime down.

Write the purpose statement in language a security engineer and a business owner can both sign. "Help support" is not a purpose. "Draft tier-1 replies for password-reset tickets; may read the knowledge base and the ticket thread; may not send mail or close tickets without human approval" is a purpose. Ambiguous purpose is how least privilege gets renegotiated in Slack under deadline pressure.

Review the register on a fixed cadence. Agents that no longer have an owner, a purpose, or traffic should be disabled — not left "just in case" with live credentials.

Least privilege for agents means credentials that match the current task, not the maximum power the roadmap might need someday.

• Issue short-lived, scoped tokens instead of static API keys that live in env files for years.
• Separate read from write. An agent that summarises tickets does not need permission to close them. An agent that drafts replies does not need permission to send without a human gate.
• Gate irreversible actions. Payments, deletions, outbound messages to customers, and production schema changes should require human approval until eval data and incident history say otherwise.
• Make access revocable in real time. When an agent drifts outside its purpose, you must be able to cut the session without a change window.

Rotation calendars for long-lived keys are a fallback, not the design. Prefer credentials that die with the task. Where static keys still exist, inventory them, bind each to one agent ID, and put a hard expiry on the ticket to replace them.

Tool permissions deserve the same split. An agent that can open a browser, send email, or call an internal admin API is not "slightly more capable" — it is a different risk class. Scope tools the way you scope credentials: default deny, allow by purpose, and require a human gate when the action cannot be undone. Log every tool call against the agent ID so an incident review can reconstruct the path.

Break-glass access should be rare, time-boxed, and audible. If operators habitually elevate an agent to fix production, your purpose statements are wrong or your runbooks are missing — fix those, do not normalise standing admin rights for non-human actors.

Identity without retrieval control is half a story. An agent that can call your RAG stack will see whatever the retriever returns. If the index does not enforce the same tenant, role, and classification filters as your source systems, the agent's "least privilege" is fiction.

That is the bridge to RAG security and governance: ACL metadata on chunks, query-time filters tied to the agent's (or end-user's) principal, and audit logs that record which identity retrieved which documents. Agents acting on behalf of a user should usually inherit that user's retrieval scope — not a superuser service role "for convenience."

The same discipline belongs in any production RAG or LLM path described in our RAG and LLM production guide: permissions in the index path, not in a polite system prompt.

Test negative cases the way you would for any IDOR. An agent scoped to tenant A must not retrieve tenant B. An agent without HR access must not surface compensation passages. A revoked agent must fail closed after ACL sync — including cached sessions. Positive demos are not access tests.

When the agent acts on behalf of an end user, prefer delegating the user's token (or a down-scoped derivative) over a standing superuser retrieval role. Convenience is how confidential corpora end up in the wrong answer stream.

1. Days 1–3 — Inventory. List every agent in use (including shadow prototypes). Record owner, purpose, credentials, and data stores touched.
2. Days 4–7 — Unique IDs. Create one identity per agent. Kill shared accounts for anything that can write or spend. Assign named owners.
3. Days 8–11 — Scope credentials. Replace static keys with expiring, least-privilege tokens. Split read/write. Add human approval for irreversible actions.
4. Days 12–14 — Prove revoke. Drill a live revoke: stop one agent mid-session and confirm tools and retrieval fail closed. Fix gaps before the next launch.

If you are still jumping from pilot to production, fold this identity work into the readiness gates in AI PoC to production — an agent without an owner and scoped credentials is not production-ready, no matter how good the demo looked.

Need help installing agent identity and least privilege without freezing delivery? Talk to rowth.ai's enterprise AI consulting team.