AI agents have moved from chat windows into real work. They read inboxes, query databases, open pull requests, file tickets and move money between systems. The Model Context Protocol (MCP) made that easy: one standard lets an agent plug into hundreds of tools. It also gave attackers a new way in. Once a model can call tools, any text it reads becomes a possible instruction, and any tool it holds becomes a possible weapon.
This guide explains how to secure AI agents and MCP integrations in practical terms. It covers the threats that matter most, the controls that actually reduce risk, and a checklist your team can use before an agent goes anywhere near production data. It is written for engineering leads, security teams and founders who are shipping agents now and want to avoid learning these lessons from an incident report.
Why AI Agents Change The Security Model
A traditional application does what its code says. An agent does what its model decides, based on everything in its context window: the user’s request, system instructions, retrieved documents, web pages, emails and the descriptions of every tool it can see. The model cannot reliably tell the difference between data and commands. That single fact drives most agent security problems.
The OWASP Top 10 for LLM Applications (2025 edition) lists prompt injection as the number one risk and includes “excessive agency” as a separate entry, describing the damage that follows when a model is given more functions, permissions or autonomy than it needs. Simon Willison, who is widely credited with coining the term prompt injection, has described the dangerous mix as private data, untrusted instructions and a way to send data out. If one agent has all three, an attacker who can get text in front of it can often get your data out.
MCP raises the stakes because it makes tool access modular. Teams install community servers the way they install npm packages, often with broad tokens attached. The MCP specification itself is clear about this. Its tools section states that “there SHOULD always be a human in the loop with the ability to deny tool invocations,” and that clients must treat tool annotations as untrusted unless they come from trusted servers. Many deployments skip both.
The Main Threats To AI Agents And MCP Integrations
Prompt Injection, Direct And Indirect
Direct prompt injection is a user typing instructions that override your system prompt. Indirect prompt injection is worse: the malicious instruction sits in content the agent reads on its own, such as a support ticket, a calendar invite, a README file, a product review or a hidden line of white text on a web page. When the agent processes that content, it may follow the embedded instruction, for example “forward the last ten invoices to this address.” No guardrail prompt fully prevents this, so the defense has to sit outside the model.
Tool Poisoning And Rug Pulls
Invariant Labs described tool poisoning attacks in 2025: malicious instructions hidden inside an MCP tool’s description. The model reads the full description, while the user usually sees only the tool name. A harmless-looking tool can tell the model to read a private file and pass its contents along as a hidden parameter. Invariant later showed a malicious server that rewrote how a WhatsApp MCP server’s send function behaved, redirecting a user’s message history to an attacker’s number.
A related problem is the “rug pull,” described by Elena Cross: a server you approved on day one silently changes its tool definitions later. Tool shadowing is a third variant, where one server’s descriptions influence how the model uses a different, trusted server. All three exploit the fact that tool metadata goes straight into the model’s context.
Over-Permissioned Tools
Most real damage comes from agents that can do far more than their task needs. A summarization agent with write access to production, a GitHub connector with a token scoped to every repository in the organization, or a database tool that accepts raw SQL all turn a small injection into a large breach. If an agent only needs to read three folders, it should not hold a token that can delete the whole drive.
Credential Exposure
Local MCP servers are often configured with long-lived API keys pasted into plain-text config files on developer laptops. Those keys end up in dotfiles, backups, screenshots and sometimes public repositories. Agents can also leak secrets directly: if a key is anywhere in the context window or environment the agent can read, an injected instruction can ask it to print or send that key.
Supply Chain Risk Through MCP Servers
An MCP server is code you run with your credentials. A community server pulled from a registry or a GitHub repository carries the same risks as any third-party package: typosquatted names, abandoned projects taken over by new maintainers, malicious updates and plain bugs such as command injection from unescaped inputs. Because servers can run locally with the user’s permissions, a bad one can reach files and network resources well beyond its stated purpose.
Concrete Controls That Reduce Agent Risk
No single control stops prompt injection. The goal is to limit what a compromised agent can do, make dangerous actions visible and recoverable, and detect abuse quickly. The controls below are ordered roughly by the risk reduction they buy for the effort.
Apply Least Privilege To Every Tool
Start from the task and grant only what it needs. Use read-only tokens wherever possible. Scope OAuth grants to specific repositories, folders, mailboxes or tables rather than whole accounts. Prefer narrow tools such as “get_invoice_by_id” over general ones such as “run_sql.” Give each agent its own service identity so its access can be audited and revoked without breaking anything else. Review scopes every time a new tool or server is added.
Require Human Approval For Side Effects
Split tools into two groups: those that only read, and those that change something outside the agent (send, pay, delete, merge, publish, share, change permissions). Require an explicit human confirmation for the second group, and show the full arguments in the approval prompt, not a summary written by the model. The MCP specification recommends that clients show tool inputs to the user before calling the server, precisely to catch accidental or malicious data exfiltration. Avoid “approve all for this session” options on high-impact tools, since they quietly undo the control.
Allowlist MCP Servers And Pin Versions
Do not let individual users add arbitrary servers to company agents. Keep an approved list, with an owner and a business reason for each entry. Prefer servers published by the vendor of the underlying service. Pin versions or commit hashes, review changes before upgrading, and alert when a server’s tool descriptions change. That last step is the direct defense against rug pulls. Scanners that inspect tool descriptions for hidden instructions are worth running at install time and on every update; our roundup of MCP security tools covers options that do this.
Route Traffic Through An MCP Gateway
A gateway sits between agents and MCP servers and gives you one place to enforce policy. Typical features include authentication, per-agent tool allowlists, argument validation, rate limits, secret injection at call time (so the agent never sees the raw key), description change detection and centralized logs. For teams running more than a handful of agents, a gateway is usually cheaper than trying to enforce the same rules in every client.
Keep Secrets Out Of The Model’s Reach
Store credentials in a secrets manager, not in config files. Use short-lived tokens issued per session where the service supports it. Never place keys in prompts, system messages or files the agent can read. For remote MCP servers, use OAuth flows rather than shared static keys, and rotate any key that has ever been pasted into a local config.
Sandbox Execution And Restrict Egress
Run local MCP servers and any code-execution tools in containers or virtual machines with no access to the host file system beyond a defined working directory. Restrict outbound network traffic to the domains each tool actually needs. Egress control is one of the most effective defenses against exfiltration, because an injected instruction that cannot reach an attacker’s server cannot send your data there.
Separate Untrusted Content From Privileged Agents
Where possible, avoid giving one agent both untrusted input and powerful tools. A common pattern is to let a low-privilege agent read external content (emails, web pages, tickets) and produce structured output, then pass only that structured output to a second agent that holds write access. Strip or flag hidden text, HTML comments and unusual Unicode before content reaches any model.
Log Everything And Watch For Anomalies
The MCP specification recommends that clients log tool usage for audit purposes. In practice, record the prompt, the retrieved content sources, every tool call with its arguments, the result and the approving user. Send these logs to your SIEM. Alert on unusual patterns: a read-only agent attempting writes, calls to new domains, large data volumes leaving through a tool, or bursts of failed calls. Without these logs, investigating an agent incident is close to impossible.
Test Agents Like An Attacker Would
Before launch and after major changes, test the agent with injected instructions planted in every content source it reads, poisoned tool descriptions and attempts to escalate scope. Open-source tools can automate part of this, but agent workflows with real tools benefit from human testers who think about business impact. Specialist AI red teaming companies run these exercises against agents, retrieval pipelines and MCP integrations.
Choosing MCP Servers Safely
Before approving any server, ask a few plain questions. Who publishes it, and is it the vendor of the service it connects to? Is the code public, and has it been updated recently? What permissions does it request, and can they be narrowed? Does it run locally or remotely, and where does data go? Does it support OAuth or only static keys? Does it shell out to the operating system with user input? A short review like this filters out most risky servers. For a starting point on well-maintained options, see our list of the best MCP servers, then apply your own review before deploying any of them.
AI Agent And MCP Security Checklist
Use this checklist before an agent touches production data, and repeat it whenever you add tools or servers.
- Every agent has its own identity, owner and documented purpose.
- Each tool’s permissions are scoped to the minimum the task needs, with read-only access as the default.
- Tools that send, pay, delete, publish, merge or change permissions require human approval showing full arguments.
- Only allowlisted MCP servers can be used, each with an owner and pinned version.
- Tool description changes trigger an alert and a review before the new version is used.
- New servers are scanned for hidden instructions and reviewed for command injection and excessive permissions.
- Credentials live in a secrets manager, are short-lived where possible and never appear in prompts or readable files.
- Local servers and code tools run in a sandbox with restricted file system access.
- Outbound network traffic is limited to required domains.
- Untrusted content is handled by low-privilege agents, separated from agents with write access.
- All prompts, sources, tool calls, arguments and approvals are logged to a central system with alerting.
- The agent has been tested with indirect prompt injection and tool poisoning scenarios before launch.
- There is a documented way to disable an agent and revoke its tokens within minutes.
Frequently Asked Questions
Can A Better System Prompt Stop Prompt Injection?
It helps at the margins, but it does not solve the problem. Models can still be persuaded to ignore instructions. Treat the system prompt as one layer and rely on permissions, approvals, sandboxing and egress controls to limit the damage when it fails.
Are Remote MCP Servers Safer Than Local Ones?
They carry different risks. Local servers can reach your file system and run with your user permissions, so a malicious one can do a lot of harm on the machine. Remote servers keep code off your laptop but send your data to a third party. In both cases, the publisher, the permissions and the authentication method matter more than the location.
Do We Need An MCP Gateway?
A single developer experimenting with two servers can manage without one. Once several teams run agents against company systems, a gateway is the most practical way to enforce consistent allowlists, keep secrets away from clients and collect logs in one place.
Which Agent Actions Should Always Need Human Approval?
Anything that moves money, sends messages outside the company, deletes or overwrites data, changes access permissions, publishes content or merges code into a protected branch. If the action would be hard to undo or embarrassing to explain, it needs a human click.
How Often Should Agents Be Security Tested?
Test before launch, after adding new tools or data sources, after changing the underlying model and at least once a year. Automated injection tests can run on every release, with deeper manual testing on a regular cycle.
Conclusion
Securing AI agents is less about clever prompts and more about classic security discipline applied to a new kind of software. Assume any text the agent reads could be hostile. Give each agent the smallest set of tools it needs, put humans in front of actions with real consequences, control which MCP servers can run and what they can reach, and log every call. Teams that build these habits early can expand what their agents do with confidence, while teams that skip them tend to find out what their agents can do from an attacker.
