Before rollout, map what an agent can actually do

Start with the action and its consequence

Describe the proposed workflow in ordinary language. Does the agent assemble information, recommend a choice, prepare a transaction, or execute it? Identify the point at which its work affects a customer, employee, record, or business commitment. This gives the review a concrete object.

Consider a hypothetical purchasing assistant. Comparing supplier quotes, drafting a purchase order, submitting the order, and changing payment details are four separate actions. A team may approve the first two for a pilot while reserving submission for an authorized employee. Write those boundaries explicitly.

Trace the tools and identities behind the action

Ask the implementation team to walk through one realistic task. Record each tool the agent can call, the identity it uses, the data it can reach, and the changes that identity permits. Include other agents or services that receive delegated work. A workflow diagram becomes useful when it connects these details to an actual action.

OWASP’s Excessive Agency guidance identifies unnecessary functionality, permissions, and autonomy as sources of risk. It recommends limiting tool capabilities and enforcing appropriate permissions in downstream systems. Use that guidance to frame the technical review; the questions below are our suggested starting point.

• Can the tool perform writes or sends when the intended task only needs reads?
• Does the connection use the initiating person’s authority or a shared service identity?
• Where is a disallowed action blocked, and what record shows the block worked?
• Could a sequence of permitted tool calls create a commitment that requires separate approval?

Test the boundary as well as the successful task

For the purchasing example, ask the team to attempt an order submission during the drafting-only pilot. Check the result in the purchasing system and its action logs. Record whether the operation was prevented, who received any escalation, and whether another route remained available. A statement in an instruction is evidence of intent; a demonstrated permission check is evidence about enforcement.

Give the pilot owner a short set of review questions: which actions remain available, which are withheld, what evidence supports the boundary, and who can authorize a change? Include unresolved access questions in the rollout decision. The business sponsor can then see what authority the proposed automation would carry.

Make expansion a deliberate decision

Revisit the map whenever a new tool, identity, or action is introduced. Ask whether it changes the consequence of a mistake and whether the original approval still covers the workflow. Broader access deserves an explicit owner and a review of the affected boundary. This keeps the discussion tied to the authority being delegated as the workflow develops.