AI Agents Need an Authority Map, Not Just Permissions

I think we are using the word permission too narrowly. When an AI agent gets access to a calendar, inbox or credit card, the important question is not only what the software can reach. It is what the software is allowed to decide.

That distinction is becoming urgent. Agents are being placed closer to payments and communication, AI tools are making it easier to create and distribute products, and autonomous transport is moving from a technical demonstration towards an operating service. At the same time, security incidents keep showing how weak identity checks and unclear processes can turn legitimate access into damaging action. The product conversation is also returning to basic questions about responsibility, team systems and measurement. These developments belong together.

Access is technical. Authority is organizational.

A support agent may have access to customer records, but does that give it authority to issue a refund? A growth tool may have access to campaign software, but can it change a live audience, increase spend or send a message? A pricing agent may be able to edit a discount, but who accepted the margin impact?

Those decisions were previously attached to roles. A support manager defined refund limits. A campaign owner approved spend. A commercial leader accepted pricing exceptions. When we automate the action, that responsibility does not disappear. It becomes less visible.

This is why I would require an authority map before putting an agent into a live workflow. For every action, I want to know whose authority is being delegated, how far that delegation extends, what economic or customer consequence it can create, and who reviews exceptions. I also want to know whether the action is reversible. Sending a draft for approval and sending an email to ten thousand customers may use the same integration, but they are not remotely the same product decision.

A normal permission model will not capture this. It will tell us that the agent can write to the campaign platform. It will not tell us whether it may launch a campaign on a Friday afternoon, use an unapproved claim or consume the remaining monthly budget. Those are operating rules, not API scopes.

The same problem appears in measurement. Teams will naturally report how many tasks an agent completed or how much time it saved. Those figures can look good while the organization quietly absorbs more reversals, customer complaints and manual exception handling. Completion is not a useful outcome if another team has to inspect and repair the result.

I would therefore measure delegated work differently from assisted work. If a person still approves the final action, I care about decision quality and review time. If the agent acts independently, I also care about reversals, exceptions, financial exposure and the amount of operational work created elsewhere. Autonomy changes the measurement obligation.

This should not make the product manager the owner of every automated decision. Product should make the authority transfer explicit, engineering should enforce it, and the relevant business owner should accept the trade-off. If nobody is prepared to own that authority, the agent is not ready to receive it.

The current debate often presents AI adoption as a choice between moving quickly and adding safeguards. I think that is too simplistic. Clear authority usually helps teams move faster because they no longer need to debate every individual action. The agent can operate freely inside a defined mandate, while unusual or expensive decisions move to a person with the right context.

We already know how to run organizations through delegated authority. We use approval limits, budgets, role definitions and escalation paths. The mistake is treating AI agents as software users rather than new holders of that delegated authority. Before giving an agent another integration, I would first ask a more difficult question: whose decision is it about to make?