Access to a tool does not give an AI agent the right to act.

The most important question about an AI agent is no longer:

How intelligent is it?

It is:

What can it do—and who decided it was allowed to do that?

An agent connected to email, CRM, files, code, payments or internal APIs is not simply a chatbot with better UX. It is a software actor with potential consequences.

The moment it can call a tool, capability and authority separate.

A customer-service agent may technically be able to:

• read an order;
• change an address;
• issue a refund;
• send an email;
• cancel a subscription.

That is its capability surface.

Its authorized surface should be smaller and contextual.

Perhaps it may read an order for the authenticated customer. Perhaps it may prepare a refund but not send it. Perhaps it may execute refunds below a threshold and escalate higher-value cases. Perhaps it may not expose internal fraud notes at all.

If we collapse “can” into “may,” the architecture is already wrong.

MCP standardizes how AI applications can connect to external resources and tools. Its authorization specification uses established OAuth mechanisms for HTTP transports and emphasizes resource-specific tokens and validation.

Source context: MCP · authorization specification · 2026-07-28 ↗

A2A addresses a different layer: agents discovering, communicating and coordinating with other agents. Created by Google and now hosted by the Linux Foundation, the protocol has reached v1.0 as an open interoperability standard for agent-to-agent communication across vendors, frameworks and enterprise environments.

Source context: Agent2Agent · v1.0 specification ↗

Protocol compatibility does not settle organizational authority. A valid Agent Card, tool description, OAuth token, registry entry or signed metadata can improve interoperability and identity/security properties; it does not answer whether this agent may take this action for this organization, on this subject, at this consequence level.

This interoperability is useful. It also means the permission graph is becoming more complex.

An agent may have:

MODEL CAPABILITY + TOOL CAPABILITY + DATA ACCESS + PEER-AGENT ACCESS + USER CONTEXT + ORGANIZATIONAL ROLE.

None of those should automatically grant business authority.

OWASP’s LLM Top 10 describes “Excessive Agency” as a risk created when systems have excessive functionality, excessive permissions or excessive autonomy. Its Agentic Top 10 goes deeper into goal hijacking, tool misuse, identity and privilege abuse, supply-chain vulnerabilities and unexpected code execution.

Source context: OWASP Top 10 for Agentic Applications 2026 ↗

The design lesson is not “agents are unsafe.”

It is that agents need the same discipline we already expect from serious systems—plus new controls for natural-language instructions, dynamic tool selection and probabilistic behavior.

A useful authority record answers:

WHO is acting? FOR WHICH organization or tenant? FOR WHICH Mission? ON WHAT subject? USING WHICH tool or capability? FOR WHICH action? WITH WHAT limit? UNTIL WHEN? UNDER WHICH approval condition? WITH WHAT consequence class?

This is much more precise than “the agent has access to Salesforce.”

Access is infrastructure. Authority is a business and governance decision.

A simple principle:

Higher consequence should not require less control.

If an agent moves from recommending to preparing to executing, required authority should not decrease.

If data becomes more sensitive, disclosure controls should not become weaker.

If a permission is revoked, execution should not remain stronger because a cached workflow still thinks the permission exists.

If an input contains an unsupported or malformed safety state, the system should fail closed rather than default to the most permissive interpretation.

These are not philosophical rules. They are testable properties.

Another critical boundary:

An agent should not be able to create the evidence that proves its own authority.

The same applies to verification.

A model may report “I completed the task.” That is an execution claim.

The organization may still need independent observation:

Did the CRM actually change? Was the correct customer updated? Was the action inside the approved amount? Did the payment settle? Was the required human approval recorded?

Execution claim ≠ observed outcome.

Requiring human approval for every agent action defeats much of the economic value.

Requiring none is irresponsible.

The goal is calibrated review.

Low-consequence, reversible, well-evidenced actions can often receive bounded autonomy. Higher-consequence or ambiguous actions should require stronger authority or human review. Protected human, safety, privacy and legal boundaries may veto an economically attractive action.

The art is not “human in the loop” as a slogan.

It is knowing which human, at which point, for which decision, with which evidence.

Agentic systems can amplify a broken workflow as efficiently as a good one. McKinsey’s September 2026 scaling guidance makes the operating point explicit: many enterprises are scaling agents faster than they redesign the work underneath. For an authority model, that means autonomy should follow task/workflow design, data readiness, build-vs-buy choices, decision rights and escalation—not substitute for them.

Not every task needs an agent. A task may be better served by deterministic automation, analytical models, generative assistance or agentic execution. Human authority is orthogonal to all four: the organization still decides what may happen, under which conditions, and who is accountable.

An agent's permission should have a lifecycle. Somebody grants it for a purpose, it applies to a defined set of actions, and it expires or is withdrawn when the conditions change. This sounds obvious until a project connects a shared service account and leaves the connection running indefinitely. The service account may remain valid after the original sponsor changes role, the pilot ends or the tool gains a new capability.

Begin with the smallest useful delegation. A procurement assistant might read approved supplier documents and prepare a comparison. Preparing a purchase order is a separate permission; submitting it is another. The organisation can gain useful support from the first two activities while reserving commitment of funds to an existing purchasing workflow. There is no need to choose between an unconnected chatbot and unrestricted automation.

Withdrawal must work at the moment an action is attempted. Removing an agent from a dashboard is insufficient if an active session, queued task or cached credential can still write. Test whether the permission is rechecked after a delay, after an approval is cancelled and after the underlying customer record changes. Record the expected behaviour for each case before testing. A result is easier to assess when the team has agreed what should happen.

Imagine an internal assistant asked to reorder equipment for a new employee. It can find the approved catalogue, check the department's budget and prepare a draft order. A manager approves a particular laptop, quantity and price. Before the order is placed, however, the supplier changes the price or substitutes an item. The old approval should not silently authorise a different transaction.

A useful design binds the approval to the relevant details: buyer, supplier, item, quantity, price limits and validity period. Material changes return the order for review. Repeating the request should recover the existing order state rather than create another purchase. If the supplier returns an ambiguous response, the workflow should reconcile the transaction before retrying. These are proposed operating controls, not claims about any particular vendor's implementation.

The same scenario exposes the danger of loose delegation between agents. A planning agent may ask a purchasing agent for help, but the request does not create a budget or a purchase entitlement. Each recipient still needs to check the authority that applies to its own action. A well-written instruction from another agent should never be treated as a higher permission than the organisation actually granted.

A review screen should summarise the proposed action, its consequence, the evidence used and the reason approval is needed. A long conversation log can help an investigation, but it is a poor default decision interface. The reviewer needs to see the exact object that will change and the difference between its current and proposed state. Important uncertainty should appear alongside the action, not below a reassuring completion message.

Give the reviewer an effective choice: approve the bounded action, change the proposal, request evidence or refuse it. Show when an approval becomes invalid. Where a reviewer is expected to examine every case, measure the queue and the attention required. Calling a process “human reviewed” does not establish that people have enough time, information or authority to challenge it.

The European Data Protection Supervisor's discussion of automated decisions distinguishes meaningful involvement from a procedural formality. Its context is data protection, not a universal agent design standard. The operating lesson is nevertheless useful: adding a person to a diagram is weaker than demonstrating what that person can actually understand and change. Human oversight source.

Use a test matrix organised around consequences. Include an ordinary permitted action, a forbidden action, a missing approval, an expired approval, a different tenant and a changed underlying record. Also test an instruction hidden in retrieved content and an attempt to call a tool that the agent can discover but may not use. The expected outcome is a specific allowed, denied or escalated state, rather than a generic assertion that the agent behaved safely.

Observe the downstream system independently. A model's explanation of why it respected a limit can be helpful, but it does not prove that the external write was blocked. Check the actual records and audit trail. Keep a record of the model, connector and policy versions used so that a later test can explain what changed. Preserve failures as evidence instead of selecting only successful demonstrations.

Include service recovery. If the model is unavailable, can staff still complete the underlying business process? If a connector is disabled, does the assistant explain which actions are unavailable? An orderly fallback protects the business without pretending that a queued or prepared action has been completed. This is a practical requirement for assisted operations, not an argument for automating every exception.

Before expanding access, put three examples in front of the workflow owner: an ordinary action, an action at the limit and an action outside it. For each, show the actor, the subject, the evidence and the expected external change. Ask the owner to explain the decision without relying on the model's narration. If the boundary cannot be explained, it is not ready to become a wider delegation.

Then change one relevant detail. Replace the customer, increase the amount, expire the approval or move the request to another organisation. The result should follow the changed condition. This checks whether the implementation is using the actual permission or merely reproducing a familiar example. Record the external observation, not only the assistant's response.

Finally, ask who can revoke the delegation during ordinary operations and how staff learn that it has changed. The answer should name a role and a practical path. An emergency mechanism that only the original developer understands is a fragile operating control. Preserve the review alongside the permission so that a future owner can inspect both its purpose and its limits.

When exploring providers in the Good AI Prism, compare the relevant deployment and permission evidence rather than relying on the word “agent.” Ask which controls are configurable, which are enforced by the provider, which require your own integration and which remain undocumented for the proposed plan. Keep these distinctions in the comparison and in the supplier question list.

For a bounded implementation discussion, the AI Trust Pilot concerns one use case with agreed responsibilities and review boundaries. An AI Decision Brief is a smaller starting point when the immediate question is which options deserve further inspection. The brief is requested and confirmed by Sten; its delivery window starts with confirmation of a complete request. Neither service grants an agent permission to operate your systems. That authority remains a deliberate organisational decision.

Before an agent receives a tool, ask:

What Mission does this tool support? What exact action is needed? What is the minimum permission required? What data can the action expose? What is reversible? What is the blast radius? What requires approval? What happens when authority expires? How do we observe the result independently? How do we replay the decision later?

If those answers are unclear, the problem is not the model.

The problem is the operating design around it.