MCP Turned Every AI Agent Into a Client of Your Internal Systems
Two years ago, an LLM inside your business could read text and write text. That was the whole threat model. Today, through the Model Context Protocol (MCP), the same model can query your production database, open a ticket in your service desk, push a commit, pull a customer record, or trigger a payment run. The protocol standardised how agents call tools, and adoption moved fast because it solved a real integration problem. The security work to match it did not move at the same speed.
We have spent the last year helping teams wire agents into banking, telecom, and critical-national-infrastructure environments, and the pattern repeats. Engineering ships an MCP server in a sprint because the SDK makes it a few hundred lines of code. Nobody scopes what that server is allowed to touch, nobody logs the tool calls, and the credentials it runs under are the same broad service-role keys the rest of the platform uses. That is not a hypothetical. In mid-2025 a widely used Supabase MCP configuration combined a privileged service-role token with untrusted text pulled straight from customer support tickets, and an attacker was able to smuggle instructions through a ticket that made the agent run SQL it was never meant to run and leak data back out. One server, one over-broad token, one channel of untrusted input. That is the shape of nearly every MCP incident we investigate.
In June 2026 the NSA published a Cybersecurity Information Sheet specifically on MCP, which tells you the problem is no longer confined to early adopters. This article lays out how we secure MCP deployments in production, the attack classes worth treating as real, and how each control maps back to the standards most of our clients already answer to.
What Actually Changes When You Add MCP
The uncomfortable part of MCP is that the model becomes a confused deputy by design. The agent holds the server's privileges, and it decides what to do with them based on text it reads at runtime. Some of that text is a legitimate user request. Some of it is a tool description written by whoever authored the server. Some of it is data returned from a previous tool call, which may itself contain content an attacker planted. The model cannot reliably tell these apart, because to the model they are all just tokens in a context window.
That collapses a boundary security teams have relied on for decades. In a normal application, the code path that talks to the database is fixed and reviewed. With an agentic tool loop, the "code path" is chosen on the fly by a probabilistic system reading attacker-influenceable input. So the questions we ask on an MCP review are not really new questions. They are the same identity, least-privilege, and network-segmentation questions we ask about any service, applied to a component whose control flow is unusually easy to hijack.
The Attack Classes We Treat as Real
Not every theoretical MCP attack deserves equal weight. These are the ones we have either seen exploited or consider likely enough to design against from day one.
Attack classHow it worksWhat it costs you
Indirect prompt injection
Malicious instructions arrive inside data the agent reads — a support ticket, a web page, a document, a prior tool result — and the model follows them.
Unauthorised tool calls under the agent's identity. This is the root cause behind most real incidents.
Tool poisoning
A tool's name, description, or parameter schema carries hidden instructions that steer the agent, invisible to the human who approved the server.
The agent behaves against your interest even when the user request was benign.
Confused deputy / over-permissioned tools
The server runs with broad credentials (admin DB role, wildcard API scope) and the agent inherits all of it.
A single successful injection reaches everything the token can reach.
Rug pulls and version drift
A third-party server behaves during review, then changes its tool definitions after you have granted trust, or a dependency is swapped upstream.
Trust granted once is silently abused later.
Supply-chain / typosquatted servers
A malicious or impersonating server is pulled from a public registry and installed without provenance checks.
Compromise before the agent ever runs a real task.
Token and secret exfiltration
Injected instructions coax the agent into reading environment variables, config, or credential stores and returning them in output.
Lateral movement well beyond the original server.
The through-line is that four of these six only matter because the agent had more privilege, more reach, or more trust than the task in front of it required. Fix the privilege model and you shrink the blast radius of the others.
Identity: Kill the Shared Service Key First
The most common finding in our MCP assessments is a server authenticating with one long-lived, high-privilege key shared across every user and every agent session. When that is what you have, an audit log tells you an action happened but never who it happened for, and one leaked key is total compromise.
The MCP authorization specification now builds on OAuth 2.1, and that is the direction to standardise on. Treat each MCP server as a protected resource and each agent session as a client that must present a token minted for a specific user, with specific scopes, that expires. In practice, for the Microsoft-centric estates we work in most, that means fronting the server with Entra ID, issuing short-lived tokens per session, and carrying the real user identity through to the tool call so authorization decisions and audit records reflect a person, not a robot account. Okta, Entra ID, or any OIDC provider you already run for SSO is the right anchor here. You do not need a new identity silo for agents. You need the one you have to reach the tool layer.
Least Privilege at the Tool Level, Not the Server Level
Granting an agent access to an MCP server is not a single yes-or-no decision. A server may expose a dozen tools, and an agent almost never needs all of them. We scope access per tool and default to deny: an agent gets the read-only lookup it needs for its job and nothing that writes, deletes, or moves money unless that is explicitly its function.
Role-based access control belongs at the tool boundary. A summarisation agent reading knowledge-base articles and a reconciliation agent posting ledger entries should hold different token scopes even if they call into the same server. Where a tool can take irreversible action — issuing refunds, deleting records, changing access rights — we keep a human approval step in the loop rather than letting an autonomous agent execute it on the strength of a text instruction it read. For our banking and payments clients this is also where PCI-DSS obligations land squarely on the design, because an over-scoped agent touching cardholder data is a control failure regardless of whether it was ever exploited.
Contain the Server and Control What It Can Reach
Every MCP server should run in its own isolated container with a minimal image, a read-only filesystem where possible, no privilege escalation, and dropped Linux capabilities. This is standard hardening, and it maps directly to CIS Benchmarks for Docker and Kubernetes, which most of our clients are already measured against.
Network egress is the control people skip, and it is one of the most valuable. An MCP server that only ever needs to reach one internal database has no business making outbound calls to the public internet. Default-deny egress with an explicit allow-list turns "the agent was tricked into exfiltrating data to an attacker endpoint" from a quiet success into a blocked connection and an alert. We put a gateway or proxy in front of the tool layer for exactly this reason: it gives you one place to enforce allow-lists, rate limits, and inspection across every server instead of trusting each one to police itself.
Know Where Your Servers Come From
The public MCP server registries are useful and also exactly the kind of open supply chain attackers target. We do not let a third-party server into a client environment on the strength of its README. The process is boring and it works: maintain an internal registry of approved servers, verify provenance and signed artifacts before anything is admitted, pin versions so a rug pull cannot land silently, and re-review on update rather than auto-pulling latest. Supply-chain attestation on the container image ties the running server back to a build you actually trust. This is the same software-supply-chain discipline ISO 27001 and NIST CSF already expect for any third-party component; MCP servers are third-party components, and they run with your agent's privileges.
Log Every Tool Call Into the SOC
If your SIEM cannot answer "which agent, acting for which user, called which tool with which parameters, and what came back" then you do not have monitoring, you have hope. Structured logging of every MCP request — identity, tool, arguments, result, timestamp — routed into your existing SIEM is what turns an agent from an invisible actor into something your SOC can actually watch. Most serious MCP tooling emits OpenTelemetry and drops cleanly into Splunk, Sentinel, or whatever platform is already in place.
Once the telemetry is there, the detections write themselves: an agent calling a tool it has never called before, a spike in tool invocations, parameters that do not match the shape of a legitimate request, output containing something that looks like a credential. In our SOC engagements these behavioural rules catch the injection attempts that slipped past the input controls, which is the whole point of defence in depth.
Mapping the Controls to Standards You Already Report Against
None of this sits outside the frameworks our clients are audited on. It maps cleanly, and framing it that way tends to free up the budget and the sign-off.
- NIST CSF — server inventory and provenance under Identify; identity, least-privilege scoping, egress control and isolation under Protect; SIEM telemetry and behavioural detections under Detect; agent-aware runbooks under Respond and Recover.
- ISO 27001 — MCP servers are assets and third-party suppliers, so they inherit access control, supplier security, logging, and change-management clauses you are already certified against.
- PCI-DSS — any agent that can reach cardholder data falls in scope; least-privilege tool access, segmentation, and full audit logging are direct requirements, not nice-to-haves.
- CIS Benchmarks — the container and host hardening for where these servers run.
A Deployment Checklist Before an MCP Server Goes to Production
This is the list we run before signing off an MCP deployment. If a server cannot clear it, it does not ship.
- The server authenticates per session with short-lived OAuth 2.1 tokens carrying real user identity, not a shared service key.
- Tool access is scoped per tool with default-deny; the agent holds only what its task requires.
- Any irreversible or high-value tool action requires human approval in the loop.
- The server runs in an isolated, hardened container with no privilege escalation.
- Outbound network egress is default-deny with an explicit allow-list, enforced at a gateway.
- The server came from an approved internal registry with verified provenance and a pinned version.
- Every tool call is logged with full context and routed to the SIEM.
- Behavioural detection rules for anomalous tool use are live before, not after, go-live.
- An incident runbook exists for revoking the server's tokens and permissions in minutes.
How Aydahwa Enterprise Can Help
We help organisations across banking, telecom, and critical infrastructure adopt agentic tooling without opening a new front for attackers. That work spans MCP and agent-security architecture reviews, identity and least-privilege design against Entra ID and your existing SSO, container and network hardening to CIS Benchmarks, and standing up the SOC detections that make agent activity visible. Our team holds credentials including the Microsoft Cybersecurity Architect Expert certification and works to ISO 27001, PCI-DSS, SOC 2, and NIST CSF, so the controls we put in place are ones your auditors will recognise.
If you are wiring agents into production systems and want a second set of eyes before something reaches your data, our cybersecurity services and cloud security and migration teams can review the design and the deployment. For estates that need ongoing operational cover, our managed IT and support practice keeps the monitoring and patching running. You can gauge where you stand today with our free cybersecurity self-assessment and the cybersecurity readiness checklist, and when you are ready to talk specifics, get in touch.
