MCP Security: How to Protect Model Context Protocol Connections at Runtime

TL;DR

• <li>MCP security protects Model Context Protocol connections where AI agents call tools at runtime; the protocol itself mandates no auth, authorization, or transport.</li>
• <li>The root cause of most MCP threats is that tool descriptions enter the model as trusted instructions, enabling tool poisoning, confused deputy, and rug pulls.</li>
• <li>Install-time scans prove a server was safe once, not that it stays safe; rug pulls like the Postmark incident mutate after approval, so runtime verification is essential.</li>
• <li>Guardrails and better models are probabilistic; deterministic enforcement outside the model, at the runtime and kernel layer, is the only reliable control.</li>
• <li>Prioritize patching by exploitability using EPSS and CISA KEV, not CVSS alone, since roughly 88% of CVEs have exploitation probability below 10%.</li>
• <li>A 30-day plan (inventory and hash-diff, token exchange and default-deny egress, behavioral monitoring, then EPSS/KEV triage) makes MCP production-safe on one agent.</li>

Q1: What is MCP security, and why does it break the rules of normal API security? [toc=1. What Is MCP Security]

I keep meeting SecOps leads who treat their first Model Context Protocol (MCP) server like just another API. Same firewall, same token, same mental model. Then an agent reads a tool it was never meant to trust, and the old model quietly falls apart.

MCP security is the set of controls that protect MCP deployments, where AI agents discover and call external tools at runtime. Unlike a normal API, MCP mandates no authentication, no authorization, and no transport security of its own. Each host, client, and server enforces those separately. Tool descriptions enter the model's context as trusted instructions, so every connected server becomes a new attack surface.

🔌 The four-part flow you are actually securing

MCP works as an integration layer between an AI model and your systems. It moves through a short chain. Learn the chain and the risk points become obvious.

• Host: the app in charge, like an IDE or agent platform, that orchestrates connections.
• Client: the piece that calls a server's tools/list endpoint and injects tool descriptions into the model's context.
• Server: the component that exposes tools and sensitive data, then executes calls.
• Tools: the functions the agent can actually run against your data.

The client step is where poisoning enters, because the model reads descriptions as trusted instructions. This is exactly why our AI and LLM security approach starts at the point of tool invocation.

🕳️ Why the protocol leaves the door open

Here is the part that surprises people. MCP does not enforce security at the protocol level. The spec standardizes how models discover and call tools, and leaves authentication, authorization, and transport to whoever builds each host, client, and server.

So an MCP server is only as secure as the team that shipped it. That is not a theoretical worry. Research on 500 plus scanned servers found 38% had no authentication at all. Wiz Research also found MCP servers in at least 80% of observed cloud environments in early 2026, with 5% running an internet-facing server.

🧠 The semantic gap that a normal API never had

A normal API separates code from input. Your app decides what runs. With MCP, the tool description itself is instructions the model obeys.

AI models process everything as text. They cannot cleanly tell trusted instructions from developers apart from untrusted input from users. That single gap is the root of nearly every MCP threat class. The OWASP MCP Security Cheat Sheet treats tool metadata as an untrusted boundary for exactly this reason.

I could be wrong on the timeline, but where my head is right now is this: distributed AI computing forces distributed security. You cannot bolt a 2015 API gateway onto an agent that picks its own tools at runtime.

At EdgeLabs, we treat every MCP server as an untrusted runtime boundary and watch it where the workload actually executes, not where it was registered. In our work running detection across workloads and applications, that distinction is what catches a server acting differently from how it was reviewed.

Q2: What are the biggest MCP security risks, and how do they map to MITRE ATLAS? [toc=2. MCP Risk Taxonomy]

Most MCP risk lists read like a wall of scary words. I want you to leave this section able to name each risk, spot it in your stack, and tie it to a formal technique ID your detection team can actually use.

The biggest MCP risks are tool poisoning (malicious instructions hidden in tool descriptions), the confused deputy (an over-privileged server abused as a proxy), token passthrough (forwarding credentials past their intended audience), SSRF via tool connectors, rogue server registration, and rug pulls (a trusted tool that mutates after approval). All share one root cause. Tool metadata is read by the model as trusted instructions.

🎯 One root cause, six ways it shows up

Prompt injection is the common thread across the OWASP MCP Top 10, published in 2025. Most vectors work by feeding malicious instructions into the model's context, through a poisoned description, a manipulated output, or untrusted data the model reads at runtime.

Wiz frames this as one leg of the "lethal trifecta" for AI agents. Untrusted input, access to sensitive data, and the ability to act. When all three line up, a simple text input becomes a breach. Our network protection layer is designed to break that third leg at runtime.

🧬 Why these are runtime problems, not config problems

You can patch a bug and be nearly certain it is fixed. You cannot patch a brain the same way. A model that followed a poisoned instruction once will follow it again, so the fix has to live at execution time.

MITRE ATLAS documents this as case study AML.CS0054, data exfiltration via a remote poisoned MCP tool, chaining prompt crafting, a published poisoned tool, and exfiltration through tool parameters. Some of these text-only attacks carry success rates as high as 88% in published testing, and they are not expensive or sophisticated.

Name the vector, tie it to an ATLAS ID, and your detection engineers can write a rule instead of a worry. That mapping is the piece most MCP write-ups skip, and it is the honest way to work in a category this young. It is also why we build runtime detection around observed behavior, not stated intent.

Q3: How do tool poisoning and indirect prompt injection turn a helper agent into a data thief? [toc=3. How the Attacks Work]

A security lead once asked me, mid-PoC, whether an agent would really act on text it was only supposed to read. Two real incidents settled that question for good. Neither needed a malicious click.

Tool poisoning hides instructions in a tool's description or schema. Indirect prompt injection hides them in content the agent only means to read, like a support ticket. Both are invisible to the user but read by the model as trusted context, so the agent acts on them, dumping a database or exfiltrating SSH keys. Just loading a poisoned tool can be enough.

🔑 Situation one: the innocent "add" tool that stole keys

Invariant Labs disclosed this in 2025. They built a harmless-looking add tool whose description carried hidden instructions inside an IMPORTANT tag.

The instructions told the model to first read the local configuration file and SSH private key, then pass the contents through a sidenote parameter, while distracting the user with math explanations. The user saw a simple addition. The agent read SSH private keys and shipped them to a malicious server. That configuration file often holds credentials for other servers, so one poisoned tool can unlock several.

📧 Situation two: the email tool that BCC'd an attacker

The second case is a rug pull, where an approved tool mutates later. The Postmark MCP incident in September 2026 showed it in production.

A widely installed email MCP package pushed an update that silently BCC'd every agent-sent email to an attacker-controlled domain. It passed install-time review because it behaved legitimately until a later version changed. No user did anything wrong. Invariant showed a related shadowing trick, where a poisoned tool rewrites the behavior of a trusted send_email tool so all mail routes to the attacker.

🧱 Complication: why "just tell the model no" fails

The obvious fix is to instruct the model to ignore bad instructions. It does not hold. The model cannot tell a developer's rule from an attacker's text, because both arrive as the same trusted context.

That is the semantic gap again. Prompt-based defenses are among the weakest defenses in practice, precisely because the attack lives in the same channel as the instruction. I have watched teams burn weeks tuning system prompts that a single poisoned description walked right past.

👁️ Payoff: watch behavior, not intentions

So detection has to move to the moment of action. Not the tool's stated purpose, but what it actually does when invoked, reading a key file, opening an odd egress path, calling a server it never called before.

This is where EdgeLabs' Parallax engine sits. Our LLM proxy inspects tool inputs and outputs and flags injection at invocation, and because it works at runtime, a "better model" is not the dependency. When behavior drifts from what the workload should do, we treat that as the signal, not the tool's promise. You can see how this fits the broader platform in our use-case solutions.

Q4: How do you actually secure MCP connections at runtime? [toc=4. Runtime Hardening Checklist]

Enough theory. Here is the checklist I would hand a busy DevSecOps lead who has to make MCP production-safe this week, with each control tied to the specific vector it kills.

To secure MCP at runtime: enforce least privilege with scoped per-server tokens; use OAuth 2.1 with PKCE; exchange tokens per RFC 8693 instead of passthrough; require mTLS; sandbox each server with default-deny egress; pin and verify tool-description hashes on every tools/list; sign each message and reject stale nonces; gate destructive actions behind a human; and log every invocation to your SIEM.

✅ The nine controls, in order

1. Scope every token to one server and tool. Use deny-by-default, per-tool scopes so a server with broad authority cannot act outside a single call. This closes the confused deputy.
2. Use OAuth 2.1 with PKCE for user-facing flows, since auth gaps feed both confused deputy and passthrough.
3. Exchange tokens per RFC 8693, never pass them through. Token exchange issues a fresh credential scoped to the target, so a token for one server cannot be reused against another.
4. Require mutual TLS (mTLS) for service-to-service calls, and validate audience and scope so the server confirms it is the intended recipient.
5. Sandbox each server with a default-deny egress allowlist. Only expected outbound destinations are permitted, which removes the precondition that makes SSRF viable.
6. Validate URL schemes to block tool-supplied file paths or cloud metadata endpoints the agent should never reach.
7. Hash tool descriptions at deployment and verify on every tools/list. A description that changed since review is unreviewed code running with model trust, which is exactly the Postmark and rug-pull gap.
8. Sign each message and reject stale nonces. The OWASP cheat sheet recommends signing JSON-RPC messages and refusing anything outside a short replay window.
9. Gate destructive actions behind a human and log every invocation to your SIEM for behavioral detection.

⚠️ Be honest about what a checklist cannot do

I want to name a limit, because pretending otherwise loses a skeptical reader. An egress allowlist helps, but it will not stop a poisoned tool that is already inside your approved scope.

One more tactic worth stealing. When your system blocks a malicious call, return the security result as the tool output, so the model reads "prompt injection detected" and stops retrying the same call in a loop. And treat the 2-of-3 rule as design law. An agent that can read files, reach the internet, and write code should only ever hold two of those three. For containerized agents, our Kubernetes protection enforces these boundaries at the node level.

💰 The two rules that matter most

If you only do two things, do these. Exchange tokens instead of forwarding them, and verify tool-description hashes at runtime. Those two close the widest paths, credential reuse and silent mutation.

This is where EdgeLabs consolidates the runtime half of the list into one agent. Default-deny egress, host-local in-line prevention, invocation logging, and behavioral detection run together, and they keep working self-hosted, on-prem, or air-gapped with no cloud backend in the loop. If consolidation is your goal, our platform capabilities and pricing show how one agent replaces several point tools.

Q5: What isn't scanning your MCP servers at install time enough? [toc=5. Runtime vs. Posture]

I hear the same reassurance on almost every call. "We scanned the server, it came back clean, we're good." I understand the comfort. It is also the exact gap attackers now build for.

Scanning at install proves a server was safe once, not that it stays safe. A rug pull is a tool that passes review, then silently changes behavior in a later version. Posture and build-time scans never see the mutation, because it happens at runtime, during a live session. Only continuous verification of tool definitions and behavior catches it in the act.

🧪 The claim, stated plainly

Here is my governing belief, and it drives how we build. You cannot secure what you only scanned. Protection has to run where the workload executes.

A posture scan is a photograph. It tells you the server looked fine at one moment. An MCP tool, though, can change its description or its behavior after you approved it, and the model keeps trusting it. This is the core reason we anchor our platform in runtime detection and response.

📸 The proof: Postmark passed review, then turned

The Postmark MCP incident in September 2026 is the cleanest example I have seen. A widely used email MCP package shipped fine, then pushed an update that silently BCC'd every agent-sent email to an attacker-controlled domain.

It passed install-time review because it behaved legitimately at first. The malicious behavior arrived later, in a version bump nobody re-scanned. This is why OWASP recommends pinning and verifying tool-description hashes on every tools/list call, not just once.

The lesson holds beyond MCP. You can patch a bug and be nearly sure it is fixed. You cannot patch trust that keeps re-reading a mutable file. Our workloads and application security is built for exactly this class of post-approval drift.

👁️ What continuous verification actually watches

So what should run at runtime? Three things, in my experience. Drift in tools/list responses against a reviewed baseline, behavioral anomalies during a live session, and ambient authority being abused across multi-hop trust chains.

This is where EdgeLabs sits by design. Our eBPF (a Linux kernel technology for watching system calls safely) monitoring continuously verifies tool responses and flags behavioral drift the moment a trusted server starts acting untrusted. We watch where the workload runs, not where it was registered. You can see this pattern in our Kubernetes protection case study.

Q6: Is MCP safe for production, and when should you turn it on? [toc=6. Production Readiness]

The honest question under "is MCP safe" is usually quieter. It is a lead deciding whether to enable one more server before an audit, with a business asking for agents yesterday. That pressure is real, so let me give you a straight answer and a gate.

MCP can be production-safe, but not by default. The protocol standardizes tool discovery while deferring authentication, authorization, and transport to each implementation. Safety depends on runtime controls: token exchange, sandboxing, default-deny egress, and continuous tool-definition verification. Turn MCP on server by server, only after each passes an auth, egress, and behavioral-monitoring gate.

⚠️ The problem, and why waiting is not free

Naked MCP is not safe. A server with no authentication, broad scopes, and open egress is a data-exfiltration path waiting for a poisoned tool.

But refusing MCP outright is its own risk. Agents are moving into production fast, and a blanket "no" pushes teams to shadow deployments you cannot see. The safer move is a per-server decision, not a company-wide verdict. Our solutions by stage map this to where each team actually is.

✅ The go/no-go gate for each server

Run this short gate before you enable any MCP server. If a server fails one line, it does not go live until it passes. These four map directly to the questions a careful CISO now asks before enabling MCP.

• Auth: Does it use scoped, per-server authentication rather than a shared or absent credential?
• Egress: Is outbound traffic default-deny, with an explicit allowlist?
• Monitoring: Are all tool invocations logged and watched for behavioral drift?
• Human gate: Are destructive or irreversible actions held for human approval?

My one piece of judgment here. Do not mistake a quiet dashboard for a safe one, and do not mistake a noisy one for a breach. Quiet often means you are not watching the right layer. Our network protection is designed to surface the egress signals that a quiet dashboard hides.

At EdgeLabs, this gate is not a manual promise on a wiki. Our agent enforces the egress, logging, and behavioral-monitoring lines automatically at runtime, so "monitored before enabled" is a control the platform holds, not a box someone remembered to tick. See it in action on our AI and LLM security page.

Q7: Why do AI guardrails and "just use a better model" keep failing? [toc=7. Why Guardrails Fail]

Most teams reach for two fixes when an agent misbehaves. Add a guardrail, or wait for a smarter model. I used to half-believe both. The standard read gets this backwards.

Guardrails and prompt-based defenses are probabilistic. They lower the odds of an attack, they do not close the door. Because a language model cannot be patched like deterministic code, you can never be sure the flaw is gone, and new models get broken by simple text inputs within an hour. Deterministic enforcement outside the model is the only reliable control.

🎲 Why the popular playbook is probabilistic, not secure

A guardrail is a filter that tries to catch bad inputs and outputs. It helps, but it works on probability, not certainty. When a vendor says it catches everything, that claim does not survive contact with a determined attacker.

Prompt-based defenses are weaker still. Telling a model "ignore malicious instructions" just hands the attacker your rulebook, since the instruction and the attack ride the same trusted channel.

🧠 You can patch a bug, not a brain

Here is the structural problem. Patch a bug in deterministic code and you can be nearly certain it is gone. Do the same in a weight-based model, and you can be nearly certain the problem is still there.

That is why "just use a better model" disappoints. Newer models raise the bar, then get broken by cheap text inputs, sometimes within an hour. Published testing shows some plain-text attack techniques hitting success rates as high as 88%. I could be wrong on the exact half-life, but the direction has held for two years.

🔒 Put the control where it is deterministic

So move the boundary. The reliable control lives outside the probabilistic model, at the runtime and kernel layer where actions are concrete, not persuadable. Enforce architectural constraints the agent cannot talk its way past, the way a type system quietly catches a swapped argument before it ships.

This is the core of how we build EdgeLabs. Our enforcement is deterministic and host-local. It does not ask the model to behave. It blocks the system call or the egress connection regardless of what the model decides, which is the one guarantee a guardrail cannot make. Our approach to deterministic runtime enforcement explains why this matters.

Q8: Which MCP server vulnerabilities should you patch first? [toc=8. Exploit-Based Prioritization]

Ask ten teams how they prioritize patches and nine say "start with the criticals." Then they drown, because their scanner labels half the backlog critical. There is a defensible way out.

Patch by exploitability, not just severity. With 30 plus MCP-server CVEs logged in 2026, CVSS-only triage floods you with "criticals" that are never exploited. Layering EPSS exploit-probability and the CISA KEV known-exploited catalog tells you what to fix this week. Under the EU CRA and NIS2, a "no known exploitable vulnerabilities" posture is becoming an obligation, not a nicety.

📊 The pain: CVSS alone is mostly noise

CVSS (Common Vulnerability Scoring System) rates how bad a flaw could be in theory. It does not tell you whether anyone is actually exploiting it. That gap is huge. Roughly 88% of published CVEs carry an exploitation probability below 10%.

So a CVSS-ordered backlog spends most of its effort on flaws attackers ignore. For an SMB team with finite hours, that is real money burned on the wrong fixes. Our vulnerability management is built to end that waste.

🎯 The method: reorder by what gets exploited

Two free public feeds fix this. Layer them on top of CVSS.

• EPSS (Exploit Prediction Scoring System): a FIRST.org model that estimates the probability a CVE will be exploited soon.
• CISA KEV (Known Exploited Vulnerabilities): a curated catalog of CVEs confirmed exploited in the wild.
• CWE (Common Weakness Enumeration): the flaw type, which adds the "why" for explainability.

The rule I use. If it is on CISA KEV, patch it now, because active exploitation supersedes any prediction. Then work down by EPSS score. Success leaves clues, and exploited-vuln data is the clearest clue you have.

💰 The payoff: this is now a documented duty

This is no longer just good hygiene. The EU Cyber Resilience Act (Regulation (EU) 2024/2847) requires products to ship without known exploitable vulnerabilities and to handle vulnerabilities across their life, per Annex I, with reporting obligations from September 2026. NIS2 (Directive (EU) 2022/2555) adds staged incident reporting under Article 23. Our practical CRA roadmap walks through what this means for security teams.

At EdgeLabs, this is what our exploited-vulnerability and explainability scoring does, combining CVSS, EPSS, CISA KEV, and CWE. Our shipping CRA and NIS2 Compliance Center maps each control to a requirement ID and runs a "No Known Exploitable Vulnerabilities" check. I will be candid about the boundary. That center covers vulnerability-handling and detection controls, not lifecycle-governance duties like backup policy or staff training.

Q9: What should you look for in an MCP / AI-runtime security tool? [toc=9. Choosing a Tool]

Buyers ask me for a shortlist. I would rather hand you a rubric, because the shortlist changes and the criteria do not. The teams that pick well decide what "good" means before they open a single demo.

Judge an MCP-security tool on four things. Does it detect AND respond at runtime, not just alert? Does it work with no cloud backend (self-hosted, on-prem, air-gapped)? Does it consolidate NDR, EDR, Kubernetes, vulnerability, and AI-agent security into one agent? And does it map findings to CRA and NIS2? Rank tools against that rubric before you shortlist.

📏 The four criteria that actually separate tools

Most feature lists blur together. These four do not, because they are where MCP threats and SMB budgets collide.

1. Detection and response at runtime. Alerting is not defending. You want in-line prevention that fires at invocation, not a report you read later.
2. No cloud dependency. If the tool needs a cloud backend to detect or respond, it goes blind in an air-gapped or disconnected environment.
3. One-agent consolidation. Five point tools mean five agents, five bills, and five blind spots between them.
4. Compliance mapping. Findings should map to CRA and NIS2 requirement IDs, or an audit becomes a manual export project.

These criteria map directly to how our runtime detection and response is built, and to the way we structure solutions by feature.

🥇 How the field ranks against that rubric

Here is my honest read, strengths first, then the trade-offs.

1.1 EdgeLabs. We are runtime-first and agent-only. Detection and response both run on the agent, so they keep working self-hosted, on-prem, and air-gapped. One eBPF agent consolidates NDR, EDR, IPS/IDS, container and Kubernetes security, vulnerability management, and AI-agent security via the Parallax engine. You can see the consolidation in our AI and LLM security and Kubernetes protection pages.

1.2 Sysdig. A strong, credible runtime and CNAPP (Cloud-Native Application Protection Platform) player with deep Falco heritage and broad cloud visibility. The honest trade-off is that it is heavier and more cloud and platform oriented than an agent-only model.

1.3 CrowdStrike, SentinelOne, Vectra. Capable, but built for a different first job. CrowdStrike and SentinelOne are endpoint-first, so runtime is an extension of an EDR engine. Vectra is network and cloud-NDR, heavier and cloud-dependent.

💬 What buyers say, in their own words

Reviews back the pattern. Sysdig users praise the visibility and flag config churn.

"Granular host, container, K8s visibility... Feature updates can often render existing configuration or content useless leading to rework."
Verified User in Financial Services Sysdig Secure G2 Verified Review

The cloud-dependency trade-off shows up clearly on the CNAPP side.

"The heavy dependency on SaaS availability creates vendor lock-in and introduces a real risk to overall availability."
Verified User in Information Technology and Services CrowdStrike Falcon Cloud Security G2 Verified Review

On our side, the runtime IPS/IDS/EDR core is what users name first.

"Good IPS/IDS/EDR software. Web portal management is good. Docker container integration is useful."
Verified User in Computer Software EdgeLabs G2 Verified Review

⚠️ When EdgeLabs is not your tool

Honesty over hype, because the category is young and under-reviewed. If your primary job is pure OT/ICS asset visibility, IoT-hardware security, or build-time-only application scanning, we are not the right fit. And I will name a rival's strength: Aqua's full build-to-runtime lifecycle coverage is broader on the CI/CD scanning side than ours. Pick the tool whose first job matches yours, and if runtime is that job, compare our pricing and use-case solutions.

Q10: What's your 30-day plan to make MCP production-safe? [toc=10. Your 30-Day Plan]

Let me turn everything above into a month you can actually run. Not a rip-and-replace, just four weeks of steady, defensible moves. Ship the first control this week instead of waiting for a perfect rollout.

Week 1: inventory every connected MCP server and hash-diff tool descriptions against a reviewed baseline. Week 2: replace token passthrough with RFC 8693 token exchange and enforce default-deny egress. Week 3: turn on runtime behavioral monitoring and message-signing. Week 4: triage CVEs by EPSS and KEV, then map controls to CRA and NIS2 requirement IDs.

🗓️ The four-week rollout

Each week has one owner and one primary-source anchor, so nobody has to guess who does what.

⚠️ What week one will and will not fix

Be clear-eyed. Week one gives you visibility, not protection. Knowing which servers you run and which descriptions drifted is the foundation, but it does not stop an attack on its own.

The protection lands in weeks two and three, when egress goes default-deny and behavioral monitoring goes live. That sequencing matters, because an AI agent can complete a destructive action in about 9 seconds, faster than you can read a Slack message. Week three has to be automated for that reason, not a human watching a dashboard. Our network protection and vulnerability management handle weeks two through four as one agent.

💰 Doing this without a big team

At EdgeLabs, we built for the SMB reality where one person owns all four rows. The whole plan runs on one agent that works self-hosted or air-gapped, so a team with no dedicated cloud-security staff can execute weeks one through four end to end. When compliance mapping matters, our CRA and NIS2 Compliance Center closes week four.

Here is the question I am sitting with, and I would genuinely like your take. Over the next two years, I think distributed AI computing forces distributed security, and securing the LLM agent at runtime stops being niche and becomes the default question every SecOps team answers. If you are enabling MCP servers right now, tell me where your plan breaks, and let us compare notes.

FAQs

What is MCP security and why is it different from normal API security?

MCP security is the set of controls that protect Model Context Protocol deployments, where AI agents discover and call external tools at runtime.

Unlike a normal API, MCP mandates no authentication, authorization, or transport security of its own. Each host, client, and server enforces those independently.

• A normal API separates code from input, so your app decides what runs.
• With MCP, the tool description itself is read by the model as trusted instructions.
• That single semantic gap is the root of nearly every MCP threat class.

This is why an MCP server is only as secure as the team that shipped it. Research on scanned servers found many ran with no authentication at all.

We treat every MCP server as an untrusted runtime boundary and monitor it where the workload executes, not where it was registered. You can see how this works in our AI and LLM security approach, which inspects tool inputs and outputs at invocation rather than trusting a clean registration.

What are the biggest MCP security risks?

The biggest MCP risks share one root cause: tool metadata is read by the model as trusted instructions. Naming them precisely lets your team write detections instead of worrying.

• Tool poisoning: malicious instructions hidden in a tool's description or schema.
• Confused deputy: an over-privileged server abused as a proxy.
• Token passthrough: forwarding credentials past their intended audience.
• SSRF via connectors: tool URLs routed to internal or metadata endpoints.
• Rogue server registration: weak session binding lets an untrusted server in.
• Rug pulls: a trusted tool that mutates after approval.

These map to the OWASP MCP Top 10 and to MITRE ATLAS technique IDs, with case study AML.CS0054 as the canonical example of data exfiltration via a poisoned MCP tool.

Because these activate at invocation, they are runtime problems, not config problems. Our runtime detection and response watches observed behavior, so a poisoned tool that acts outside its stated purpose gets flagged the moment it fires.

How do tool poisoning and prompt injection actually steal data?

Tool poisoning hides instructions in a tool's description or schema. Indirect prompt injection hides them in content the agent only means to read, like a support ticket.

Both are invisible to the user but read by the model as trusted context, so the agent acts on them.

• Invariant Labs built a harmless-looking add tool that quietly exfiltrated SSH private keys.
• The Postmark MCP incident pushed an update that BCC'd every agent-sent email to an attacker.

Telling the model to ignore bad instructions does not work, because the instruction and the attack ride the same trusted channel. Prompt-based defenses are among the weakest in practice.

So detection must move to the moment of action, not the tool's stated purpose. Our Parallax engine, part of our workloads and application security, inspects tool inputs and outputs and flags injection at invocation. Because it works at runtime, a better model is not the dependency; the enforcement is deterministic and host-local.

How do you secure MCP connections at runtime?

To secure MCP at runtime, apply an ordered checklist where each control defends a specific vector.

1. Enforce least privilege with scoped, per-server tokens.
2. Use OAuth 2.1 with PKCE for user-facing flows.
3. Exchange tokens per RFC 8693 instead of passing them through.
4. Require mutual TLS and validate audience and scope.
5. Sandbox each server with default-deny egress.
6. Pin and verify tool-description hashes on every tools/list call.
7. Sign each message and reject stale nonces.
8. Gate destructive actions behind a human and log every invocation.

If you only do two things, exchange tokens instead of forwarding them, and verify tool-description hashes at runtime. Those close the widest paths.

Be honest about limits: an egress allowlist will not stop a poisoned in-scope tool. We consolidate the runtime half of this list, including default-deny egress, in-line prevention, and behavioral detection, into one agent through our Kubernetes protection, and it works self-hosted, on-prem, and air-gapped.

Why isn't scanning MCP servers at install time enough?

Scanning at install proves a server was safe once, not that it stays safe. A posture scan is a photograph of one moment.

A rug pull is a tool that passes review, then silently changes behavior in a later version.

• The Postmark MCP package passed install-time review, then a version bump BCC'd every email to an attacker.
• Posture and build-time scans never see the mutation, because it happens at runtime during a live session.

Continuous runtime verification checks three things: drift in tools/list responses against a reviewed baseline, behavioral anomalies during a session, and ambient authority abused across multi-hop trust chains.

This is our governing belief: you cannot secure what you only scanned, so protection has to run where the workload executes. Our network protection uses kernel-level monitoring to verify tool responses continuously and flag drift the moment a trusted server starts acting untrusted.

Is MCP safe for production, and when should you enable it?

MCP can be production-safe, but not by default. The protocol standardizes tool discovery while deferring authentication, authorization, and transport to each implementation.

Safety depends on runtime controls, so turn MCP on server by server, only after each passes a short gate.

• Auth: scoped, per-server authentication rather than a shared or absent credential.
• Egress: default-deny outbound traffic with an explicit allowlist.
• Monitoring: all tool invocations logged and watched for behavioral drift.
• Human gate: destructive or irreversible actions held for approval.

Refusing MCP outright is its own risk, because a blanket no pushes teams to shadow deployments you cannot see. A per-server decision is safer than a company-wide verdict.

With us, this gate is not a manual promise on a wiki. Our agent enforces the egress, logging, and behavioral-monitoring lines automatically, and you can match it to where each team is on our solutions by stage page.

Which MCP server vulnerabilities should you patch first?

Patch by exploitability, not just severity. With more than 30 MCP-server CVEs logged in 2026, CVSS-only triage floods you with criticals that are never exploited.

Roughly 88% of published CVEs carry an exploitation probability below 10%, so a CVSS-ordered backlog wastes effort on flaws attackers ignore.

• EPSS: a FIRST.org model estimating the probability a CVE will be exploited soon.
• CISA KEV: a catalog of CVEs confirmed exploited in the wild.
• CWE: the flaw type, which adds the why for explainability.

The rule: if it is on CISA KEV, patch now; then work down by EPSS score. Under the EU CRA and NIS2, a no-known-exploitable-vulnerabilities posture is becoming a documented duty.

Our exploited-vulnerability scoring combines CVSS, EPSS, KEV, and CWE, and our vulnerability management ties each finding to a requirement ID for audit-readiness.

What tool should you choose to secure MCP and AI agents at runtime?

Judge an MCP-security tool on four criteria before you shortlist.

• Does it detect and respond at runtime, not just alert?
• Does it work with no cloud backend, so it runs self-hosted, on-prem, or air-gapped?
• Does it consolidate NDR, EDR, Kubernetes, vulnerability, and AI-agent security into one agent?
• Does it map findings to CRA and NIS2 requirement IDs?

Sysdig is a strong, cloud-oriented runtime and CNAPP player. CrowdStrike and SentinelOne are endpoint-first, so runtime is an extension of an EDR engine. Vectra is network and cloud-NDR, heavier and cloud-dependent.

We are honest about fit: if your primary job is pure OT asset visibility or build-time-only scanning, we are not the right tool.

Where runtime is the job, we are runtime-first and agent-only, consolidating detection and response into one eBPF agent. Compare our approach and pricing against that four-part rubric.