The Model Context Protocol made connecting agents to tools easy, which is exactly the problem. The risks that matter in production (tool output as an injection channel, over-broad tokens, unreviewed servers) and how Gateway, Identity and Policy on AgentCore, or your own controls, contain them.
An MCP server exposes tools an agent can call: read a ticket, query a database, send a message. Before MCP, every integration was code someone wrote and reviewed. Now a new capability is a configuration line, and an agent can be given dozens of tools from servers nobody on the team has read. The agent then decides, from text, which to call and with what arguments.
Book a free 30-minute call. You'll leave knowing what we'd do first and roughly what it costs, whether or not you hire us.
Injection through tool output: a ticket, email or web page the agent reads contains instructions, and the agent follows them with whatever other tools it holds. This is the most common real-world failure, and no prompt fully prevents it.
Over-broad credentials: a server configured with an admin token gives every agent that uses it admin rights, whatever the user asking was allowed to do.
Unreviewed servers: a third-party MCP server is code running with your credentials. Treat it like any dependency — pin versions, review changes, prefer official servers.
Tool descriptions as instructions: a server's tool descriptions are sent to the model, so a malicious or careless description can steer the agent.
Act as the user, not as the agent. Pass the user's own scoped credentials to tools — AgentCore Identity's on-behalf-of flows exist for this — so the agent can never do more than the person who asked.
Put a deterministic check in front of consequential tools. AgentCore Policy evaluates every tool call through Gateway before it runs; elsewhere, a small authorisation layer in your own tool server does the same job.
Separate reading untrusted content from taking actions. An agent that has just read an external email should not, in the same step, hold a tool that sends money.
Require human confirmation for irreversible actions, shown as a clear summary of exactly what will happen.
Log every tool call with its arguments and the identity behind it, and alert on unusual patterns — new tools, new destinations, volume spikes.
Centralise tools behind one gateway with an allowlist, rather than letting each agent load servers from its own configuration.
Once a month: what changed in tech that month and what it means for you, from cloud and AI to security and the tools you build with. Every item links to its source. No sales pitch, unsubscribe in one click.
Book a free 30-minute call about it. Bring your setup and your bill; you'll leave knowing what we'd do first and roughly what it costs, whether or not you hire us.
Or keep reading
EKS and AI Agents: Running Agents on Kubernetes, and Letting Agents Operate Your Clusters
Two different problems. Running agents on EKS is about long-lived workers, GPUs, sandboxes for code they write, and tight egress. Letting an agent operate EKS, through the EKS MCP server or kubectl, is about read-only by default, separate roles for writes, and approvals. The setups that are safe enough to use.
Read
Prompt Injection Defenses for Tool-Using Agents: What Works in 2026
No prompt or classifier reliably stops prompt injection. What does work is architecture: limiting what an agent can reach, keeping private data, untrusted content and outbound channels apart, and putting approvals on side effects. A practical checklist mapped to the OWASP Top 10 for LLM Applications.
Read
As of October 25, 2026. Provided as is, for general information, and accurate to the best of our knowledge on the date shown. Not legal, compliance, tax, financial or other professional advice. Prices, limits and vendor services change; check current vendor documentation before relying on anything here. Terms of use.