An agent needs its own identity so its permissions can be defined separately from the person using it. A delegated action should remain within both the agent’s assigned role and the human’s authority.

Why the user’s login is not the whole story

A person may have access to many systems while a particular agent has a narrow purpose. Giving the agent every permission the person holds expands the workflow unnecessarily. Conversely, an agent’s wider service permissions should not let a person perform an action they are not entitled to request.

The intersection of two permission sets

Consider an account reviewer who can read records, and an account assistant agent that can read or update records. When acting for that reviewer, the agent may read. It may not update, because the human’s role does not authorize that operation.

The rule

Effective authority = actions permitted to the human and actions permitted to the agent.

What context should travel with an action?

  • The identity of the person delegating the task.
  • The identity and role of the registered agent.
  • The requested operation and target resource.
  • The relevant policy and approval requirements.
  • The result of the authorization decision.

Keeping this context distinct allows a reviewer to understand delegation without treating the agent as the human. It also helps teams investigate which boundary or policy affected a decision.

Questions for your next design review

  1. Does every agent have a defined purpose and role?
  2. Can you identify the person behind a delegated action?
  3. Are permissions checked for the particular operation and resource?
  4. Can a tool call exceed either identity’s authority?
  5. Can the team review how a decision was reached?

See the dual-identity model

AGMIO AIM keeps human and agent identities in view when evaluating delegated authority. Explore the identity solution to try a simple permissions example.

Further reading

OWASP: Least-privilege controls for AI applications