AI Agent Tool Permissions and Risk

The Point

AI agents become dangerous when tool permissions are broader than the business task requires.

The model is not the authority. The tools are.

A safe AI agent program needs a tool permission model that answers:

What can the agent read, write, delete, send, execute, deploy, approve, or persist, and under whose authority?

OWASP identifies excessive autonomy, tool abuse and privilege escalation, data exfiltration, memory poisoning, and sensitive-data exposure as major agent risks. Its LLM Top 10 also warns that unchecked autonomy, insecure plugin design, and insecure output handling can lead to severe downstream impact.

Why Tool Permissions Matter More Than Model Behavior

People often ask whether the model is safe.

For production agents, the sharper question is:

What can the agent do if the model behaves unsafely?

A model that produces a bad answer is one type of risk. A model that produces a bad API call, shell command, email, record update, or deployment is a different risk class.

Tool permissions define blast radius.

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 non-critical records.	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

OWASP's AI Agent Security Cheat Sheet recommends minimizing the number of tools available to an agent, scoping permissions per tool, separating tools by trust level, and requiring explicit authorization for sensitive operations.

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.

This matrix should exist 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 is dangerous because it crosses an organizational boundary.

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.

Tool-use review should analyze chains, not just individual tools.

Credentials Determine True Authority

A tool's permission is determined by its credential.

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.

Without logs, tool permission mistakes become difficult to assess and hard to defend in diligence.

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 proves it ran correctly.

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.

Final Thought

AI agent security is not only about prompts. It is about permissions.

If an AI agent can touch production tools, customer data, SaaS systems, code, infrastructure, email, or workflows, then every tool should be treated like an API surface with business impact.

Before production, ask:

What can this agent do, what credential lets it do that, what policy authorizes it, and what artifact shows it happened correctly?

If you cannot answer those questions, the agent has unknown blast radius.

What TKOResearch Reviews

TKOResearch performs MCP & Tool-Use Blast-Radius Reviews for teams connecting AI agents to SaaS tools, internal APIs, RAG systems, code execution, production workflows, and sensitive business data.

Request Tool-Use Blast-Radius Review

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