Before You Give an AI Agent a Tool, Give It a Permission Manifest

Short answer

Before an AI agent receives tool access, give it a permission manifest: who owns the agent, what job it is doing, which systems it can touch, what scope expires when, which actions need approval, and where every run is recorded. A chat approval is not enough unless a lower gateway actually enforces the scope and leaves an audit receipt.

The useful signal

Agent products are moving from raw tool access toward governed authorization.

The Model Context Protocol authorization specification describes an OAuth-style pattern for authorization servers, protected-resource metadata, dynamic client registration, PKCE, scope errors, and risks such as confused-deputy attacks. Cloudflare's MCP authorization documentation describes scopes, consent, and tool-level permission patterns for MCP servers. Identity vendors including Auth0, Stytch, and Descope publicly position AI-agent authorization, delegated app access, token vaulting, approval, and identity-aware MCP servers as product categories.

Those sources do not prove broad adoption or production maturity. They do show that agent access is becoming a permission problem, not only a prompting problem.

That matters to a business owner because an agent connected to Slack, files, CRM records, scheduling software, browser sessions, or payment-adjacent workflows is no longer just answering a question. It may be reading, drafting, changing, sending, or escalating work inside the business.

The buying question becomes:

Which agent is acting, who approved it, what can it access, how long does that access last, and where is the receipt?

Use passports, visas, and receipts

A simple model keeps the conversation practical.

Passport: the agent's identity. It names the agent, owner, job, requester, and home workflow.

Visa: the allowed access. It names the systems, scopes, actions, expiry, spend cap, and approval rule.

Receipt: the evidence afterward. It records what the agent used, what it attempted, what succeeded, what failed, and what a person approved or rejected.

This is SpinTheBloc's synthesis, not terminology from the cited sources. The point is to translate OAuth scopes, consent, token handling, and audit trails into a buyer-visible operating standard.

What an agent permission manifest should contain

A first manifest can be plain language. It should be specific enough that a nontechnical operator can approve or hold the work.

Field	Buyer question
Agent and owner	Which agent is acting, and who is accountable for its result?
Job	What exact business job is this access for?
Approved sources	Which files, channels, apps, records, or domains may it read?
Allowed actions	Can it only read and draft, or can it change, send, delete, charge, or publish?
Scope and expiry	Which permission ends after this run, date, or repetition count?
Approval rule	Which action requires a person before execution?
Token boundary	Where is the credential stored, and is the raw secret hidden from the agent?
Audit destination	Where can the operator review the request, action, result, and failure state?
Revocation path	How can the business stop the permission without rebuilding the workflow?

This does not require a large security program for every helper. The depth should match the consequence. A public-source research agent needs less authority than an agent that edits customer records or sends appointment confirmations.

Example: a follow-up draft agent

Hypothetical illustration: a service business wants an agent to prepare follow-up drafts after completed estimates.

A weak setup says: "The agent can use the CRM and email."

A permission manifest says:

• The owner is the service manager.
• The job is to prepare a reviewable follow-up draft for estimates completed since the previous run.
• The agent may read customer name, service requested, estimate status, approved service language, and recorded contact preference.
• It may create a draft queue item.
• It may not send email, change price, change scope, edit the customer record, delete records, or contact the customer.
• The permission expires after the daily run.
• Every draft must include source record ID, missing-information flags, and validation state.
• A coordinator approves or rejects each send.

The example is not a verified customer case or benchmark. It is a buyer-facing way to test the permission concept against a common workflow.

A Slack approval card is the interface, not the whole control

Slack, Microsoft Entra, and other platform documentation make delegated permissions and scopes familiar concepts for enterprise buyers. A readable approval card can help a human understand what is being requested.

But a card is only trustworthy when the underlying system enforces the decision. If the agent can bypass the gateway, reuse a broad token, or act without writing a run record, the approval layer becomes theater.

A stronger design separates four things:

1. Request: the agent asks for a named scope for a named job.
2. Approval: a person approves, holds, or rejects that scope.
3. Enforcement: the tool gateway grants only the approved action for the approved window.
4. Audit: the run record shows what happened and where confidence stops.

That is the difference between "we approved the agent" and "the agent was only able to do the approved thing."

What to ask before approving agent tool access

Use these questions in a vendor review, internal build review, or automation proposal:

1. Which exact job does this agent need tool access for?
2. What is the narrowest read scope that can complete the job?
3. Which actions remain draft-only or human-approved?
4. How long does the access last?
5. Where are tokens stored, and can the agent see raw secrets?
6. What happens if the agent asks for an unapproved scope?
7. What run record proves what it actually did?
8. How do we revoke or rotate access?
9. Which failure stops the workflow before a customer, record, payment, or public surface is affected?

If the proposal answers mostly with model capability, the permission design is unfinished.

Sources and limits

The MCP authorization specification supports the description of OAuth-style authorization mechanics, resource metadata, dynamic client registration, PKCE, scope handling, and security risks such as confused-deputy attacks. Cloudflare's MCP authorization documentation supports the narrower claim that MCP server implementations can use scopes, consent, and tool-level permission patterns.

Auth0's AI-agent authorization page, Stytch's connected-apps article, and Descope's identity-aware AI/MCP launch material are vendor-positioning sources showing that agent authorization, delegated access, approval, token handling, and identity-aware MCP are being packaged as products. They do not independently prove adoption, reliability, security quality, or customer outcomes.

Slack's OAuth scopes documentation and Microsoft's permissions and consent overview support the general explanation that business software already uses scopes, delegated permissions, app-only permissions, and consent records. They do not validate any particular AI-agent implementation.

The passport/visa/receipt model, permission-manifest table, follow-up-draft example, and approval-card operating sequence are SpinTheBloc's synthesis. They should be adapted to the workflow, data sensitivity, customer consequence, vendor contract, and available audit evidence before an agent receives live authority.