AI Agent Security Checklist: Review Tool Permissions Before Production

An AI agent can produce correct text and still be unsafe to launch.

The reason is simple: once the system can call tools, the real risk is not only what the model says. It is what the surrounding application lets the model read, change, send, spend, or delete.

OWASP groups this failure mode under Excessive Agency and separates it into excessive functionality, excessive permissions, and excessive autonomy. Its recommended controls start with limiting extensions and their functions to the minimum necessary.OWASP LLM06:2025

So before asking “Is the agent accurate enough?”, ask a narrower launch question:

Can every consequential tool action be traced to a necessary permission, a bounded target, and a human-approved failure path?

This checklist turns that question into a review you can run before production.

The permission-boundary review

Create one row for every tool or external action the agent can invoke. Do not group “Google Workspace,” “AWS,” or “internal API” into a single row. Review the specific operation: read a calendar, send an email, update a ticket, rotate a key, or delete a file.

Record these seven fields:

Field	Question to answer	Weak answer	Launch-ready answer
Business purpose	Why must the agent perform this action?	“It may be useful.”	“Creates a draft incident ticket after a validated alert.”
Operation	What exact verb is allowed?	“Access Jira.”	“Create issue in project SEC; no edit, close, or delete.”
Target scope	Which records, systems, or tenants are reachable?	“Production.”	“SEC project only; tenant ID pinned server-side.”
Credential scope	What can the credential itself do?	“Uses the service account.”	“Dedicated token limited to create-only scope; no admin role.”
Side effect	What can change, leak, cost money, or become public?	“Low risk.”	“Creates an internal ticket and may expose alert metadata to assigned responders.”
Approval gate	When must a person approve?	“For sensitive actions.”	“Required before any external message, financial action, identity change, or destructive operation.”
Recovery evidence	How will you detect, stop, and reverse failure?	“Check logs.”	“Request ID logged; token revocable; created object tagged; rollback tested with a synthetic record.”

The important shift is from a capability inventory to an evidence chain. A tool name tells you what might happen. These fields tell you why it is allowed, where it stops, and how you recover.

Apply three constraints before adding a human approval step

Human approval is useful, but it should not compensate for an overpowered integration. Constrain the system in this order:

1. Remove unnecessary functions

If the workflow only reads invoices, do not expose a generic shell, browser, or mailbox tool. If it drafts an email, do not include a send function in the same tool contract.

2. Reduce credential permissions

The agent-facing credential should be narrower than the human administrator’s account. Enforce scope in the downstream service or trusted application layer, not in the prompt alone.

3. Reduce autonomous decisions

Require approval where an error is hard to reverse or affects someone outside the immediate team. Examples include:

• sending an external message;
• changing identity or access;
• spending money or accepting a contract;
• publishing content;
• deleting or overwriting data;
• executing a production change with no tested rollback.

Only after these constraints should you decide which remaining actions need a human checkpoint.

Use a launch gate that critical gaps can override

A percentage score can hide one dangerous permission among many harmless controls. Use an override rule instead:

Do not launch when any production tool lacks an owner, bounded target, least-privilege credential, observable request log, or tested stop path.

A practical gate can be written as:

READY = all critical tool rows have:
  owner
  + exact operation
  + bounded target
  + least-privilege credential
  + side-effect classification
  + approval rule
  + stop/recovery evidence

This aligns with the NIST AI Risk Management Framework’s emphasis on managing AI risk across Govern, Map, Measure, and Manage, rather than treating testing as a one-time model check.NIST AI RMF

Test the boundary with synthetic scenarios

Do not test with real credentials or customer data. For each critical tool, create at least four synthetic cases:

1. Allowed request: expected action succeeds inside the approved scope.
2. Out-of-scope target: request is denied server-side.
3. Missing approval: consequential action remains pending or fails closed.
4. Injected instruction: untrusted content asks the agent to use a tool beyond the workflow; the request is rejected and logged.

Capture expected outcome, actual outcome, evidence location, owner, and retest date. A demonstration that “the agent refused once” is not durable evidence; a downstream authorization failure and a traceable event are stronger.

The minimum review packet

For a small team, the review packet does not need to be a large governance program. It can be five connected artifacts:

• an agent and owner inventory;
• a permission and credential-reference map;
• a tool side-effect register;
• synthetic test evidence;
• a launch decision with explicit blockers.

The value is not the spreadsheet itself. The value is being able to answer, before production:

• What can this agent actually do?
• Why does it need each permission?
• Which actions cannot proceed without approval?
• What evidence proves the boundary works?
• Who can stop it when the assumption fails?

If you want an editable workbook that connects those records into one review flow, the AI Agent Security Readiness Kit includes permission, tool-side-effect, data-boundary, test, launch-gate, and incident-response sheets in English and Korean.