Agent systems need distinct identities for runtime, provider, principal, operator, and beneficiary, plus a separate account of practical influence.
Why this question matters
NIST frames agent identity and authorization as an emerging enterprise security problem because agents reach across data, tools, and applications. A cryptographic workload identity can authenticate the running process, but it does not by itself state whose interests the process is serving for this action.
Conflating these roles makes conflicts invisible. A shopping agent may be authenticated by a platform, delegated by a consumer, optimized by a merchant-funded model, and hosted by a separate cloud operator. Every identity can be valid while the relationship remains misleading. Agents can also have unequal practical power even when their formal roles look equal. A more capable model may persuade peers more effectively, while an orchestrator may give one agent earlier turns, more retries, a larger token or spending budget, access to shared memory, or the final right to execute. The machine equivalent of a louder voice is control over attention, persistence, and action.
Signals worth observing
- One agent identifier is used for actions belonging to several principals.
- The beneficiary of a decision differs from the delegating user.
- One participant receives more turns, retries, context, or execution authority than its peers.
Practical control direction
- Model principal, operator, provider, runtime, and beneficiary separately.
- Bind each action to a current delegation and record speaking order, repetition, memory writes, budget, and execution rights.
- Disclose material conflicts at selection and approval time.
AgentCollusion lensCollusion analysis asks not only which agents communicated and which interests aligned behind them, but whose voice could actually shape the group outcome.
