Agent Permission Review Checklist: Bounding the Blast Radius

An agent's permissions are its blast radius, and most reviews examine tools one at a time, which is where exposure hides. This checklist covers doing it properly, drawn from FISTA Solutions' AI agents production work.

What does the review cover?

Six areas, with the combination review being the one usually skipped.

Area	Question it answers
Tool justification	Why does it need this at all?
Limits	How much damage in one period?
Combination	What paths exist across tools?
Credentials	Can it be cut off alone?
Delegation	Does authority narrow at each hop?
Revocation	How fast can this be stopped?

Tool justification

Start from zero and add only what a documented case requires.

• Every tool maps to a case in the written scope
• Read-only alternatives used where they suffice
• Tools added since launch reviewed against the original justification
• Tools no longer used have been removed
• Each tool's parameters are constrained, not open-ended
• Access scoped to specific resources rather than whole systems
• A person outside the build team has reviewed the list

Limits and thresholds

Bound the damage per action and per period. See why agent security is different.

• Monetary limit per action enforced in code
• Monetary limit per period enforced in code
• Volume limit per period enforced in code
• Approval threshold defined for high-value actions
• Limits tested by attempting to exceed them
• Limit breaches alert someone who can act
• Limits reviewed against what the business would tolerate losing

Capability combination

The review most often skipped and most often where the exposure is.

• The full capability set listed in one place
• Read plus external send combinations identified
• Read plus write combinations across systems identified
• An adversarial question asked: what could this set accomplish?
• Paths to data exfiltration explicitly considered
• Paths to privilege escalation explicitly considered
• Someone with a security background reviewed the set

Credentials and identity

Attributable and independently revocable.

• The agent has its own service identity
• Credentials are not shared with other systems or agents
• Credentials can be revoked without affecting anything else
• Rotation schedule defined and followed
• Actions in downstream systems are attributable to the agent
• Credentials stored in a secrets manager, not in configuration
• Credential use is logged and monitored for anomalies

Delegation

Authority should narrow at every hop. See the coming agent interoperability standard.

• Whether the agent delegates to other agents is documented
• Delegated authority is a subset, never the full set
• Delegation is time-limited
• Delegation is revocable independently
• The chain is logged so actions trace back to the original grant
• Third-party agents receiving delegation are reviewed
• A maximum delegation depth is enforced

Revocation and response

How fast can this be stopped, and by whom.

• A kill switch exists and has been exercised
• On-call can disable the agent without an engineer
• Individual tools can be disabled without stopping the agent entirely
• Time from decision to fully stopped is known and acceptable
• In-flight tasks are handled predictably when the agent is stopped
• Actions taken can be identified for reversal where reversible
• The revocation path is documented in the runbook

What are the most common failures?

Reviewing tools individually. Limits stated in prompts. Shared credentials. Capability added incrementally without re-review. And a kill switch nobody has tested.

Who should own this?

The business owner of the agent decides what capability is acceptable; security reviews the combination; engineering implements the enforcement. All three signatures should be on the record.

How often should it run?

Before launch, on every capability change, and quarterly for deployed agents. The quarterly pass catches accumulation, which is the failure mode this checklist exists to prevent.

What evidence should it produce?

The signed capability list with limits, the combination review notes, credential inventory, and a record of the kill switch test. That set answers the question an incident review will ask.

What about agents that need broad access?

Some genuinely do — a research agent reading across many systems, for instance. The response is not to refuse but to compensate: no write capability, no external communication, output reviewed before use, and heavier logging.

Broad read with narrow action is a very different risk profile from broad read with broad action, and the distinction is what makes such agents deployable. See AI agent security risks.

What should you do first?

List every capability your most privileged agent holds and ask what an adversary could achieve with that set. The answer is usually more than anyone intended.

How FISTA Solutions helps

FISTA Solutions builds and operates production AI systems through AI agents, AI enablement, and forward deployed engineering: capability sets reviewed as a whole for the paths they create, with monetary and volume limits enforced in code rather than requested in a prompt, decisions documented with their reasoning, and handover that leaves your team able to maintain what was delivered. The record is 150+ projects for 50+ companies across 12+ countries.

To adapt this checklist to your environment, message FISTA on WhatsApp, or read AI agent launch checklist.