AI Agent Security Checklist: Before You Connect Any Tool
Key Takeaways
- Before you connect any AI agent to a tool, answer three questions: what can it reach, what can it change, and what will you see it do?
- Permissions should follow least privilege: the narrowest access that does the job, read-only first, write access only where a real task needs it.
- Require human approval for every destructive action — delete, send, publish, pay, change a permission — no exceptions for convenience.
- Tool output is untrusted data, not instructions. Anything a tool returns could contain text written by someone else, and the model must not obey it as if it came from you.
- This checklist reduces risk. It does not guarantee security, and no checklist can.
AI agents are useful precisely because they can act: search your data, file your tickets, send your messages, update your systems. That same power is the risk. An agent with broad permissions, no approval step and no audit log is not a productivity tool; it is an unguarded door into every system it can reach. This checklist is the lock, the alarm and the logbook, in one page you can copy and use before every new connection.
The risks, in plain language
Most agent security problems come from a small set of recurring patterns, documented across MCP and agent security guides in 2026.
| Risk | What happens | Why it matters |
|---|---|---|
| Tool poisoning | A tool’s description or metadata hides instructions the model reads but you never see | The model follows instructions from a server author, not from you |
| Indirect prompt injection | Attacker-controlled text inside a document, ticket or web page steers the model | Reading a file becomes running someone else’s instruction |
| Over-broad permissions | An agent given “access to the CRM” can read, edit and delete everything | One compromised agent has the same power as a careless admin |
| Credential exposure | API keys or tokens sit in prompts, configs or tool output | A leaked key is usable by anyone who finds it, until revoked |
| Shadow servers | Team members connect unvetted servers nobody inventories | You cannot protect a connection you do not know exists |
The pattern underneath all five is the same: the agent’s reach exceeds the user’s intent, and nobody notices until after the fact. Every item on the checklist below exists to close one of those gaps.
The checklist: copy this table before you connect
| # | Check | Done when |
|---|---|---|
| 1 | Inventory the connection | The server or tool, its author, its version and its owner are written down in one place |
| 2 | Vet the source | You have checked the author and, where possible, the code; no typosquatted or unknown package |
| 3 | Apply least privilege | The connection has the narrowest scope that does the job — one folder, one project, one queue, not everything |
| 4 | Start read-only | Write access is off until a real task needs it, and then only for that task |
| 5 | Require approval for destructive actions | Delete, send, publish, pay and permission changes all pause for a human |
| 6 | Keep secrets out of prompts | Keys and tokens live in the server or a secrets manager, never in prompts or shared configs |
| 7 | Scope data sent to the model | Only the data the task needs is sent; sensitive fields are excluded or redacted first |
| 8 | Treat tool output as data | Returned text is never obeyed as an instruction; suspicious content is flagged, not followed |
| 9 | Validate tool inputs | Arguments are checked against a schema before the tool runs; unexpected input is rejected |
| 10 | Log every call | Caller, tool, arguments, result and timestamp are recorded and reviewable |
| 11 | Set limits | Maximum steps, retries and tokens per run, plus rate limits, are configured before production use |
| 12 | Plan revocation | You know how to remove the connection and rotate its credentials in under five minutes |
| 13 | Review on a schedule | Connections are reviewed regularly; unused ones are removed, not left connected |
| 14 | Human review for consequential output | Anything that reaches a customer, a record or a payment is reviewed by a person first |
Permissions: the section that matters most
If you do only one thing from this checklist, do least privilege properly. “Access to the CRM” is not a permission; it is an abdication. The permission you want reads like this: “Read tickets in project X, create tickets in project X, no delete, no export, approval required for sending.” Every word in that sentence removes a class of accident.
Two habits make least privilege practical. First, use scoped tokens per connection, so revoking one connection does not break the others and a leaked token has a narrow blast radius. Second, separate the agent’s identity from yours where the system allows it: an agent acting as “you” inherits your full authority, while an agent acting as a service account with its own narrow role inherits only what you deliberately gave it.
Data, secrets and logging: the three disciplines
Data sent to the model is data disclosed. Before a task runs, ask what the model will see: full documents or just the relevant excerpt? Customer names or anonymised rows? The model provider’s retention and training policies apply to whatever you send, so sending less is not just a privacy nicety, it is a scope decision. Exclude sensitive fields before they reach the prompt, not after.
Secrets belong in a secrets manager, never in a prompt. A prompt is logged, copied, shared and sometimes pasted into a screenshot. A key in a prompt is a key you have already lost control of. The server or tool should hold credentials and use them without showing them to the model, and tool results should never echo a credential back into the conversation.
Logging is how you find out what happened. Without a log, a bad outcome is a mystery: you know something went wrong, but not which tool, which arguments or which user triggered it. Log the caller, the tool, the arguments, the result and the timestamp. Review the log when something surprises you, not just when something breaks.
How this connects to existing coverage
The risks above are not theoretical. Socure’s agent trust scores show how the industry is trying to measure whether an agent can be trusted, and the OpenAI–ServiceNow partnership shows the governed-action pattern: agents that act inside enterprise workflows, with controls around what they may do. On the funding side, Infisical’s $40 million Series B for AI agent security shows investors betting that agent security tooling is a real category, not a footnote. And for the protocol layer underneath, see what AI agents are and how they work.
Troubleshooting: what to do when something looks wrong
- An agent did something you did not approve: revoke the connection first, then read the log. Fix the permission, not just the prompt, because the prompt was not what failed.
- You find a server nobody recognises: treat it as unvetted until proven otherwise. Remove it, ask who added it, and add it to the inventory only after vetting.
- A tool returns suspicious instructions: do not follow them, do not paste them into another prompt, and report the server. Treat the output as data from an untrusted source.
- Credentials appear in a conversation or log: rotate them immediately. A credential that has been displayed is a credential that has been disclosed, even if nobody admits to copying it.
Limitations
This checklist is editorial guidance drawn from public security guides; it is not a compliance standard, and following it does not guarantee security or satisfy any specific regulation. Threats evolve, and new attack techniques against agents appear regularly, so treat this checklist as a baseline to review, not a one-time pass. For regulated data or high-stakes systems, get advice from a qualified security professional.
