The Agent's Tool List Is Not Its Authority Model

An agent demo often ends with a satisfying inventory: it can search documents, read CRM records, draft email, open a support ticket, and submit a change through an API.

That inventory proves reach. It does not prove authority.

Authentication answers which actor is making a request. Authorization decides whether that actor may perform this operation, on this resource, under these conditions, now. A production agent needs both, plus a traceable link to the person or declared business purpose that authorizes the action.

Every consequential agent action therefore needs an authority chain. A forward-deployed team should make that chain explicit before expanding access, not reconstruct it after an incident.

Agent authority is becoming a production control

Google Cloud's August 24 security-governance note opens from a blunt operating fact: enterprises let agents read internal data and invoke real actions. The controls surrounding that access are now taking shape across public standards work and competing platforms.

NIST's February 2026 concept paper asks how an agent should prove authority for a specific action, how delegated authority should work when an agent acts on someone's behalf, how human identity should bind to approvals, and how actions should remain auditable. NIST is asking questions, not declaring a finished standard. Those questions still form a practical deployment review.

AWS argues that deterministic external controls should enforce agent boundaries outside the model's reasoning loop. Instructions such as “do not approve payments above this amount” can guide behavior; they are not the enforcement layer.

Google Cloud's current IAM model gives agents a principal distinct from human identities and generic service accounts, then applies policy at agent-to-tool connections. Microsoft's agent-identity guidance adds named human sponsors, approval workflows, time-bound access, and lifecycle controls.

These implementations are vendor-specific. My read of the shared pattern is that a deployable control model needs five things: a distinct agent identity, an authorizing principal or purpose, policy enforced outside the model, human accountability for consequential boundaries, and a lifecycle that includes expiry and revocation.

One action can involve three identities

Suppose an agent prepares a supplier record in an enterprise resource planning system. At least three identities may be involved:

• the agent identity, which says which deployed system initiated the request;
• the authorizing principal, which says which user or role delegated authority—or, for an autonomous workflow, the declared business purpose and accountable sponsor; and
• the application or tool identity that authenticates the actual API call.

If those identities collapse into one broad service account—or worse, a copied employee credential—the logs may show that the ERP accepted a request without showing which agent acted, whose authority it used, or whether the operation belonged to the approved workflow.

A distinct agent identity improves attribution. It does not finish the design. The authorization decision still has to bind that identity to an allowed operation, resource, context, and approval rule.

Build an authority ledger, not only a tool inventory

Keep the tool inventory. Add one authority-ledger row for every action that changes money, records, access, commitments, customer communication, or production state.

Consider a hypothetical supplier-onboarding agent. It can read documents only from an approved intake queue and propose values for a draft supplier record. Read and propose do not confer create or approve. The agent may create the record only after the procurement owner approves the legal entity and the finance owner approves payment instructions. A bank-account change always escalates and cannot be self-approved. Access expires at the end of the bounded deployment unless the sponsor renews it. The evidence record links source documents, proposed values, approvals, the policy decision, the API response, and any exception.

This example does not prove the workflow is safe. It makes unresolved decisions visible enough to assign and test.

Review the ledger with four failure questions

Can we attribute the action? The team should distinguish the agent, the authorizing principal or purpose, and the tool credential. “Automation account” is not enough when several workflows or teams share it.

Does the agent have the least authority the workflow needs? Scope should follow operations and resources, not the maximum permissions of the employee who configured the demo. Read, propose, create, approve, and execute are different authorities. Separate them where the consequence warrants it.

Is the boundary enforced outside the model? Prompts, natural-language policies, and model reasoning traces can inform a decision. Deterministic controls should still enforce allowed operations, approvals, resource boundaries, and denial. The agent should not judge whether its own exception is acceptable.

Can authority end cleanly? Name the sponsor, review date, expiry behavior, credential-revocation path, and incident stop owner. Microsoft's sponsor and expiration model is a useful reminder: production access is a lifecycle, not a launch event.

The FDE handoff should contain proof of control

For a consequential agent workflow, a repository and runbook are not a complete transfer. The receiving team should get:

• the authority ledger linked to the architecture and workflow specification;
• machine-enforced policy configuration with named owners;
• negative tests proving that a wrong principal, forbidden operation, expired authority, missing approval, changed context, and prompt-injection attempt are denied;
• an emergency-revocation test showing that access ends without breaking unrelated work;
• logs that capture authorization decisions and tool results, not only model traces; and
• acceptance from the product owner, identity or security owner, workflow operator, and production-support owner.

Those artifacts let a buyer distinguish a persuasive demo from a governable deployment. They also expose a legitimate stop decision. If the team cannot identify the authorizing principal, constrain the operation, obtain required approval, or revoke access, the next move is not another connector.

A tool connection proves that an agent can reach a system. An authority model makes its actions attributable, bounded, testable, and reversible.

Before adding the next tool, choose one consequential action and complete its authority-ledger row end to end. The result may be autonomous execution, an approval-gated action, or a defensible decision not to deploy it. All three are better than treating connectivity as consent.