# How Should Enterprises Design Per-Decision Authorization for AI Agent Tools?

Savannah Jenkins · September 25, 2026

> Direct Answer: Treat Every Agent Action as a Separately Authorizable Request The safest architecture for agent tool authorization is to evaluate each...

## Direct Answer: Treat Every Agent Action as a Separately Authorizable Request

The safest architecture for agent tool authorization is to evaluate each consequential action at execution time, rather than granting an agent broad access to an API, database, MCP server, or internal website for the duration of a session. The authorizing service should receive the authenticated human or workload identity, the specific tool and operation, target resource, requested scope, relevant data classification, session risk, and approval state. It should return a time-bounded decision such as allow, deny, or require human approval, together with conditions that the runtime must enforce. This is commonly called per-decision authorization, and it adapts long-established policy models such as XACML and ALFA to AI systems whose plans and tool calls are dynamic. It is not enough to ask whether an agent may use a category of tool. A research agent that may search public documents should not automatically be allowed to export the same agent’s results to a customer record, invoke a payment API, or alter an ERP transaction.

**Also worth reading:** [What are MCP token scoping patterns and how do they secure AI agent authorization in enterprise systems?](https://agustin-otegui.com/knowledge/what_are_mcp_token_scoping_patterns_and_how_do_they_secure_ai_agent_authorization_in_enterprise_systems.php) · [How should enterprises design agentic infrastructure for production in 2026?](https://agustin-otegui.com/knowledge/how_should_enterprises_design_agentic_infrastructure_for_production_in_2026.php) · [What Are AI Agent Control Planes and How Should Enterprises Choose One?](https://agustin-otegui.com/knowledge/what_are_ai_agent_control_planes_and_how_should_enterprises_choose_one.php)

A practical rule is to authorize at the narrowest stable action boundary. For a file tool, that may mean read versus write and one directory versus another; for a cloud API, it may be the HTTP method, route, account, and object; for an MCP server, it may be the named tool plus its validated arguments. Use automatic evaluation for low-impact reads, step-up approval for bounded changes, and deny-by-default execution for destructive operations. The design should also separate identity, policy decision, and policy enforcement: an identity provider establishes who is acting, a policy decision point evaluates whether that identity may perform that action now, and a gateway or runtime enforces the result. This separation reduces the chance that a prompt injection turns into unauthorized access merely because the surrounding conversation had elevated privileges.

## Core Authorization Model: Identity, Intent, Scope, and Time

Agent authorization needs more than an API key attached to a model or agent. A useful decision model has four layers: authenticated principal, requested action, policy context, and decision constraints. The principal may be a human employee, a service account delegated by that employee, or another agent acting under a workload identity. The action should identify the exact tool, operation, resource, and requested fields or records. Context can include tenant, geography, device posture, authentication strength, session age, prior denials, data sensitivity, transaction amount, and whether the request came through an untrusted document or web page. Constraints can limit the decision to 30 seconds, 10 minutes, or one transaction, restrict the response to 20 records, prohibit writes, or require reauthorization after the tool schema changes.

Attribute-based access control is usually more appropriate than maintaining a large role matrix for dynamic agents. Roles can still provide coarse grouping, but attributes express why access should be granted now. For example, an account analyst may read invoices for business unit 42 during normal working hours, while an invoice agent may submit only invoices below $5,000 and only when the source document has passed validation. Traditional RBAC answers “Does this workload have the AP role?” while an attribute-aware decision can answer “May this workload submit invoice INV-8821, for $3,200, on behalf of analyst 17, using source document D-90, during this approved workflow?” This is especially important for multi-agent workflows, where one agent may plan an action, another may retrieve data, and a third may perform the write. A2A-style agent messaging can carry identity and authorization metadata, but the protocol alone does not decide whether a downstream action is safe.

The policy decision should be deny by default for tools that can mutate data, execute code, send communications, access secrets, or move money. Read-only discovery tools can begin with allow-by-default under controlled egress, logging, rate, and data-loss restrictions, but that is a risk choice rather than a universal best practice. Keep a small emergency role outside the normal agent path, test it regularly, and alert on every use. Avoid embedding authorization only in natural-language system prompts: a model instruction is not a reliable enforcement boundary because prompts can be ignored, misinterpreted, overwritten, or influenced by untrusted content.

## Reference Architecture and Request Flow

A production design normally includes an identity provider, agent runtime, policy decision point, policy enforcement points, tool gateways, secrets manager, approval service, and audit pipeline. The agent runtime constructs a canonical authorization request when a model selects a tool. A policy-aware gateway validates the request and enriches it with trusted attributes before forwarding it to the policy decision point. The decision point evaluates the tool binding, principal, resource, action, environment, and workflow state, then issues a signed decision. The gateway enforces the decision, applies argument limits, injects short-lived credentials, and records the outcome. MCP gateways can reduce the number of direct agent-to-server connections, but they do not replace authorization; a gateway that merely routes traffic is not automatically a policy enforcement point.

Tool binding should identify not just the tool name but the specific implementation and deployment that the agent is permitted to invoke. A name such as update_customer is ambiguous if several MCP servers expose that label. Bind the decision to the server identity, canonical tool name and version, normalized arguments, target tenant, and credential audience. Schema validation should occur before authorization and again immediately before execution, because a model can emit malformed or unexpected fields. Secrets should be retrieved only after approval and should be scoped to the approved resource and operation. A 10-minute database credential should not silently become the identity used for a shell command or unrelated cloud account.

The flow should also account for chained actions. Suppose an agent retrieves a customer record and then calls a messaging tool. Reading the record may be allowed, while sending externally may require a different purpose, destination restriction, or human confirmation. Carry purpose and data-flow labels across the workflow so that sensitive context is not laundered through an intermediate tool. For high-risk plans, use a planning phase in which the agent proposes actions without execution credentials, followed by an execution phase in which each action is independently checked. This pattern preserves useful autonomy for reversible work while preventing a single mistaken plan from obtaining unrestricted access.

| Feature | Session-level authorization | Per-decision authorization |
| --- | --- | --- |
| Granularity | Access to a tool or server for a session | Exact operation, arguments, resource, and time window |
| Main weakness | Prompt injection can reuse broad permissions | More policy, latency, and runtime enforcement work |
| Best use | Sandboxed, read-only experimentation | Production agents touching enterprise systems |
| Approval model | Usually granted before the session | Can vary by action, risk, amount, or data class |
| Auditability | Shows session identity and broad tool use | Links each decision to a concrete action |
| Typical cost | Lower initial engineering cost | Higher integration and testing cost, lower breach exposure |

## Policy Evaluation, Approval, and Enforcement
A robust decision pipeline has six recurring stages: authenticate, validate, evaluate, approve when necessary, execute, and audit. Authentication should use phishing-resistant methods for administrators and short-lived workload credentials for agents. The runtime must distinguish an agent’s claimed intent from attributes obtained from trusted infrastructure. Policy evaluation should use canonical inputs, deterministic rules where possible, and machine-readable outputs. A decision may allow the request, deny it, redact or reduce its scope, or route it to a human approver. “Allow with constraints” is valuable because an approval system often sees the proposed action more clearly than the authorizing policy service.

Human approval should be meaningful rather than a button that confirms an opaque request. The approver interface should display the agent identity, initiating user, tool, arguments, affected records, expected data disclosure, estimated financial impact, and a diff or preview of the change. Bind the approval to a hash of that exact request; if the arguments change, the approval should expire. Use short approval windows, such as five minutes, and require a fresh decision after context or tool implementation changes. For lower-risk actions, organizations can set monetary and data thresholds: for example, automatically allow reads of at most 100 non-sensitive records, permit exports of up to 1,000 records only for approved roles, and require review for more than 10,000 records or any write to a production financial system.

Enforcement must happen where actions actually occur. A policy decision that exists only in a central control plane is ineffective if a tool can be called directly. Remove or protect bypass routes, rotate credentials, validate server identity, and test alternate endpoints. Log policy version, decision ID, principal, tool version, normalized arguments or their secure hash, resource, outcome, approver, and timestamp. Logs should be written to append-only storage with access controls, because an attacker may attempt to erase evidence. Record failures as well as successes, especially repeated denials and unusual tool sequences. Metrics should measure authorization latency, approval rates, denied actions, step-up frequency, policy conflicts, and bypass attempts.

## Practical Implementation Steps for an Enterprise Pilot

Start with one bounded workflow and an explicit risk budget. Good candidates are internal search, report generation, or read-only ERP analysis; avoid beginning with unrestricted shell access, production database writes, customer communications, or payments. Draw a map from user to agent, model, tool, data source, destination, and service account. Remove shared credentials and replace them with identities that can be revoked independently. Then define 10 to 20 high-value policy cases, including ordinary reads, cross-tenant access, bulk export, destructive writes, and an injected instruction that attempts to escalate privileges. Each case should have an expected decision and an automated test.

Next, build a canonical request format and a policy decision point that can be called from a gateway. Add a runtime wrapper around every tool so that no developer can bypass the check accidentally. During the first 30 to 60 days, run the new authorization layer in monitoring mode: record what would happen without blocking production work, then review disagreements between the existing model and the proposed policy. Target false positives below roughly 5% for routine actions and 100% blocking of known high-risk cases before enabling enforcement. These are operating targets, not universal standards, and teams should measure them against their own risk and throughput requirements.

After shadow evaluation, enforce low-risk decisions first, then introduce step-up approval and write restrictions. Test not only the policy engine but also token expiry, gateway retries, concurrent approvals, tool-version changes, regional data rules, and failure behavior. A timeout should fail closed for sensitive tools; it should not fail open merely to preserve agent uptime. Keep an incident runbook that identifies how to disable one tool, revoke one agent, suspend a workflow, and preserve evidence. Revisit the policy monthly during a pilot and at least quarterly after production deployment, because tool schemas, data classifications, and organizational responsibilities change faster than many static access reviews.

## Comparison With RBAC, API Keys, Sandboxes, and Human Approval

Per-decision authorization is not a replacement for every other control. RBAC is useful for assigning broad responsibilities and managing users at scale. API keys establish a credential, but they do not determine whether the current request is appropriate. Sandboxes limit blast radius, while authorization decides whether an action is permitted. Human approval provides judgment for unusual or high-impact actions, but it does not scale if every read requires a person. The strongest practical design combines RBAC or workload identity for stable assignments, attributes for context, per-decision evaluation for runtime control, sandboxing for containment, and approval for selected exceptions.

| Option | Strength | Limitation | Appropriate role |
| --- | --- | --- | --- |
| Static RBAC | Familiar and inexpensive to administer | Often too broad for dynamic agent behavior | Base permissions and account grouping |
| Long-lived API key | Simple integration pattern | Hard to revoke, scope, or attribute to a specific action | Legacy integrations only |
| Tool gateway | Centralizes validation, routing, and enforcement | Can become a bottleneck or a single point of failure | Runtime control plane |
| Full human approval | Contextual judgment and accountability | Slow, expensive, and vulnerable to approval fatigue | High-impact exceptions |
| Policy-based per-call checks | Precise, explainable, and adaptable | Requires disciplined schema and policy maintenance | Production authorization layer |

The main tradeoff is engineering and operational cost. A simple wrapper can add perhaps $1,000 to $10,000 in setup for a small internal pilot, while an enterprise deployment with identity integration, gateways, approval UX, observability, and compliance testing may cost tens of thousands to hundreds of thousands of dollars. Recurring expenses include policy evaluation, gateway compute, log storage, identity services, and security operations. Open-source policy components and open protocols can reduce software fees, but they do not remove integration or governance work. Measure cost per authorized action, not only infrastructure spend; a system that creates excessive approval prompts may be expensive even when its license is free.

## Common Design Mistakes and Failure Modes

The first common mistake is authorizing the conversation rather than the action. If an agent receives a broad “analyst” permission and then follows instructions found in a PDF, the permission boundary has effectively disappeared. The second is treating tool names as security identifiers. A malicious or misconfigured server can expose a tool with a familiar name, so server identity, version, schema, and target resource must be part of the decision. The third is allowing model-generated text to define the user, tenant, purpose, or approval state. Those values must come from trusted session context and server-side validation.

Another mistake is caching an allow decision for the entire session. Decisions should normally be short-lived, especially when the agent can change tools, targets, or arguments. A fifth mistake is approving a summary instead of the exact execution request. Approvers need a preview, immutable request hash, and clear indication of what will happen after approval. The sixth is granting a human’s permissions directly to an autonomous agent without delegation, expiration, and revocation. The seventh is assuming observability equals prevention. Logs cannot stop an action unless an enforcement point blocks it.

Teams also underestimate policy conflicts and emergency behavior. A workflow may pass identity checks while a data-classification rule denies export, or an approver may be unavailable at 02:00. Define fail-closed behavior for sensitive tools, bounded retries, alternate approval groups, and a safe queue rather than retrying indefinitely. Test prompt injection, indirect instruction injection, credential theft, tool poisoning, confused-deputy scenarios, replay of approvals, and cross-tenant object references. The correct security target is not “the model never misbehaves”; it is “the model cannot obtain authority it was not granted.”

## When to Act and What to Measure

Act now if an agent can access production data, modify operational systems, communicate externally, or run code, and if the organization cannot answer a simple question such as “which exact action did this agent perform with this user’s authority?” Waiting is reasonable for an offline prototype using synthetic data, a read-only research assistant with strict egress limits, or a sandbox with no credentials to sensitive systems. The risk changes when a prototype receives a production identity, when multiple agents exchange instructions, or when a vendor connects a new tool without an independent authorization boundary. A practical trigger is any deployment that handles confidential data or can cause financial, legal, privacy, or safety effects.

Measure the system with operational and security indicators. Track the percentage of calls receiving an explicit decision, the number of actions denied, approval latency, unauthorized-action attempts, cross-tenant violations, stale approvals, policy-evaluation errors, and time to revoke an identity. Include business measures such as task completion rate, human review burden, and cost per completed workflow. A target of 99.9% successful policy evaluation is not automatically good if 1% of sensitive operations fail open; conversely, a high approval rate may show that policies are too broad or poorly tuned. Report exact counts and rates over a defined period, such as 30 days, and segment results by agent, tool, tenant, and risk class.

The architecture should be reviewed whenever an agent gains a new tool, an existing tool changes its schema, a new model or vendor is introduced, or an incident reveals a gap. Maintain a current map of tool ownership, data classification, delegated authority, and accountable business owner. The agent may be intelligent, but authorization remains an ordinary enterprise engineering responsibility. The best design is not the one with the most sophisticated policy language; it is the one that makes every consequential action attributable, narrowly scoped, reviewable, revocable, and impossible to bypass through an untrusted prompt.

## Quick answers

### What is per-decision authorization for an AI agent?

It is a control that evaluates each tool call separately, using the acting identity, requested operation, target resource, attributes, and current time. The result can allow, deny, narrow, or require human approval instead of granting session-wide access.

### Is RBAC enough for securing AI agents?

RBAC is useful for assigning stable responsibilities, but it can be too broad when agents act dynamically across tools and data. Combine it with workload identity, attribute-based conditions, short-lived credentials, and enforcement at every tool boundary.

### How should human approval work for high-risk agent actions?

The approver should see the exact tool, arguments, target, initiating user, and expected effect, then approve a hash-bound request for a short window. Changing an argument, tool version, or target should invalidate the approval.

### Do MCP gateways automatically provide agent authorization?

No. An MCP gateway can centralize routing, credential handling, validation, and policy enforcement, but it must explicitly implement and test those controls. A gateway that only forwards requests may still allow unauthorized actions.

### What is a good first deployment for an authorization pilot?

Choose a read-only internal workflow with synthetic or low-sensitivity data, such as controlled enterprise search. Run the policy layer in monitoring mode for 30 to 60 days, measure false positives and high-risk denials, and enforce only after known dangerous cases are blocked reliably.

Canonical: https://agustin-otegui.com/knowledge/how_should_enterprises_design_per-decision_authorization_for_ai_agent_tools.php
Markdown: https://agustin-otegui.com/knowledge/how_should_enterprises_design_per-decision_authorization_for_ai_agent_tools.php/index.md