Yes, in almost every production setup an AI agent should have its own identity, separate from the identity of the user or system that invoked it. That doesn't mean the agent's identity replaces the user's; it means both need to exist and be tracked together. The agent's identity lets you authenticate the software actor, rate-limit it, detect anomalous behavior, and revoke it without touching the underlying user account. The user's identity is still what should bound what the agent is allowed to retrieve or change on any given call. Treating "the agent" and "the user it's acting for" as the same thing collapses information you'll need later, whether that's for authorization decisions in the moment or for reconstructing what happened after an incident.
What giving an agent its own identity actually buys you
With a distinct agent identity, you can apply controls that have nothing to do with any specific user: a rate limit on how many tool calls the agent makes per minute, an anomaly baseline for what normal behavior looks like for that agent, a kill switch that disables the agent entirely without disabling every user it serves. You can also revoke or rotate the agent's own credentials without cascading through every user session that happens to be using it. None of this is possible if the agent silently borrows a user's session token or a single shared service account for every action it takes.
What it doesn't solve on its own
Giving an agent an identity doesn't automatically make its actions correctly scoped. An agent with its own identity but an overly broad role is just as dangerous as a shared credential, arguably more so, because it looks like a properly designed system from a distance. The agent's identity needs to carry, or reference, the permissions of the user it's acting for at that moment, so authorization checks downstream can evaluate the right boundary. An agent identity without that linkage becomes its own standing privilege, independent of any specific user's actual access.
The delegation relationship needs to be explicit
The cleanest model treats the agent as a delegate: it has its own identity for authentication and operational purposes, but every action it takes carries a reference to who it's acting on behalf of, and authorization is evaluated against that person's or system's actual entitlements. This is the same delegation logic that OAuth-style token exchange handles for conventional applications, just applied to an actor that decides its own next step rather than following a fixed code path.
Multiple agents, multiple identities
When several agents cooperate on a task, treating them all as one undifferentiated blob loses exactly the information you need if one of them misbehaves. A research agent, a drafting agent, and an execution agent performing different roles in the same workflow should each carry an identity that reflects their specific function, so logs and policy checks can distinguish "the agent that read the document" from "the agent that sent the email."
When a shared identity might be acceptable
For very low-stakes, read-only, single-purpose bots, the overhead of full per-agent identity management might not be worth it immediately. Even then, it's worth building toward distinct identities as the system grows, because retrofitting identity separation onto a system that was built assuming one shared credential is far more disruptive than building it in from the start.
Naming and labeling agent identities clearly
A distinct identity only helps if anyone reading a log or an alert can tell at a glance what it refers to. Naming conventions matter more than they sound like they should: an identity labeled with the agent's function and version, rather than a generic label like "bot-1" or an autogenerated UUID nobody can read without looking it up, turns an incident review from a lookup exercise into something immediate. When an alert fires at two in the morning, the difference between "refund-agent-v3" and an opaque identifier is the difference between someone acting in minutes and someone spending the first twenty of them just figuring out what triggered the page.
This also matters for permission reviews. A list of agent identities with clear, consistent names makes it obvious when two entries look suspiciously similar, a sign someone spun up a duplicate instead of reusing an existing identity, or when an old identity is still present long after the agent it named was supposed to be retired. Consistent naming won't catch every problem, but it removes a surprising amount of friction from the reviews that do catch them.
Where TELEON fits
TELEON's gateway evaluates policy using whatever identity is presented to it at the point of a tool call, and it keeps an audit trail tied to that identity. When an agent has its own distinct identity and correctly carries the originating user's context, that audit trail can distinguish which agent did what, and on whose behalf, rather than recording a single undifferentiated actor.
The decision to give an agent its own identity, and the mechanism for linking that identity to the user it's delegating for, is an architectural choice each team makes based on its own service topology.
A short checklist
- Assign every agent a distinct, authenticatable identity separate from any user.
- Carry a reference to the originating user or system in every agent action.
- Evaluate authorization against the delegated user's permissions, not just the agent's own role.
- Apply rate limits and anomaly detection at the agent identity level.
- Give distinct identities to distinct agent roles in multi-agent workflows.
- Build toward per-agent identity early, even for simple bots, rather than retrofitting later.
- Ensure the agent's identity can be revoked independently of any user session.
An agent's own identity is a tool for accountability and control, not a substitute for correctly scoped authorization. The real question isn't whether to give an agent an identity, it's whether that identity is wired up to actually constrain what the agent can do, or whether it just adds a name to logs that don't reflect any real boundary.