AI Technology Brief
AI agent authorization: tool access is not business authority
An agent may be authenticated and technically able to call a tool without being authorized to perform the resulting business action. Dependable operation needs user and workload identity, resource-bound credentials, action-time policy enforcement, exact approval, and correlated evidence.
01 / Independently verifiable claims
Begin with what the technology and standards actually support.
- NIST zero-trust guidance separates policy decisions from policy enforcement and requires access to protected resources to be explicitly authorized rather than implicitly trusted.
- The finalized MCP 2025-11-25 authorization specification treats a protected MCP server as an OAuth resource server and requires protected-resource metadata and resource indicators.
- MCP servers must validate that access tokens were issued for them, and the MCP specification prohibits passing a received MCP token through to downstream APIs.
- OAuth security guidance recommends audience-restricted access tokens so a token intended for one protected resource is rejected by another.
- MCP authorization secures access to an MCP server; downstream tools and business systems still require their own user, resource, action, and approval controls.
- Arcade documents server-level and tool-level authorization as separate layers. It is one implementation example, not proof that every system supports identical delegation semantics.
02 / The practical distinction
Authentication, tool availability, authorization, and business approval answer different questions.
A technically successful login or tool call does not establish that the requested action is permitted for this user, this agent workflow, this record, and this business consequence.
Identity
Authentication
Who is the requesting human, service, workload, or client, and how was that identity established?
Capability
Tool access
Which API, MCP tool, browser action, or execution method is technically available to the workflow?
Permission
Authorization
May this identity, through this approved agent, perform this operation on this resource under current policy?
Authority
Business approval
Does a named accountable person have the evidence and authority to approve the commercial, contractual, financial, safety, privacy, or professional consequence?
03 / Operating architecture
Place policy decisions and enforcement between model intent and business action.
The model can propose a tool call. An external control plane evaluates and enforces current authority before the execution service reaches the protected system.
Authenticated request
Identify the user, client, agent or workload, session, organization, workflow, and permitted business purpose.
Policy decision
Evaluate user authority, agent boundary, resource, record, field, action, token audience, risk, time, and approval state.
Policy enforcement
Grant, narrow, deny, expire, interrupt, or escalate the action outside the model. Keep credentials out of prompts and ordinary context.
Protected action
Execute only the approved operation, capture the durable result, and preserve the authorization and business evidence.
04 / Required records
Every attempted action needs enough identity and evidence to reconstruct the decision.
Actor record
Requesting user, organization, role, assignment, authentication event, agent or workload identity, and session.
Policy record
Policy version, user permission, agent permission, resource, action, purpose, conditions, decision, reason, and expiry.
Credential reference
Provider, token or secret reference, scopes, audience, issue, expiry, rotation, revocation, and broker. Never store the secret in the run record.
Approval record
Exact proposed action, source evidence, consequence, approver identity, decision, conditions, version, and time.
Execution record
Tool, parameters, destination, start, result, returned resource identity, error, retry, and idempotency key.
Audit correlation
Run ID linking request, policy decision, approval, tool call, protected-system response, exception, and final business state.
05 / Construction example
One construction agent may prepare useful work while four authority boundaries remain closed.
The permissions depend on the client systems and responsibilities. These examples show why one broad send, write, or administrator scope is not a business control.
Estimating
RFQ and bid
Read approved invitations and prepare a response; estimator or commercial authority retains bid, price, qualification, and submission decisions.
Documents
Revision control
Extract candidate metadata and compare revisions; document control verifies the controlling source, status, distribution, and formal issue.
Projects
Management reporting
Prepare source-linked status commentary; responsible people approve progress, payment, safety, quality, entitlement, and contractual conclusions.
Finance
Invoice workflow
Match invoice, order, and delivery evidence; authorized finance roles resolve exceptions, bank changes, posting, approval, and payment release.
06 / Deterministic controls
Enforce deterministic limits around every probabilistic request.
Separate user and workload identity
Record both. Do not assume a shared agent identity safely represents every user who can invoke it.
Minimum action scopes
Separate read, search, download, draft, create, update, send, approve, export, delete, share, and permission changes.
Resource and audience binding
Request credentials for the intended resource and reject tokens not issued for the receiving service.
Action-time policy check
Re-evaluate current identity, scope, resource, purpose, conditions, and approval immediately before execution.
Credential broker
Where supported, inject protected credentials inside the execution environment without exposing them to the model or client.
Approval bound to exact action
Bind approval to the visible recipient, amount, document, version, parameters, evidence, expiry, and next effect.
07 / Failure analysis
Most failures come from collapsed boundaries, stale authority, or incomplete evidence.
Shared authority
A service identity can access information or actions that the invoking user should not inherit.
Full-user blast radius
Delegating a privileged user identity gives the agent unrelated delete, send, administration, or production capabilities.
Permission requested too early
Broad scopes are granted before the specific action, destination, record, and consequence are known.
MCP overstatement
A conforming connection is treated as evidence that downstream scopes, records, business rules, and approvals are secure.
Token misuse
A token is accepted by the wrong resource, passed downstream, exposed to model context, retained too long, or not revoked.
Approval fatigue
People repeatedly approve vague requests without seeing the exact action, evidence, change, recipient, or consequence.
Permission chaining
Several individually permitted tool calls accumulate into a larger unreviewed capability or irreversible effect.
Audit gap
Logs show that a tool ran but not which user, agent, policy, resource, approval, and business state authorized it.
08 / Deployment and cost
Authorization architecture changes with the systems and delegation they actually support.
Direct API and OAuth
Use documented scopes, resource indicators, audience validation, delegated user consent, token lifecycle, and source-system permission checks where available.
MCP server or gateway
Secure server access and tool-level downstream authorization separately. Validate resources and never treat tool discovery as permission.
Dedicated service identity
Suitable for narrow machine-owned work when users cannot inherit excess authority and project, record, action, and purpose limits are enforced.
Browser and legacy access
Use a dedicated or approved delegated account, isolated execution, permitted pages and actions, execution-time confirmation, evidence, takeover, and credential rotation.
- Identity provider, authorization server, policy engine, gateway, credential broker, secrets, and token lifecycle
- Source-system integration, custom scopes, record-level enforcement, internal MCP tools, and legacy access
- Approval interfaces, permission reviews, audit storage, monitoring, incident response, and access recertification
- Test environments, adversarial cases, stale-role testing, revocation, recovery, and provider-change regression
- Human security, system-owner, workflow-owner, and business-authority review
09 / Evaluation
Test denied and expired authority as carefully as successful action.
- Correct user and agent identity on every run
- Denied cross-project, cross-client, restricted-field, and prohibited-action attempts
- Token audience, scope, expiry, revocation, replay, and downstream-passthrough behavior
- Action-time policy decisions after role, assignment, permission, or approval changes
- Approval binding to the exact recipient, record, amount, document version, and parameters
- Credential absence from prompts, model context, client responses, ordinary logs, screenshots, and errors
- Permission chaining, duplicate action, retry, interruption, and partial-completion behavior
- Complete correlation from request through policy, approval, execution, exception, and final business record
10 / Controlled pilot
Prove the operating boundary before expanding it.
Choose one consequential edge
Start with one task that can read and prepare but must stop before a clearly defined send, update, submission, payment, deletion, or permission change.
Map real identities
Identify users, service identities, roles, projects, records, scopes, systems, approvers, and temporary access instead of designing from generic personas.
Build denial cases
Test wrong user, project, tenant, record, field, action, audience, expired token, revoked access, missing approval, and changed assignment.
Keep execution reversible
Use read-only or shadow operation first, then one bounded reversible action with exact confirmation and a reliable stop path.
Measure evidence quality
Confirm an independent reviewer can reconstruct why the action was allowed or denied without exposing credentials or unnecessary content.
Expand one boundary at a time
Add one scope, system, user group, resource class, or action only after the prior authorization behavior remains accepted.
11 / StructuredLayer recommendation
Treat an AI agent as an untrusted application requestor, not as an employee carrying ambient authority.
Begin with one workflow, identify the user and agent separately, restrict the resource and action, keep policy and credentials outside the model, require exact approval for consequential effects, and preserve a correlated authorization record. MCP can standardize part of the connection, but the client still owns business authority, source-system permissions, approval, monitoring, incident response, and change control.
12 / Primary sources
Capability, governance, and implementation claims remain inspectable.
Model Context Protocol
Authorization specification 2025-11-25
IETF RFC 9728
OAuth 2.0 Protected Resource Metadata
IETF RFC 8707
Resource Indicators for OAuth 2.0
IETF RFC 9700
OAuth 2.0 Security Best Current Practice
NIST SP 800-207
Zero Trust Architecture
NIST SP 1800-35
Implementing a Zero Trust Architecture
Arcade documentation
Server-Level vs Tool-Level Authorization
Arcade documentation
Add user authorization to MCP tools
Sources reviewed 27 July 2026. Technology capabilities, laws, guidance, terms, and pricing can change.
13 / Related StructuredLayer guidance
Continue from model selection into operating architecture.
Permissions and Security for AI
Assess identities, retrieval filters, credentials, tool actions, approval, audit, incidents, and handover for one workflow.
AI Agent Reliability
Connect bounded tools and permissions to validation, exception handling, monitoring, and staged production action.
How StructuredLayer Works
Follow an approved source event through deterministic checks, bounded AI, review, governed write-back, and monitoring.