User identity answers who a request is ultimately for. Agent identity answers which piece of software actually made the call. They sound similar, and in a lot of system diagrams they get merged into one box labeled "the AI," but conflating them removes exactly the information an authorization system needs to make a correct decision. A support agent acting on behalf of a customer needs its access bounded by that customer's actual permissions, not by whatever broad role the agent's own service account happens to carry. Getting this distinction right is the difference between an agent that can only do what its user could already do, and an agent that quietly becomes a more powerful actor than any human using the system.
What user identity represents
User identity is the accountable party: the person or, in some cases, another system, whose intent the request is supposed to reflect. It's what most existing authorization logic already understands, tenant boundaries, role assignments, data ownership, because it's built on decades of application security practice. When an AI agent acts on a user's behalf, the whole point of propagating that identity is so every downstream check can keep using the same logic it already trusts, instead of inventing a parallel authorization model just because an AI is involved.
What agent identity represents
Agent identity is the operational actor: the specific software instance, version, or deployment that executed the call. It matters for reasons that have nothing to do with any individual user: monitoring for unusual behavior, applying rate limits, revoking a compromised or misbehaving agent without touching every user it happens to serve, and attributing an incident to a specific agent version rather than "the AI system" in the abstract. Two different agents acting for the same user should still be distinguishable in logs and policy decisions.
Where the two have to intersect
Every meaningful authorization decision an agent makes needs both pieces of context at once: which agent is asking, and on whose behalf. A tool call that only checks the agent's identity risks granting access the underlying user was never entitled to. A tool call that only checks the user's identity, with no visibility into which agent or agent version made the request, loses the ability to detect that a specific misconfigured or compromised agent is the actual source of a problem. Systems that get this right pass both identities through the whole request chain and log both at every decision point.
What goes wrong when they're collapsed
The most common failure is authorizing purely on the agent's service account, because it was simpler to configure one broad role for "the AI system" than to propagate individual user context through every hop. That pattern grants the agent access matching its own service account rather than the specific user it's currently serving, which is almost always broader than intended. The reverse failure, ignoring agent identity entirely and authorizing only on user identity, still leaves you blind when the same user's requests start behaving differently because the agent itself was changed, updated, or compromised.
A useful mental model
Think of user identity as the "on whose authority" question and agent identity as the "which actor executed this" question. A court needs both: who ordered the action, and who carried it out. Dropping either one from the record makes the other significantly less useful, because you either can't tell if the action was properly authorized, or you can't tell which specific execution path caused a problem.
Testing the distinction directly
The cleanest way to confirm user identity and agent identity are actually being tracked separately, rather than merged somewhere in the middle of the request chain, is to test it directly. Have one user with narrow permissions and another with broad permissions both send a structurally identical request through the same agent, and confirm the two get different, correctly scoped results. If they come back the same, authorization is very likely keying off the agent's identity instead of the user's, and no amount of correct-looking logging will fix that until the actual authorization check is corrected.
It's worth running this test again after any change to the agent's framework, its tool integrations, or the service mesh it runs on, because identity propagation is exactly the kind of thing that can silently break during a refactor that looked unrelated. A test that passed once during initial design isn't the same as a test that still passes after six months of incremental changes made by people who weren't thinking about identity propagation at all.
Where TELEON fits
TELEON's policy enforcement at the tool-call boundary is only as accurate as the identity context it receives. When an application propagates both the originating user's identity and the calling agent's identity into that request, TELEON's audit trail and policy decisions can reflect both, rather than treating every call as coming from one undifferentiated source.
Deciding how user identity and agent identity get generated, signed, and passed through a given architecture remains application-level design work outside what a policy layer alone can fix.
A short checklist
- Track user identity and agent identity as two separate values, not one merged field.
- Authorize tool calls against the user's permissions, not just the agent's service role.
- Log both identities at every policy decision point.
- Apply rate limiting and anomaly detection at the agent identity level.
- Ensure agent identity survives updates and redeployments in a traceable way.
- Test that user permission changes actually affect what the agent can do on their behalf.
- Review logs periodically to confirm both identities are consistently present, not dropped at some hop.
The distinction between user identity and agent identity isn't academic. It shows up the first time someone asks "why did the agent access that record" and the honest answer depends on knowing exactly whose permissions were supposed to apply and which specific agent instance made the call. Systems that track both from day one answer that question in minutes. Systems that didn't usually can't answer it at all.