MCP went from experiment to production faster than security could keep up
In under two years, the Model Context Protocol has gone from a niche way to wire a language model into a tool to a default part of how enterprises build with AI. Anthropic reported roughly 97 million monthly SDK downloads by December 2025, and there are now more than 10,000 active public MCP servers. By early 2026, Truto estimated that around 28% of Fortune 500 companies had MCP servers running in production workflows. That is a serious adoption curve for a protocol that is barely out of its first major revision.
The security posture behind that curve has not kept pace. An Astrix audit of over 5,200 MCP servers found only 8.5% using OAuth, while 53% still leaned on static API keys. A separate Zuplo survey put the share of MCP servers with no authentication at all somewhere around a quarter. In July 2025, Trend Micro found 492 MCP servers exposed to the public internet with zero authentication. We have walked into environments that looked mature on paper and found exactly this: a working agent, a useful set of tools, and a trust model that nobody had actually designed.
This article is a practitioner's view of what changes when you put MCP and autonomous agents into an enterprise, where those deployments tend to break, and the control baseline we use to make them safe enough to run against real data. It is written for architects and security leads who are past the demo stage and now have to answer for what these systems can reach.
What agents and MCP actually change about your attack surface
It helps to be precise about the three moving parts, because they are often lumped together. MCP is an open protocol that gives a model a standard way to connect to external tools and data, whether that is an API, a database, or an application like Gmail, Slack, or GitHub. Retrieval-augmented generation (RAG) is a pattern where the model pulls fresh information at query time from documents, PDFs, or databases so it answers from current data rather than its training set. An AI agent is the system that plans and acts on its own, deciding which tools to call and in what order, rather than sitting in a simple request-and-response loop.
From request-response to autonomous action
A chatbot answers. An agent does. That single shift is where most of the new risk lives. When a model can call a tool that deletes a record, moves money, opens a firewall rule, or emails a customer, the blast radius of a bad decision stops being a wrong answer and becomes a real-world action. The Replit production database incident, where an agent wiped data despite explicit instructions not to, is the cautionary tale people cite because it shows what "autonomous" costs when the guardrails are advisory rather than enforced.
Every connected tool is now part of your trust boundary
The moment you attach a tool to an agent through MCP, that tool's permissions, its data access, and its own supply chain become yours to defend. A model reading a support ticket, a shared document, or a web page is now processing untrusted input that can carry instructions. The classic web assumption that data and commands are separate does not hold here, because to a language model, text is text. That is the root cause behind most of the failure modes below.
The failure modes we see most often
Prompt injection, direct and indirect
Direct prompt injection is a user typing something that overrides the system's intent. The harder problem is indirect injection, where the malicious instruction is buried in content the agent fetches on its own. The Supabase MCP incident in mid-2025 is the clean example: attackers planted SQL instructions inside support tickets, and when an agent processed those tickets through its database tool, it executed them and exfiltrated integration tokens. Nobody typed a malicious prompt. The payload arrived through normal business data. HackerOne reported a 540% surge in prompt-injection vulnerability reports through October 2025, which tracks with what we see in testing.
Tool poisoning and preference manipulation
An agent chooses tools based on their metadata and descriptions. Tool poisoning abuses that: an attacker crafts a tool description that quietly instructs the model to hand over data or call a second, malicious tool. A related technique, MCP preference manipulation, nudges the agent's ranking so it reaches for the compromised tool first. Chain a few of these together and you get a parasitic toolchain that escalates on its own while every individual step looks routine. Because the manipulation lives in metadata the model reads but humans rarely inspect, it survives casual review.
Over-permissioned agents and leaked credentials
The most common enterprise failure we find is dull and preventable: agents running with far more access than their job requires. Shared API keys, inherited user sessions, over-scoped service accounts. OWASP calls this identity and privilege abuse, and the data backs it up. Roughly half of organizations in recent surveys reported agents that exceeded their intended permissions. Credential hygiene is worse than most teams assume. GitGuardian found 24,008 secrets sitting in MCP configuration files on public GitHub in 2026, with 2,117 of them still valid at the time of the scan.
Supply chain and the registry problem
Public MCP registries are filling up the way early package repositories did, and with the same problem: not everything in them is safe to run. Endor Labs found 82% of 2,614 MCP implementations vulnerable to path traversal; Equixly measured 43% vulnerable to command injection; Enkrypt AI found 33% of 1,000 scanned servers carried critical vulnerabilities. CVE-2025-6514, disclosed by JFrog in July 2025, touched more than 437,000 downloaded environments through a single vulnerable component. More than 30 MCP-related CVEs were filed in one 60-day window in early 2026. Pulling a server off a registry and pointing your agent at it is a supply-chain decision, whether or not anyone treated it as one.
Mapping the risk: OWASP Top 10 for Agentic Applications
OWASP published its Top 10 for Agentic Applications in late 2025, refined for 2026, built with input from more than 100 practitioners. It is the most useful shared vocabulary we have for these systems. The table below maps each category to what it tends to look like inside an MCP deployment and the control we reach for first.
OWASP categoryWhat it looks like in an MCP deploymentPrimary control
ASI01 Agent Goal Hijack
Instructions hidden in a fetched document or ticket redirect the agent's task
Treat all retrieved content as untrusted; isolate and filter tool inputs
ASI02 Tool Misuse and Exploitation
Legitimate tools chained or fed unsafe parameters to produce destructive output
Parameter validation against strict schemas; constrain tool combinations
ASI03 Identity and Privilege Abuse
Shared keys and over-scoped service accounts let the agent act beyond its role
Per-agent identity, RBAC, least privilege, short-lived credentials
ASI04 Agentic Supply Chain
A poisoned tool or dependency pulled from a public registry
Tool vetting, signed registries, dependency inventory, code audit
ASI05 Unexpected Code Execution
Shell or interpreter access manipulated into running arbitrary commands
OS-level sandboxing (seccomp, AppArmor, SELinux); no raw shell by default
ASI06 Memory and Context Poisoning
False data planted in persistent memory and recalled sessions later
Validate what enters memory; scope and expire stored context
ASI07 Insecure Inter-Agent Communication
One compromised agent passes malicious instructions to others unverified
Signed, authenticated messages between agents; replay protection
ASI08 Cascading Failures
A single compromise propagates across connected tools and agents
Segmentation, circuit breakers, blast-radius limits per agent
ASI09 Human-Agent Trust Exploitation
The agent's fluent output convinces a human to approve a harmful action
Human-in-the-loop for high-impact actions; show the action, not the summary
ASI10 Rogue Agents
An agent pursues goals outside its approved scope
Hard-coded action allowlists; kill switches; continuous behavior monitoring
A control baseline that holds up
In June 2026 the NSA published a cybersecurity information sheet on MCP security design. Its framing matches our own experience: MCP is promising but still maturing, and security "remains uneven and highly dependent on implementation discipline rather than protocol guarantees." In plain terms, the protocol will not save you. Your architecture has to. The diagram below shows the trust boundary we put around an agent and where each control sits.
Identity and least privilege first
Give every agent its own identity, not a shared key and not a human's session. The NSA sheet notes that MCP does not yet exchange RBAC permissions at instantiation, so you have to enforce role-based access outside the protocol, at the gateway and in the tools themselves. Scope each tool to the minimum data it needs, issue short-lived credentials, and separate tools by data sensitivity: public tools for public data, tightly restricted tools for regulated data like cardholder or health records. Only 23% of organizations had a formal AI-agent identity strategy as of early 2026, per CSA and Strata. That gap is where most incidents start.
Contain what the agent can do
Run agent and tool processes under OS-level sandboxing (seccomp, AppArmor, SELinux, or AppContainers on Windows). Validate every tool parameter against a defined schema and expected range, not just for type but for context. Treat every tool output as untrusted input that gets scanned before it feeds the next step. For high-impact actions, keep a human in the loop and show them the actual action being taken, not the agent's polished description of it, because ASI09 exists precisely because those two things can differ.
Log everything an agent and its tools do
Instrument every model and tool invocation with the parameters used, the identity that called it, and a hash of the output, then feed that into your SIEM. This is where a SOC earns its keep with agentic systems: the signal that an agent has been hijacked usually shows up as an unusual sequence of tool calls, not a single alert. Sign MCP messages cryptographically and include expiration and replay-protection metadata so a captured message cannot be replayed later. Gravitee's 2026 data has 88% of organizations reporting confirmed or suspected AI-agent incidents in the prior year, and you cannot investigate what you did not record.
Find the MCP servers you didn't know you had
Because 86% of MCP servers run locally on developer machines, shadow deployments are the norm, not the exception. Scan your network regularly for unauthorized or unauthenticated MCP instances using tools built for it, keep a versioned inventory of every deployed server, and track MCP-specific CVEs the same way you track any other vendor advisory. Put a filtering proxy or DLP control on outbound traffic from agent hosts so a compromised tool cannot quietly ship data to an external endpoint.
Where this meets ISO 27001, PCI-DSS and NIST CSF
None of this sits outside the frameworks you already answer to. Agent identities and least-privilege tool access are access control under ISO 27001 Annex A and requirement 7 of PCI-DSS. Sandboxing and parameter validation are secure configuration, which maps cleanly to CIS Benchmarks. SIEM logging of tool calls is the Detect function of the NIST Cybersecurity Framework, and the human-in-the-loop and kill-switch controls are Respond. The practical work is extending your existing control set to cover a new class of actor: a non-human identity that reasons, calls tools, and holds credentials. Only about a quarter of enterprises have a dedicated AI security governance team, so for most organizations this is a matter of stretching current governance rather than inventing a parallel one.
A pre-production checklist for MCP and agent deployments
This is the gate we run before an agent touches production data or systems. If an item cannot be answered, the deployment is not ready.
- Every agent has a unique identity with least-privilege, scoped tool access and short-lived credentials.
- Every MCP server and tool has been vetted, version-pinned, and added to an inventory with an owner.
- Tool parameters are validated against strict schemas, and no tool has raw shell access by default.
- Agent and tool processes run inside OS-level sandboxes with defined resource limits.
- All retrieved content and tool output is treated as untrusted and filtered before reuse.
- High-impact actions require human approval that shows the real action, not a summary.
- Every model and tool call is logged with identity, parameters, and output hash, and shipped to the SIEM.
- MCP messages are signed with replay protection; inter-agent messages are authenticated.
- Outbound traffic from agent hosts passes through a filtering proxy or DLP control.
- A kill switch exists, has been tested, and someone knows who is authorized to pull it.
How Aydahwa Enterprise Can Help
We build and secure the infrastructure that AI agents run on, for organizations in banking, telecom, and critical national infrastructure where a wrong action is not an option. Our work spans threat modelling an agent deployment before it ships, designing the identity and least-privilege model, standing up the sandboxing and egress controls, and wiring tool telemetry into a SOC so the behavior is actually watched. We align each engagement to the standards you report against, including ISO 27001, PCI-DSS, NIST CSF, and CIS Benchmarks.
If you are moving agents toward production, a good first step is our cyber security self-assessment and the cybersecurity readiness checklist, which surface the gaps this article describes. From there, our cybersecurity services cover the design and hardening work, our cloud services team handles secure deployment and migration, and IT support keeps it running. To talk through a specific deployment, get in touch and we will start with what your agents can currently reach.
