Why AI Agents Must Never Choose Their Own Acting Subject
AI agents shouldn't self-assign identity via tool arguments. Learn why acting subjects must come from trusted boundaries, not model output.
A syntactically valid tool call from an AI agent can still lack a legitimate identity behind it. A user_id written into the arguments by the model is not a cryptographic proof of authority — it's an untrusted string. The core issue is that a single invocation often conflates three distinct identities: the requesting human or business principal, the agent's client/service identity, and the acting business subject the system must actually authorize against.
Model-generated identity is unreliable because it can be corrupted by ambiguous language, stale memory, prompt injection in retrieved content, or plain hallucination. A trustworthy acting subject must instead come from a verified system boundary — an authenticated session, a signed delegation ticket, or an enterprise identity provider — never from text the model is merely interpreting.
The practical fix is separating model-controlled arguments (like order_id and amount) from trusted invocation context (subject_id, delegation, tenant_id), and hiding subject-required capabilities such as refunds or data exports from the agent entirely when no trusted subject exists. Because tasks can be paused, retried, or resumed across workers, the acting subject must be re-verified at every consequential step; otherwise a re-run after approval could silently authorize a different identity.
Establishing a trusted subject only answers who the system is acting on behalf of — it does not replace business authorization. Whether that subject is actually permitted to perform the specific action still requires RBAC/ABAC-style checks. The takeaway for engineers: identity boundaries and business-logic boundaries must never be merged into the same trust surface as ordinary tool arguments.