Your engineers already connected an AI agent to production
Somewhere in most organisations right now, a developer has wired an AI coding assistant or an internal agent into a live system using the Model Context Protocol. It reads from a ticketing tool, queries a database, maybe opens pull requests or sends email. It works, it saves hours, and nobody in security was asked to sign off on it. That gap between what the business has deployed and what the security team knows about is where the interesting failures live.
We have spent the last two years watching MCP go from a niche idea to the default way agents talk to the rest of the stack. The protocol is genuinely useful. It also quietly moved a trust boundary that most existing controls were never designed to police, and the incident record from 2025 into 2026 shows exactly what happens when that goes unmanaged. This article is a working account of the risk, drawn from how we assess and harden these deployments in banking, telecom, and critical national infrastructure environments.
What MCP changed, in plain terms
The Model Context Protocol is a client-server standard that lets an AI agent connect to external tools and data sources through one consistent interface. Instead of hand-coding an integration for every system, you run an MCP server in front of a backend, the agent discovers the tools it exposes, and it calls them with typed parameters. One agent can reach many backends; one backend can serve many agents. That N-to-M convenience is the whole point.
Here is the part that matters for security. The agent decides which tool to call and with what arguments, and it makes that decision partly based on text it reads at runtime, text that can come from a code repository, a support ticket, a web page, or an email. So the instruction that triggers a privileged action is no longer written only by your developers. It can be influenced by whatever content the agent happens to ingest. A component that can both read untrusted data and take real actions on your systems is a new class of thing, and it sits inside your network with credentials attached.
The trust boundary moved, and the old map is wrong
Traditional application security assumes a fairly clear line between code you control and input you do not. MCP blurs that line. The agent is code you control, but its behaviour is steered by data you often do not control, and it holds tokens that let it act. When we run a threat model on one of these setups, the first finding is almost always the same: the team drew the trust boundary around the agent's container, when the real boundary runs through every source of text the agent reads.
The incidents are not hypothetical
Skeptics reasonably ask whether this is a real attack surface or a theoretical one. The public record settled that question over 2025 and 2026. A few of the documented cases are worth naming, because each one maps to a control that was missing rather than to some exotic exploit.
In May 2025, researchers demonstrated an attack on the GitHub MCP server where a malicious public issue carried hidden instructions. An assistant reading that issue was hijacked, and because its access token was over-privileged, it exfiltrated details from private repositories. This is the technique the community calls tool poisoning, and it is prompt injection applied to an agent that holds real credentials. Around the same time, a malicious WhatsApp MCP server was shown rewriting the behaviour of a legitimate send-message tool to copy entire chat histories to an attacker's number, slipping past data-loss-prevention tooling by looking like normal outbound traffic.
The supply chain took hits too. The mcp-remote proxy carried a command-injection flaw (CVE-2025-6514) affecting more than 400,000 downloads, turning unpatched installs into a backdoor that could steal API keys and SSH credentials. Anthropic's own MCP Inspector had an unauthenticated remote-code-execution issue (CVE-2025-49596) that exposed developer workstations. A hosted Asana MCP server leaked data across tenant boundaries because of an access-control logic flaw. A trojanised Postmark server quietly BCC'd every email it handled to an attacker. By 2026 the pattern was clear enough that the NSA published dedicated guidance on securing MCP deployments.
None of these required a nation-state. They required an over-privileged token, an unauthenticated endpoint, an unvetted package, or an agent that treated untrusted text as trusted instruction. Those are ordinary security failures wearing new clothes.
Mapping the risk to something you can act on
The OWASP Top 10 for LLM Applications (2025 edition) gives a useful vocabulary here, and most MCP incidents land squarely on a handful of its entries. We use it as a checklist when scoping an assessment because it forces the conversation past "the AI did something weird" and toward specific, testable weaknesses.
OWASP LLM riskHow it shows up in an MCP deploymentPrimary control
LLM01 Prompt Injection
Untrusted text in a ticket, repo, or email steers the agent into calling a tool it should not
Input isolation, spotlighting, planner/executor separation
LLM06 Excessive Agency
Agent holds broad tokens and can act far beyond the task at hand
Least-privilege scopes, human approval for sensitive actions
LLM02 Sensitive Information Disclosure
Agent reads secrets or cross-tenant data and surfaces it in output
Data minimisation, tenant isolation, output filtering
LLM03 Supply Chain
Malicious or trojanised MCP server pulled from a public registry
Package provenance, pinned versions, internal registry
LLM05 Improper Output Handling
Agent output is passed unvalidated into a shell, query, or downstream API
Output validation and encoding at every sink
LLM10 Unbounded Consumption
An agent loop runs up cost or hammers a backend into a denial of service
Rate limits, budget caps, circuit breakers
The value of this mapping is that every row points to a control your team can implement with tools it already owns. Nothing on that list needs a specialist AI-security product to fix. It needs the same discipline you apply to any service that holds credentials and talks to the internet.
How we contain an agent-plus-MCP deployment
When a client asks us to make one of these systems safe to run, the work breaks into layers. No single layer is sufficient on its own, which is exactly why prompt injection has no one-line fix. You stack defences so that each one catches what the others miss.
Cut the agent's privileges to the bone
Excessive agency is the risk that turns a nuisance into a breach. An agent that can only read the three tables it needs, on a token scoped to those tables, is a far smaller problem than one holding an organisation-wide personal access token. We scope every credential to the specific task, issue short-lived tokens where the backend supports them, and separate read access from write access so that a compromised read path cannot mutate data. This is straight least-privilege, the same principle behind CIS Controls and ISO 27001 access management, applied to a non-human identity.
Keep untrusted content away from the tools
Two model-level techniques help. Spotlighting wraps untrusted text in explicit control markers and tells the model to treat everything inside as data, never as instruction. Instruction hierarchy ranks the developer's system prompt above the user's message, and both above any third-party content the agent reads. Neither is bulletproof alone. The stronger structural move is a planner/executor split: one model plans with tool access but never sees raw untrusted content, and a second model reads the untrusted content but holds no tools. An attacker then has to compromise two separated components instead of one.
Put a human in front of anything that matters
For actions that move money, delete data, change configuration, or send external communications, an explicit approval step is worth the friction. The agent proposes, a person confirms. In the banking work we do, this maps naturally onto existing maker-checker controls, so it rarely feels like a new process to the business, only a new actor being subjected to an old one.
Treat the MCP server as software you have to vet
Most of the supply-chain incidents came from pulling a server straight off a public registry and running it with real credentials. We vet provenance, pin versions, review the code where the server is small enough to read, and run it from an internal registry rather than fetching the latest build at deploy time. An MCP server is a process with network access and often filesystem access. It deserves the same scrutiny as any other dependency in a regulated pipeline.
Isolate the runtime and watch it
Run MCP servers in their own network segment, deny egress by default, and allow only the specific destinations each tool needs. For the most sensitive environments, and we build a fair number of air-gapped and on-premises deployments for CNI clients, the agent and its models run without any path to the public internet at all. Every tool call, argument, and result should be logged and shipped to your SIEM, because an agent's decision to call a tool is a security-relevant event and your SOC needs to see it. Anomaly detection that already watches human behaviour can be extended to watch the agent's, and a tool invocation that falls outside the agent's normal pattern is exactly the kind of signal worth alerting on.
A checklist before you connect an agent to anything real
We hand teams a short version of this list during workshops. If you cannot answer yes to all of these, the deployment is not ready for production data.
- Is every credential the agent holds scoped to the minimum it needs, and short-lived where possible?
- Are write, delete, and external-send actions gated behind human approval?
- Is untrusted content structurally separated from the component that holds tools?
- Is the MCP server pinned to a reviewed version pulled from an internal, not public, source?
- Does the runtime deny outbound network access by default, allowing only named destinations?
- Is every tool call logged and forwarded to your SIEM with enough context to investigate?
- Are there rate limits and cost caps that stop a runaway loop before it becomes an outage or a bill?
- Has someone threat-modelled the deployment against the OWASP LLM Top 10, with findings tracked to closure?
Where this lands in your compliance programme
None of this sits outside the frameworks you already report against. An AI agent is an identity with access, so it falls under your access-control and least-privilege obligations in ISO 27001 and the CIS Controls. If it can reach cardholder data, PCI-DSS scoping and segmentation rules apply to it exactly as they would to any other service, and "an AI did it" is not a control the assessor will accept. The NIST Cybersecurity Framework maps cleanly onto the layered approach above: identify the agent and its data flows, protect with least privilege and isolation, detect through SIEM logging, and respond with the same runbooks you use for any credentialed service that misbehaves. The work is less about inventing new controls and more about recognising that a new kind of actor now falls inside the old ones.
The organisations that handle this well are not the ones that banned agents, and they are not the ones that let every team wire up MCP servers unsupervised. They put a light governance layer in place early, gave developers a paved path with the controls already built in, and kept their SOC in the loop. That balance is achievable without slowing delivery to a crawl, provided the security thinking happens alongside the build rather than after the incident.
How Aydahwa Enterprise Can Help
We help organisations adopt AI agents and MCP integrations without opening the kind of hole the 2025 and 2026 incident record keeps illustrating. Our team holds credentials including ISO 27001, PCI-DSS, SOC 2, and the Microsoft Cybersecurity Architect Expert certification, and we bring more than 25 years of hands-on infrastructure and security architecture experience across banking, telecom, and critical national infrastructure, including air-gapped and on-premises environments where a public-internet path is not an option.
A typical engagement starts with a threat model of your current or planned agent deployment against the OWASP LLM Top 10, moves into hardening the runtime, credentials, and MCP supply chain, and ends with SOC integration so your analysts can actually see what the agents are doing. If you want to gauge where you stand first, our free cybersecurity self-assessment and cybersecurity readiness checklist are a fast way to start. You can read more about our cybersecurity services and cloud security and migration work, or reach the team through our managed IT support line. When you are ready to talk specifics, get in touch and we will scope it with you.
AI agents are going to keep spreading through the enterprise because they earn their keep. The task in front of security teams is to make sure each new agent is a governed, monitored, least-privileged actor rather than an unsupervised one holding the keys. That is ordinary security discipline applied to an unusual new participant, and it is very much within reach.
