Security Checklist: Before You Connect an AI Agent to Your Tools

Connecting an AI agent to your tools is where it becomes useful, and where it becomes risky. A model that can read your repository, query your database, and post to your team chat can save hours. The same capabilities, misused or manipulated, can leak data or make changes nobody intended.

This checklist is for developers and small teams wiring agents into real systems, whether through MCP servers or another integration method. It is not exhaustive, but it covers the failure modes that matter most in practice.

The core risk in one sentence

An agent combines three things: access to private data, exposure to untrusted content, and the ability to take actions or communicate externally. When all three are present in the same session, a malicious instruction hidden in untrusted content can lead the agent to send private data somewhere it should not go.

Keep that combination in mind. Many of the items below are ways to break it.

1. Vet the agent and the servers

• Know who publishes it. Prefer official servers from the vendor of the system you are connecting, or open-source projects with visible maintainers and recent activity.
• Read the code or at least the tool list. Know every tool the server exposes and what each one can do.
• Pin versions. Running npx some-server without a version pulls whatever is latest. Pin a version you have reviewed, and update deliberately.
• Watch for lookalike names. Typosquatted packages are a known supply-chain risk in every package ecosystem.
• Check where it sends data. A local server should not need to call unrelated external endpoints.

2. Apply least privilege

• Create dedicated credentials for the agent instead of reusing your personal token.
• Scope tokens narrowly. Read-only where possible. Limit to specific repositories, projects, channels, or tables.
• Restrict file system access to the directories the task needs. Many servers accept an allowlist of paths; use it.
• Use separate database users with only the grants required, ideally against a replica or staging copy for exploratory work.
• Turn off tools you don’t need. Many clients let you disable individual tools from a server. A smaller toolset is both safer and easier for the model to use well.

3. Handle secrets properly

• Never paste secrets into prompts or chat. Anything in context may be logged, echoed back, or sent to a tool.
• Keep secrets out of committed config files. Project-level MCP configs are easy to commit by accident. Use environment variables, your client’s secret input mechanism, or a secrets manager.
• Prefer OAuth for remote servers when supported, so access is scoped, visible, and revocable from the service’s settings.
• Rotate tokens on a schedule and immediately if you suspect exposure.
• Make sure the agent cannot read its own credentials. If an agent has file access to the folder containing your .env file, it can read it.

4. Defend against prompt injection

Prompt injection happens when content the model reads, such as a web page, an email, a code comment, an issue description, or a tool result, contains instructions the model then follows. It is not a bug in one product; it is a property of how language models process text. There is no complete fix today, so defenses are layered.

• Treat all tool output as untrusted input. Especially from web browsing, email, tickets submitted by outsiders, and public repositories.
• Separate reading from acting. Avoid giving a single session both broad read access to untrusted content and the ability to send data externally.
• Limit exfiltration channels. Be cautious with tools that can make arbitrary HTTP requests, send messages, or create public links. Rendering images from arbitrary URLs can also leak data through the URL.
• Be wary of tool descriptions. A malicious server can put instructions inside tool names or descriptions, which the model reads. This is another reason to vet servers and pin versions.
• Watch for unexpected tool calls. If a summarization task suddenly wants to send an email, stop and investigate.

5. Keep humans in the loop for consequential actions

• Require approval for writes. Creating, updating, deleting, sending, merging, deploying, and paying should need a human click.
• Read what you approve. Check the tool name and the arguments, not just the summary the model gives you.
• Avoid blanket “always allow” except for read-only tools you have reviewed.
• Use dry-run modes where tools support them.

6. Contain the blast radius

• Sandbox code execution. Run coding agents in containers, dev environments, or VMs rather than on a machine with production credentials.
• Work on branches. Let agents propose changes through pull requests that go through normal review and CI.
• Restrict network egress for sandboxes where possible.
• Use non-production data for experiments.
• Have a rollback plan. Backups, version control, and soft-delete make mistakes recoverable.

7. Log and review

• Keep logs of tool calls, including arguments and results, where your client or server allows it.
• Review logs periodically, especially after enabling a new server.
• Monitor the connected services for unusual activity from agent credentials. Dedicated credentials (see section 2) make this much easier.
• Know how to revoke access quickly. Write down where each token was issued and how to kill it.

8. Set team rules

For teams, individual diligence is not enough. Agree on:

• Which agents and servers are approved, and who approves new ones.
• Which data classes may never be exposed to agents (customer PII, credentials, regulated data).
• Whether project-level MCP configs may be committed, and what they may contain.
• Who to contact when something looks wrong.

A short written policy beats an unwritten assumption. If you are just getting started with agents as a team, our article on AI agent use cases for small teams suggests low-risk places to begin.

A quick pre-flight table

Question	Good answer
Who maintains this server?	A known vendor or active open-source project
What can it do?	Only what this task needs
What credentials does it use?	Dedicated, scoped, revocable
Does it read untrusted content?	If yes, it cannot also send data externally without approval
Are writes approved by a human?	Yes
Can we undo its actions?	Yes
Are calls logged?	Yes

Summary

You do not need to avoid agents to stay safe. You need to give them the smallest useful set of permissions, keep secrets out of their reach, treat everything they read as potentially hostile, and keep a human in front of anything irreversible.

Part of the goal of AgentZone is to make the vetting step easier, with notes on what each listed server accesses and how it is configured. The directory is launching soon.