← Library · Concept
Agent identity and permissions — who is actually acting
An agent needs more than tools. It needs its own identity, bounded permissions and an audit trail so it is clear who stands behind an action, what it was allowed to do and where it must stop.
An agent is not an anonymous process
Once an agent sends email, reads Slack, opens a pull request or touches an internal system, it stops being just a model in a window. It becomes an actor inside a work process. The question is not only “what can it do”, but also “under whose identity is it acting”.
A shared token, a developer’s personal account or broad access through one service key are convenient shortcuts. They also erase the boundary between human, agent and automation. When something breaks, nobody wants the log to answer: some token did it.
Identity defines accountability
A good agent identity has a clear scope: this agent belongs to this team, works in this workspace, uses these tools and its actions are marked as machine-assisted. It should not pretend to be a human. It should be a recognizable participant in the system.
That does not mean every agent needs a full employee profile and ceremonial onboarding. It means the system must distinguish a human action, an assisted action and an autonomous step. Without that, audit turns into detective work.
Permissions should be narrow, not convenient
An agent should receive the smallest permissions that let it do the specific job. Reading documents is not the same as sending messages. Proposing a pull request is not the same as merging it. Creating a draft is not the same as publishing. OWASP warns that excessive functionality, permissions, or autonomy can enable damaging actions even after an unexpected model output. OWASP: Excessive Agency
A practical pattern is to separate rights by action: read, propose, request approval, execute. The more irreversible the action, the clearer the human checkpoint or technical brake should be.
Inbox, memory and tools are attack surface
An agent with an inbox, memory and tool use is no longer an isolated chatbot. It reads untrusted input, holds context and can act outward. That is exactly where prompt injection, poorly scoped permissions and an overly generous tool meet in one fire.
So it is not enough to say an agent “has Slack access” or “can send email”. What matters is which channels, under which identity, with which filters, limits, approvals and logs. An integration without boundaries is only a faster route to an incident.
What to remember
Agent identity is not enterprise architecture cosmetics. It is a basic safety and operations layer. An agent should be visible in the system, carry narrow permissions and leave a trail that a human can understand even after midnight during an incident.
Limits
A separate identity and an audit record do not protect a system on their own. They need limited tokens, tool controls, and human approval for sensitive or irreversible actions. A log that omits the decision and outcome of an action is not a usable audit trail either.