AI Agent Tool Permissions and Risk

A support agent that needs to draft a reply should not inherit the mailbox owner's ability to forward every conversation. That sounds straightforward until a connector exposes both operations under one credential and one broad tool name.

I classify permissions by the action and target the runtime can actually reach. The model's intended task is useful context, but it does not reduce the authority of an overbroad token. Start with read, draft, write, delete, send, execute and deploy, then separate permissions further when the destination or business effect changes.

OWASP's agent security guidance recommends limiting tools and their permissions. The matrices below turn that principle into a reviewable tool contract.

The Core Action Classes

Every AI agent tool should be classified by action type.

Action Class	Description	Example Tools	Default Control
Read	Access or retrieve information.	Search docs, query ticket, read CRM.	Authorize and log.
Draft	Prepare output without executing externally.	Draft email, draft ticket reply.	Human review.
Write	Create or modify records; impact depends on the fields and workflow.	Create issue, update note.	User attribution and policy check.
Delete	Remove records, files, users, or state.	Delete file, remove contact.	Deny by default or explicit approval.
Send	Communicate externally or internally.	Send email, post Slack, notify customer.	Draft-first or approval.
Execute	Run commands, code, scripts, queries, workflows.	Shell, Python, SQL, CI job.	Sandbox or deny.
Deploy	Change production systems.	Deploy app, change config.	Manual gate.
Approve	Authorize money, access, legal, security, or policy action.	Refund, permission grant, approval workflow.	Human authority only.
Remember	Persist memory or state.	Long-term memory write.	Scope, review, expiry.
Chain	Use one tool's output as another tool's input.	Search -> summarize -> send.	Policy and egress controls.

A tool inventory without action classification is not enough.

Least Privilege For AI Agents

For agents, least privilege means:

Design Question	Safer Pattern
Does the agent need write access?	Prefer read or draft access first.
Does it need all records?	Scope by tenant, user, role, and resource.
Does it need direct send?	Use draft-first workflows.
Does it need shell execution?	Deny or sandbox with strict allowlists.
Does it need admin APIs?	Almost never.
Does it need persistent memory?	Scope, expire, and review memory.
Does it need service credentials?	Prefer user-scoped authorization.

The agent should get the minimum tool set needed for the workflow, not the maximum tool set available in the environment.

Permission Matrix Template

Use a matrix like this for every agent.

Tool	Action Class	Data Touched	Credential Used	Required Scope	Risk	Required Control
`search_docs`	Read	Internal docs	User OAuth	Tenant + role	Medium	Authorized retrieval + logging.
`summarize_ticket`	Read/Draft	Support ticket	User OAuth	Assigned tickets	Medium	Source attribution.
`draft_email`	Draft	Email content	User OAuth	Current thread	Medium	Human review.
`send_email`	Send	External email	User OAuth	Approved recipients	High	Explicit approval.
`update_customer`	Write	CRM record	User OAuth	Assigned account	High	Policy check + audit.
`delete_file`	Delete	Files	Service token	Broad storage	Critical	Remove or human approval.
`run_shell`	Execute	Runtime/filesystem	Local process	Host permissions	Critical	Sandbox or deny.
`deploy_app`	Deploy	Production	CI/CD token	Production environment	Critical	Manual gate.

The scope column describes the required application boundary, not necessarily an OAuth scope the provider supports. User-delegated access does not automatically enforce ticket assignment, recipient selection or document ACLs. Verify those separately before production.

Read Permissions Are Not Always Low Risk

Read-only tools can still create high impact.

Read Tool	Risk
Search customer records	PII or confidential business data exposure.
Query internal docs	Strategy, architecture, or secret process leakage.
Read code	Supply-chain or vulnerability discovery.
Read tickets	Customer-sensitive events or credentials.
Read calendar/email	Personal, legal, or privileged information.
Read logs	Tokens, secrets, IPs, operational details.

Read access should still be scoped, authorized, and logged.

Write Permissions Require Policy

Write tools create integrity risk.

A manipulated agent may update the wrong customer record, add false internal notes, create misleading tickets, modify workflow state, change classifications, persist poisoned data, or create durable business confusion.

Write tools should require:

Control	Purpose
User-scoped authorization	Agent can only act as the correct user.
Resource-level authorization	Agent can only modify allowed resources.
Schema validation	Parameters must be typed and bounded.
Business-rule validation	Action must make sense in workflow.
Audit trail	Change must be reconstructable.
Undo/rollback	Mistakes should be recoverable where possible.

The model can propose a write. The backend should decide whether the write is valid.

Delete, Execute, Deploy, And Approve Are Critical Actions

Some actions should be treated as critical by default.

Critical Action	Default Stance
Delete records or files	Deny unless explicitly needed.
Run shell commands	Deny or strict sandbox.
Execute generated code	Deny or isolated sandbox.
Deploy to production	Manual gate.
Modify IAM or permissions	Human approval.
Approve payments/refunds	Human approval.
Send legal/customer commitments	Human review.
Change security policy	Manual process.

For these actions, "the model decided it was appropriate" is not a valid control.

Send Permissions Deserve Special Treatment

Sending moves information to another audience. That may cross an organizational boundary, or expose a restricted matter in an internal channel with broader membership.

A send-capable agent can email customers, message employees, post to Slack or Teams, submit forms, open external tickets, contact vendors, notify regulators, or publish content.

Safer pattern:

Generate draft
  -> validate recipient and content
  -> require human approval
  -> send through attributable user identity
  -> log full decision path

For many enterprise agents, draft-first is the right default.

Tool Chaining Is Where Risk Hides

A single tool may look safe. A chain may not.

search_customer_records
  -> summarize_sensitive_context
  -> draft_external_email
  -> send_email

Each step may appear defensible. Together, they create a data-exfiltration path.

Chain Pattern	Risk
Read -> Send	Data exfiltration.
Read -> Write	Unauthorized derived updates.
Web -> Tool	External content influences internal action.
Tool output -> Tool input	Untrusted output drives next action.
Memory -> Tool	Poisoned memory changes behavior.
Search -> Execute	Retrieved content affects command/code.

Review the resulting flow of data and authority across the full chain.

Credentials Determine True Authority

A credential sets part of a tool's reachable authority. Application policy, downstream resource checks, network access, and the process's local permissions determine the rest. A user token can still be too broad for one workflow.

Credential Pattern	Risk
User-scoped OAuth token	Better attribution and scope.
Shared service account	Broad authority and weak accountability.
Admin token	Critical blast radius.
Long-lived API key	Durable compromise.
Local environment secret	Endpoint compromise path.
Cloud role	Infrastructure-level impact.

MCP security guidance highlights token passthrough, session handling, local server compromise, and scope minimization as MCP-specific security areas.

A safe design minimizes broad service credentials and avoids exposing secrets to the model.

Required Logs For Tool Permissions

Every tool call should produce an audit trail.

Field	Purpose
User ID	Who initiated the workflow.
Tenant ID	Boundary applied.
Agent/workflow ID	Which agent acted.
Tool name	What capability was used.
Action class	Read/write/delete/send/execute/etc.
Parameters	What the model requested.
Authorization result	Why it was allowed or blocked.
Approval event	Who approved high-impact action.
Credential type	User token, service token, role, etc.
Downstream target	System/resource affected.
Result	Success/failure/partial.
Trace ID	Correlates prompt, retrieval, tool call, and output.

Store safe parameter fields or a digest rather than unrestricted bodies, credentials, or authorization headers. A digest can bind an action to an approval; it cannot reconstruct missing content on its own.

Tool Permission Review Checklist

Question	Good Answer
Do we have a complete tool inventory?	Yes.
Is every tool classified by action type?	Yes.
Are read/write/send/delete/execute tools separated?	Yes.
Are credentials user-scoped where possible?	Yes.
Are broad service tokens avoided?	Yes.
Are high-impact actions gated?	Yes.
Are tool parameters validated outside the model?	Yes.
Can tool output trigger another tool without policy review?	No.
Are tool calls logged with authorization artifacts?	Yes.
Can risky tools be disabled quickly?	Yes.

What A Tool-Use Review Should Leave Behind

The review should make every tool's authority explicit: what it can touch, what credential gives it access, what control gates it, and what trace records its observed result.

Deliverable	Description
Tool Inventory Matrix	Lists all tools, actions, credentials, and data touched.
Action Classification Table	Separates read, write, send, delete, execute, deploy, approve, remember.
Credential Scope Review	Identifies overbroad tokens, service accounts, and missing attribution.
Tool Chain Abuse-Case Matrix	Shows how low-risk tools can combine into high-risk outcomes.
Destructive-Action Control Plan	Defines approval, policy, sandbox, and deny-by-default controls.
Blast-Radius Reduction Plan	Prioritizes least privilege and high-impact risk reduction.

Test the permission that would matter on a bad day

For each permitted operation, add a neighboring operation that must fail. If an agent can draft a reply, try sending it without approval. If it can update one ticket, try another tenant's ticket. If it can deploy to a preview environment, try a production target with the same credential.

Those checks expose the difference between the documented tool list and the authority available at runtime. The secure tool-access implementation guide includes a runnable document-policy example and approval checks.

AI Agent Tool Permissions: Read, Write, Delete, Send, Execute, Deploy