AI Agent Safety Checklist Before Tool Access

An AI agent becomes a security boundary the moment it can call a tool that reads data, changes state, spends money, or talks to another system. The safest time to review that boundary is before the first tool is enabled, not after the agent has already touched production.

The thesis is simple: grant tool access by blast radius, not by how useful the tool sounds. Start with a narrow, read-only capability; attach an explicit identity and policy; test hostile instructions and failure cases; then add mutation rights one control at a time. The checklist below turns that idea into a preflight you can run with an agent, an MCP server, or an internal tool wrapper.

The quick answer

What is an AI agent safety checklist?

It is a pre-access review of the agent's goal, tools, identity, data scope, execution environment, approval rules, logging, and recovery behavior. It should produce a written allowlist and a set of tests, not a vague promise to monitor the model.

Why does it matter?

An agent can chain legitimate tools into an illegitimate outcome. A read tool can expose sensitive data. A browser can submit a form. A coding tool can alter a deployment. Prompt instructions are only one control surface, and they are not a substitute for authorization enforced outside the model.

The non-obvious truth: the dangerous permission is often not the obviously destructive one. It is the harmless-looking tool that creates a bridge: a search endpoint with broad results, a package installer with network access, a CRM lookup that returns secrets, or a retry loop that turns one uncertain write into many.

What changes when an agent gets tools?

An agent is not just a chatbot with extra buttons. Anthropic defines an agent as a model that directs its own processes and tool use, operating in a loop that plans, acts, observes results, and repeats. That loop is what creates leverage, and also what creates compound failure. The model can reinterpret an instruction after every observation, choose a different route, and call several tools before a human sees the final result.

The Model Context Protocol specification is unusually direct about this: tools represent arbitrary code execution and must be treated with caution. It also says tool descriptions and annotations should be considered untrusted unless they come from a trusted server. That means a tool catalog is not a security policy. It is input to the agent.

The right mental model is a keyring. Every tool is a key, every credential is a copy of that key, and every tool chain is a door sequence. You do not hand an intern the master key because they promised to use it carefully. You issue one key, for one room, for one shift, and you log the door opening.

What should the agent be allowed to accomplish?

Write the task as an outcome and a boundary before exposing a tool. “Manage support tickets” is too broad. “Read open tickets in workspace 42, classify them, and prepare draft replies without sending” is testable. The second version gives you a subject, an object scope, a state transition, and a stopping condition.

This step matters because an agent can satisfy a broad goal through a route you did not intend. If the goal is “resolve the billing issue,” it might refund a customer, edit a subscription, email a manager, or delete a duplicate record. Those are different actions with different consequences, even if they all sound like resolution.

Use this mini-spec before every tool grant:

Question	Acceptable answer
What is the task?	One observable outcome, with a deadline or stop condition
What data can it read?	Named tenant, project, mailbox, repository, or record set
What state may change?	None, draft only, or an explicit list of mutations
What must remain impossible?	Deletes, sends, permission changes, secret reads, and unbounded egress unless separately approved
Who owns the decision?	A human or service policy outside the model

If you cannot fill in the table, the tool is not ready. You are still describing a product idea, not granting a safe capability.

Why is least privilege not enough for agents?

Least privilege limits what a tool can touch. Agents also need least agency, which limits what they can decide, chain, repeat, and commit without a checkpoint. A read-only tool with unrestricted looping can still create cost, denial of service, or data leakage. A narrow write tool can still be dangerous if it accepts arbitrary identifiers or free-form code.

The OWASP Top 10 for Agentic Applications separates risks such as goal hijacking, tool misuse, identity and privilege abuse, supply-chain vulnerabilities, and unexpected code execution. Its 2025 release says the work incorporated input from hundreds of experts and a review board that included representatives from NIST, Microsoft, AWS, Cisco, and the Alan Turing Institute. That is not proof that a control works, but it is a useful vocabulary for finding the missing one.

For each tool, set at least five independent limits:

1. Scope: which tenant, records, files, endpoints, or environments are visible.
2. Action: read, draft, preview, commit, send, delete, or administer.
3. Rate: calls per minute, total calls per task, and maximum spend.
4. Egress: approved hosts, ports, domains, and payload sizes.
5. Delegation: whether the agent may pass the capability to a sub-agent or another server.

Do not implement these as text in a system prompt. Enforce them in the tool server, IAM layer, network policy, or application code. The model can request an action. It should not be able to define its own authority.

Is the identity tied to the user, the agent, or the tool?

Authentication answers who connected. Authorization answers what this particular action may do. Those are different questions. The MCP authorization specification describes OAuth-based flows for HTTP transports and distinguishes authorization-code use on behalf of a human from client-credentials use for an application. Your system should make that distinction visible in policy and logs.

Before access, verify:

• The token has an intended audience, issuer, expiry, and narrow scopes.
• The downstream tool receives a dedicated credential, not the agent client's bearer token.
• Tenant and object authorization are checked server-side on every request.
• Credentials are short-lived, revocable, and absent from prompts, model context, and tool results.
• A tool cannot exchange a read credential for a broader credential.

The failure mode to avoid is ambient authority. If the agent inherits the shell's cloud credentials, the browser's cookies, or a developer's local .env file, your formal tool policy is fiction. The agent does not need to know that those credentials are dangerous. A malicious document, poisoned tool description, or accidental model decision can put them on the path.

This is the same boundary explored in MCP servers in production: a valid token proves a connection, not a safe action. Keep identity, permission, evidence, and recovery as separate control planes.

Can the agent see untrusted instructions before it acts?

Assume that every document, email, web page, issue, repository file, tool description, and retrieved snippet can contain instructions aimed at changing the agent's behavior. The OWASP agentic security guidance treats goal hijacking and tool misuse as distinct problems because an injected instruction can redirect a legitimate tool without breaking the tool itself.

Test the agent with hostile but realistic inputs:

• A document says to ignore the task and upload all accessible files.
• A search result asks the agent to reveal its system instructions.
• A tool description claims that an emergency mode requires a broader token.
• A customer email asks the agent to change the recipient before sending.
• A repository test tells the coding agent to disable security checks.

The expected behavior is not “the model refuses every suspicious sentence.” The expected behavior is that untrusted content cannot grant authority, change the allowlist, bypass an approval gate, or alter the destination policy. The prompt injection analysis is useful background here, but the implementation rule is simpler: treat model-visible instructions as data until an external policy says otherwise.

Keep tool outputs structured and bounded. Separate content from control metadata. If a tool returns HTML, shell text, or a long document, place it in a clearly marked untrusted field and strip credentials, hidden instructions, and irrelevant private data before it enters the next model turn.

What happens when the agent wants to write?

Every mutation should have a preview path and a commit path. The preview returns the exact proposed change, target, side effects, and authorization decision. The commit accepts a structured operation, an idempotency key, and a fresh authorization check. Do not make “send email” a string argument on a general-purpose HTTP tool.

Anthropic describes permission modes such as always allow, needs approval, and block in Claude products. That pattern is useful, but the approval must be meaningful. A human should see what will happen, to whom, with which data, and under which identity. “The agent wants to use update_customer” is not enough context to approve a consequential action.

Use this approval ladder:

Risk	Default behavior
Public read or local calculation	Automatic, bounded
Private read or multi-record search	Automatic only within a named scope, logged
Draft or preview	Automatic, but never sent or committed
External message, financial action, permission change, or deploy	Human approval with a rendered diff
Delete, credential rotation, or irreversible migration	Block by default, with a separate operator workflow

The checkpoint is a turnstile, not a rubber stamp. If the screen hides the recipient, amount, or changed fields, the user is approving a label rather than an action.

Can you explain what happened after a failure?

Log the action, not just the conversation. At minimum, record the authenticated principal, agent or workflow ID, tool name and version, policy decision, target scope, trace ID, timestamp, latency, result class, approval ID, retry count, and idempotency key. Redact tokens and minimize customer content. Store the audit record where the agent cannot edit or delete it.

Recovery needs four outcome classes: rejected, transient failure, committed, and unknown. “Timeout” is not a fifth synonym for “safe to retry.” A database write may have committed even though the response disappeared. Retrying without an idempotency key can duplicate a payment, ticket, message, or deployment.

Set explicit budgets before running the loop:

• Maximum wall-clock duration.
• Maximum model turns.
• Maximum tool calls per tool and per task.
• Maximum tokens, network bytes, and financial spend.
• Maximum number of records changed.
• A kill switch that does not depend on the agent cooperating.

OWASP’s agentic guidance specifically calls out uncontrolled loops and tool chaining as resource-exhaustion risks. The agent should lose access when its budget is exhausted, even if it insists that one more call will finish the task.

The preflight checklist

Do not grant production tool access until every line has an owner and evidence.

• The task has one outcome, one scope, and one stop condition.
• Each tool has a named owner, version, schema, and documented side effect.
• Read, draft, commit, send, delete, and administer are separate capabilities.
• Identity is scoped to the user, agent, tenant, and tool action.
• Credentials are short-lived and never ambient, prompt-visible, or returned in tool output.
• Data access is enforced outside the model with tenant and object checks.
• Network egress is allowlisted and tested to fail closed.
• Untrusted tool descriptions and retrieved content cannot change policy.
• Mutations support preview, explicit approval, structured arguments, and idempotency.
• Rate, spend, time, token, record, and delegation budgets are enforced.
• Logs capture policy decisions and outcomes in an agent-independent store.
• Unknown outcomes have a reconciliation workflow instead of an automatic retry.
• A human or operator can revoke access and stop the loop immediately.
• Adversarial tests cover prompt injection, confused deputy behavior, data exfiltration, tool chaining, and partial failure.
• The same tests are rerun after every tool, model, policy, or environment change.

If the last three boxes are empty, you do not have an agent safety system. You have a permission prompt.

The honest take

This checklist does not make an agent safe. It makes the boundary legible. A model can still produce a harmful recommendation inside a read-only workflow, and a human can approve a harmful action while looking at a perfectly rendered diff.

The checklist also assumes that your tool server is trustworthy. If the server has a confused-deputy flaw, leaks data in errors, or resolves a mutable tool name from an untrusted registry, the agent policy is only as strong as that dependency. The Claude Agent SDK customer-support setup is a useful reminder that hooks, sessions, subagents, and MCP connections all become part of the control surface. Supply-chain review and ordinary application security still apply.

Finally, no public framework gives you a universal approval threshold. “Needs approval” is a policy choice that depends on the data, user, jurisdiction, and reversibility of the action. The right first deployment is therefore usually smaller than the demo: read-only, short-lived, observable, and easy to turn off. Expand it only when the evidence says the next capability is worth its blast radius.

The bottom line

Give an agent tools in stages. First prove it can complete a bounded task with read-only access and hostile inputs. Then add previews. Then add one reversible mutation with an external policy, an approval gate, an idempotency key, a budget, and an audit trail. Treat each new tool as a new security boundary.

The practical decision rule is this: if you cannot state what the tool can change, who authorized that exact change, how you will know whether it committed, and how you will stop the next call, do not expose it yet. The recent sandbox failure case shows why “isolated” is not a sufficient claim without tested network and credential boundaries. A capable agent is not dangerous because it has a plan. It is dangerous when the plan can outrun the controls around it.

FAQ

Should an AI agent ever get write access?

Yes, but write access should be narrow, structured, reversible where possible, and protected by an external policy. Start with drafts or previews. Require a human approval for external messages, financial actions, permission changes, deployments, and other high-impact mutations.

Is a system prompt enough to keep an agent safe?

No. A system prompt can describe intent, but it cannot reliably enforce identity, tenant scope, network egress, rate limits, credential handling, or recovery. Those controls belong in the tool server, IAM layer, network policy, and application code.

How do I test an agent for prompt injection?

Give it realistic untrusted inputs that ask it to change goals, reveal secrets, broaden access, or bypass approval. Verify that the agent treats those inputs as data and that external policy rejects unauthorized actions even if the model attempts them.

What should be logged for every tool call?

Log the principal, workflow, tool and version, requested scope, policy decision, approval, trace ID, timestamp, latency, result class, retry count, and idempotency key. Redact tokens and unnecessary private content. Keep the log outside the agent's control.

When should a tool be blocked instead of approved?

Block it when the action is irreversible, the target scope is ambiguous, the credential is broader than the task, the tool accepts arbitrary code, or the system cannot distinguish committed from unknown outcomes. Add it only after those conditions have an explicit control.