The MCP Vulnerability That Put 200,000 Enterprise AI Instances at Risk — Why Every Enterprise Needs an Agentic Supply Chain Security Platform
Written by
AI agents no longer just answer questions. They call tools, read and write to enterprise systems, chain actions together, and increasingly operate with minimal human oversight. The Model Context Protocol (MCP) has become the connective tissue behind this shift — the standard that lets AI copilots, coding agents, and autonomous workflows reach into databases, SaaS platforms, and internal APIs on command.
That growth has outpaced the security review it deserved. On April 15, 2026, OX Security disclosed a systemic, architectural vulnerability in Anthropic's official MCP SDKs across Python, TypeScript, Java, and Rust — a flaw in how the STDIO transport handles server configuration that allows arbitrary command execution on any host an attacker can influence. The exposure is enormous: more than 150 million cumulative package downloads, roughly 7,000 publicly reachable MCP servers, and an estimated 200,000 vulnerable deployments across the ecosystem, with 14 or more CVEs assigned as investigations continue.
The disclosure is not really a story about one flawed SDK. It is a preview of what happens when enterprises adopt a new class of software — autonomous AI agents with tool access — faster than they build the controls to govern it. That is why the conversation among CISOs, Chief AI Officers, and platform engineering leaders has shifted from "which MCP servers do we run" to a bigger question: does our organization have an Agentic Supply Chain Security Platform and an MCP Security Platform at all, or are we relying on tools that were never built to see this layer of risk?
Understanding Model Context Protocol (MCP)
MCP is an open protocol, introduced by Anthropic in late 2024, that standardizes how AI models connect to external tools, data sources, and services. Before MCP, every integration between an LLM and an enterprise system — a CRM, a ticketing system, a code repository — required custom, one-off plumbing. MCP gives that connection a common shape.
The architecture is a client-server model. An MCP client (an IDE, an AI copilot, an agent framework) connects to one or more MCP servers, each of which exposes a defined set of tools, resources, or prompts the model can call. A server might wrap a database, a filesystem, a SaaS API, or an internal microservice. The client requests a tool call; the server executes it and returns a result the model can reason over.
That simplicity is exactly why adoption exploded. Within roughly eighteen months, the ecosystem grew to thousands of community-built server packages published across npm, PyPI, and language-specific registries, embedded in coding assistants, IDEs, and agent frameworks used across the enterprise. Growth this fast, across this many independently maintained packages, is precisely the pattern that has preceded every major software supply chain incident of the last decade.
What Happened: Breaking Down the OX Security MCP Vulnerability
OX Security's research, published under the title "The Mother of All AI Supply Chains," traced a single root-cause design decision through Anthropic's four official MCP SDKs. When an MCP client launches a local server over the STDIO transport, the SDK passes user- or config-supplied command and argument values directly to shell execution without sanitization — and the command can execute even when the target process fails to start.
It is important to separate three distinct layers here, since enterprise security teams often conflate them:
- The MCP protocol itself: defines STDIO as one of several transports, intended for local development and desktop tooling. The specification does not mandate how implementers handle trust boundaries between client and server.
- The SDK implementations: Anthropic's reference SDKs in Python, TypeScript, Java, and Rust are where the unsanitized command execution actually lives. This is the layer OX Security's disclosure targets directly.
- Downstream software: Products built on those SDKs — including LangFlow, LiteLLM, LangChain-based tools, Windsurf, and others — inherited the flaw without writing a single vulnerable line of their own code.
OX Security reported confirming arbitrary command execution on six live, production-grade platforms during coordinated disclosure, and issued more than 30 responsible disclosures resulting in at least 14 assigned CVEs to date. Anthropic, for its part, has characterized the STDIO execution behavior as expected by design and placed responsibility for input sanitization on downstream developers — a position that has become the center of ongoing industry debate about where protocol-level responsibility should sit.
What is verified: the SDK-level design flaw, the affected languages, the CVE count, and the six confirmed production exploits. What is analysis, not fact: the precise number of organizations currently exploitable in production, since the 200,000 figure is OX Security's estimate of vulnerable instances across the installed base, distinct from the roughly 7,000 servers it could directly scan and confirm as publicly reachable.
Why This Is Bigger Than One Vulnerability
AI ecosystems now behave like software supply chains, because that is what they are. A single agent framework depends on MCP SDKs, which depend on open-source packages, which depend on transitive dependencies several layers removed from anyone's direct review. Add third-party MCP servers, plugins, orchestration layers, memory systems, and vector databases, and the dependency graph looks less like a traditional application and more like the npm ecosystem circa 2021 — except every node in that graph now has the ability to take autonomous action.
The comparison to prior supply chain incidents is instructive, not alarmist. Log4Shell showed how a single ubiquitous, low-level library could compromise an enormous share of enterprise Java applications overnight. SolarWinds showed how trust in a vendor's build pipeline could be weaponized against thousands of downstream customers. Recurring npm and PyPI package-poisoning campaigns show how quickly a compromised dependency propagates once it is pulled into thousands of projects automatically.
The MCP disclosure combines elements of all three: a low-level, widely inherited design flaw (Log4Shell), propagation through trusted reference implementations (SolarWinds), and a package ecosystem where anyone can publish a server with minimal review (npm). What makes AI agents different — and more urgent — is that the compromised component is not passive code sitting in a library. It is a tool an autonomous agent is actively invoking, often with elevated permissions and no human reviewing each call.
The Rise of the Agentic AI Supply ChainA modern enterprise AI deployment is rarely a single model behind an API. It is a stack: MCP servers exposing tools, an orchestration or agent framework coordinating calls, memory stores and RAG pipelines feeding context, connections to external APIs and SaaS platforms, and one or more underlying model providers. A compromise anywhere in that stack can cascade through every layer above it, because each layer trusts the output of the one below it by default.
Trust boundary
Primary artifact
Update mechanism
Attack surface growth
Detection method
§54(2)
§54(3)
§55
§56
§58–59
§60
Ch. V.A
Traditional Software Supply Chain
Compiled code, packages, containers
Version-pinned dependency updates
New packages, new CVEs
SCA, SAST, dependency scanning
Human-in-command: override, suspension and kill-switch
Independent validation of third-party models regardless of vendor assurance
Agentic AI Supply Chain
Models, prompts, agent tools, memory
Live prompts, tool descriptions, MCP servers
New MCP servers, plugins, agent permissions
Runtime behavior and tool-call monitoring
Why Existing Security Tools Cannot Fully Protect AI Agents
Most enterprise security stacks were architected before agentic AI existed, and it shows. SAST and DAST scan code for known vulnerability patterns, not for a model's runtime decision to call an unexpected tool. CSPM secures cloud configuration, not the permissions an agent has been granted inside that cloud environment. API gateways enforce schema and rate limits, not whether a tool response has quietly altered an agent's next action. Endpoint security and traditional vulnerability scanners look for malware signatures and unpatched software, not a poisoned memory store or a manipulated tool description. SIEM platforms can ingest agent logs, but only if something upstream is generating structured, security-relevant signal from agent behavior in the first place — most agent stacks today are not instrumented to produce it.
Agentic AI introduces risk categories none of these tools were built to see: unauthorized tool calls, direct and indirect prompt injection, hallucinated actions taken as if they were real, excessive standing permissions, memory and RAG poisoning, context manipulation across multi-turn sessions, rogue or drifting autonomous behavior, and trust placed in third-party MCP servers with no formal vetting process. Closing that gap requires runtime-native tooling, not another layer of static scanning.
Runtime Risks Every Enterprise Must Monitor
• Unauthorized MCP connections: an agent or developer adds an unapproved MCP server to a workflow, and it silently gains the same tool access as vetted ones.
• Tool misuse: a legitimate tool is called with parameters or in a sequence outside its intended use, exfiltrating data through an approved channel.
• Sensitive data leakage: an agent passes regulated or confidential data into a tool call, a prompt, or a third-party API without policy enforcement in the loop.
• Prompt injection through connected tools: a tool's response — a webpage, a document, an email — contains hidden instructions the agent treats as legitimate user intent.
• Hallucinated actions: an agent takes a real, consequential action (a ticket, a transaction, a code change) based on a fabricated premise.
• Memory poisoning: a RAG or memory store is seeded with false content the agent later retrieves and treats as verified fact.
• Excessive agent permissions: an agent is provisioned with broader tool or data access than its actual task requires, widening blast radius.
• Rogue autonomous behavior: an agent's chained decisions drift from its intended task into actions no one explicitly authorized.
• Third-party MCP server trust: a community-published server is added without code review, security manifest, or ongoing monitoring.
• AI policy violations: an agent's behavior breaches an internal governance policy without triggering any existing control.
• Continuous runtime drift: an agent's behavior gradually diverges from its validated baseline as prompts, tools, and models change over time.
Each of these played out, in some form, across the products OX Security examined — an unauthenticated endpoint exposing an MCP configuration screen, a tool accepting unsanitized command arguments, a coding assistant executing a payload the moment a poisoned repository was opened. None of it required a user to knowingly do something unsafe.
Stop guessing.
Start measuring.
Join teams building reliable AI with TruEval. Start with a free trial, no credit card required. Get your first evaluation running in under 10 minutes.
Questions about Trusys?
Our team is here to help. Schedule a personalized demo to see how Trusys fits your specific use case.
Book a Demo
Ready to dive in?
Check out our documentation and tutorials. Get started with example datasets and evaluation templates.
Start Free Trial
Free Trial
No credit card required
10 Min
To first evaluation
24/7
Enterprise support
ASI05: Unexpected Code Execution (RCE)
What it is: Agents increasingly generate and execute code to solve problems, creating a direct path from a manipulated prompt to arbitrary command execution on the underlying system.
Real-world example: A self-repairing coding agent generates unreviewed shell commands to fix a broken build and, through manipulation or plain error, deletes production data. In a more direct attack, an adversary embeds shell syntax inside a file the agent is asked to process, and the agent executes it as if it were a legitimate part of the task.
Business impact: Data loss, service outages, and in the worst case, full compromise of the execution environment.
Detection challenges: Code-generation agents produce plausible, syntactically correct commands constantly, which makes it hard to distinguish a legitimate fix from a malicious one without execution-time review.
Recommended mitigations: Sandbox all agent-generated code execution, require human approval before any destructive or irreversible command runs, and log every generated command together with the agent's stated rationale for post-hoc review.
What Defines an Enterprise MCP Security Platform?
Enterprises evaluating vendors in this category should look past the marketing language and check for a specific, verifiable set of capabilities. Use this as an evaluation checklist.
• Discovery of MCP servers across sanctioned and shadow deployments
• Inventory of AI agents, their tool access, and their permission scope
• Continuous runtime monitoring of tool calls, not point-in-time scans
• Prompt and response inspection for injection and manipulation attempts
• Tool usage visibility mapped to the data and systems each tool touches
• Policy enforcement and permission management, applied inline
• Runtime anomaly and behavioral-drift detection
• Hallucination and unsafe-action detection before consequences land
• Third-party and community MCP server connector monitoring
• Structured AI interaction logging for forensic and audit use
• Continuous compliance evidence generation, not manual point-in-time reports
• Risk scoring and governance dashboards for security and compliance stakeholders
Why Enterprises Need an Agentic Supply Chain Security Platform
Securing agentic AI means securing every layer an agent touches: the models it calls, the agents themselves, the prompts that steer them, the memory they draw on, the orchestration logic that sequences their actions, the MCP servers and external tools they invoke, the APIs and plugins in between, and the identities and permissions attached to all of it. No single point solution covers that whole surface — which is exactly why runtime governance is emerging as a foundational security layer, sitting alongside AppSec, cloud security, and API security rather than replacing any of them.
Picture this layer as a control plane that spans the AI stack horizontally: it sits below the agent orchestration layer (observing every tool call and decision), beside the identity and access layer (enforcing permission boundaries in real time), and above the raw infrastructure (translating runtime signal into audit-ready evidence for compliance frameworks like the EU AI Act, NIST AI RMF, and ISO/IEC 42001). An Agentic Supply Chain Security Platform is the product category built to occupy that position.
Building a Secure MCP Strategy
1. Inventory every MCP server in use, including ones added informally by individual developers.
2. Continuously monitor dependencies across the MCP SDKs and packages your agents rely on.
3. Verify trusted publishers before approving a new MCP server for production use.
4. Restrict tool permissions to the minimum an agent's task actually requires.
5. Apply least privilege at the agent, tool, and data layer, not just the network layer.
6. Validate tool outputs before an agent acts on them, especially for consequential actions.
7. Monitor prompts and responses continuously for injection and manipulation.
8. Detect runtime anomalies against a validated behavioral baseline.
9. Govern AI behavior continuously, not through periodic point-in-time reviews.
10. Map identified risks to the compliance frameworks your organization is accountable to.
11. Conduct regular AI red-team exercises that simulate real attacker techniques against your live MCP deployments.
How Trusys Strengthens Enterprise MCP Security
Trusys is built as an operations layer for AI agents that spans discovery, evaluation, runtime monitoring, guardrails, and governance — orchestrated by Argus, the platform's autonomous governance engine. Rather than one module claiming to do everything, each capability maps to a distinct part of the MCP risk surface the OX Security disclosure exposed.
• Discovery and governance (Argus): automatically discovers tool inventories, memory stores, and egress paths across connected agents — including agents and MCP servers connected via API or SDK — and continuously enforces policy across every framework in use.
• Runtime observability (TruPulse): monitors production AI traces in real time, giving security teams visibility into tool calls, anomalies, and behavioral drift as they happen rather than after an incident.
• Inline enforcement (TruGuard): applies policy guardrails inline, in production, so a tool call that violates a defined boundary can be blocked rather than merely logged.
• Adversarial testing (TruScout): runs continuous red-team campaigns mapped to the OWASP Agentic AI Top 10 and MITRE ATLAS, testing agents against poisoned tools, hostile MCP responses, and prompt injection the way an actual attacker would.
• Code-level scanning (TruScan): catches insecure patterns in AI-generated and agent-adjacent code earlier in the development lifecycle.
• Compliance evidence (Argus): generates continuous, audit-ready evidence mapped to frameworks including the EU AI Act, NIST AI RMF, ISO/IEC 42001, and the OWASP Agentic AI Top 10, replacing manual point-in-time reporting.
Together, these capabilities give enterprises a way to discover what MCP servers and agents are actually running, watch how they behave in production, stop violations inline, and prove it to auditors — the combination that defines both an MCP Security Platform and an Agentic Supply Chain Security Platform in practice, not just in name.
Frequently Asked Questions
What is an Agentic Supply Chain Security Platform?
It is a security category purpose-built to protect every layer an AI agent touches — models, agents, prompts, memory, orchestration, MCP servers, tools, and APIs — with continuous discovery, runtime monitoring, and governance rather than one-time code review.
What is an MCP Security Platform?
It is a platform focused specifically on securing Model Context Protocol deployments: discovering MCP servers, monitoring tool calls, inspecting prompts and responses, and enforcing policy on agent-to-tool interactions in real time.
How does an MCP Security Platform protect AI agents?
By giving security teams continuous visibility into which MCP servers and tools an agent is calling, inspecting those interactions for injection or misuse, and enforcing permission and policy boundaries inline rather than after the fact.
What caused the recent MCP vulnerability?
OX Security identified an architectural flaw in Anthropic's official MCP SDKs across Python, TypeScript, Java, and Rust, where the STDIO transport passed unsanitized configuration values directly to shell execution, enabling remote command execution.
Why is runtime AI security important?
Because agents make dynamic, model-decided tool calls that static code scanning was never designed to evaluate — the risk lives in what an agent decides to do in production, not just in the code it was built from.
How can enterprises secure Model Context Protocol deployments?
By inventorying every MCP server in use, restricting tool permissions to least privilege, monitoring prompts and tool calls continuously, and running regular adversarial testing against live deployments.
What are the biggest risks in the AI agent supply chain?
Unauthorized MCP connections, prompt injection through connected tools, memory poisoning, excessive agent permissions, and unvetted third-party MCP servers are among the most consequential.
How does AI governance reduce MCP-related risk?
Continuous governance turns scattered runtime signals into enforceable policy and audit-ready evidence, closing the gap between a detected anomaly and an actual enforced control.
What capabilities should enterprises evaluate in an MCP Security Platform?
Discovery, inventory, continuous runtime monitoring, policy enforcement, anomaly and hallucination detection, third-party connector monitoring, structured logging, and continuous compliance evidence — see the evaluation checklist above.
How does Trusys improve AI runtime security and compliance?
Trusys combines Argus-orchestrated discovery and governance, TruPulse runtime observability, TruGuard inline enforcement, and TruScout adversarial testing into one operations layer, giving enterprises continuous visibility and audit-ready evidence across their AI agent and MCP footprint.
Benefits
Specifications
How-to
Contact Us
Learn More
The MCP Vulnerability That Put 200,000 Enterprise AI Instances at Risk — Why Every Enterprise Needs an Agentic Supply Chain Security Platform
Written by
ASI05: Unexpected Code Execution (RCE)
What it is: Agents increasingly generate and execute code to solve problems, creating a direct path from a manipulated prompt to arbitrary command execution on the underlying system.
Real-world example: A self-repairing coding agent generates unreviewed shell commands to fix a broken build and, through manipulation or plain error, deletes production data. In a more direct attack, an adversary embeds shell syntax inside a file the agent is asked to process, and the agent executes it as if it were a legitimate part of the task.
Business impact: Data loss, service outages, and in the worst case, full compromise of the execution environment.
Detection challenges: Code-generation agents produce plausible, syntactically correct commands constantly, which makes it hard to distinguish a legitimate fix from a malicious one without execution-time review.
Recommended mitigations: Sandbox all agent-generated code execution, require human approval before any destructive or irreversible command runs, and log every generated command together with the agent's stated rationale for post-hoc review.
AI agents no longer just answer questions. They call tools, read and write to enterprise systems, chain actions together, and increasingly operate with minimal human oversight. The Model Context Protocol (MCP) has become the connective tissue behind this shift — the standard that lets AI copilots, coding agents, and autonomous workflows reach into databases, SaaS platforms, and internal APIs on command.
That growth has outpaced the security review it deserved. On April 15, 2026, OX Security disclosed a systemic, architectural vulnerability in Anthropic's official MCP SDKs across Python, TypeScript, Java, and Rust — a flaw in how the STDIO transport handles server configuration that allows arbitrary command execution on any host an attacker can influence. The exposure is enormous: more than 150 million cumulative package downloads, roughly 7,000 publicly reachable MCP servers, and an estimated 200,000 vulnerable deployments across the ecosystem, with 14 or more CVEs assigned as investigations continue.
The disclosure is not really a story about one flawed SDK. It is a preview of what happens when enterprises adopt a new class of software — autonomous AI agents with tool access — faster than they build the controls to govern it. That is why the conversation among CISOs, Chief AI Officers, and platform engineering leaders has shifted from "which MCP servers do we run" to a bigger question: does our organization have an Agentic Supply Chain Security Platform and an MCP Security Platform at all, or are we relying on tools that were never built to see this layer of risk?
Understanding Model Context Protocol (MCP)
MCP is an open protocol, introduced by Anthropic in late 2024, that standardizes how AI models connect to external tools, data sources, and services. Before MCP, every integration between an LLM and an enterprise system — a CRM, a ticketing system, a code repository — required custom, one-off plumbing. MCP gives that connection a common shape.
The architecture is a client-server model. An MCP client (an IDE, an AI copilot, an agent framework) connects to one or more MCP servers, each of which exposes a defined set of tools, resources, or prompts the model can call. A server might wrap a database, a filesystem, a SaaS API, or an internal microservice. The client requests a tool call; the server executes it and returns a result the model can reason over.
That simplicity is exactly why adoption exploded. Within roughly eighteen months, the ecosystem grew to thousands of community-built server packages published across npm, PyPI, and language-specific registries, embedded in coding assistants, IDEs, and agent frameworks used across the enterprise. Growth this fast, across this many independently maintained packages, is precisely the pattern that has preceded every major software supply chain incident of the last decade.
What Happened: Breaking Down the OX Security MCP Vulnerability
OX Security's research, published under the title "The Mother of All AI Supply Chains," traced a single root-cause design decision through Anthropic's four official MCP SDKs. When an MCP client launches a local server over the STDIO transport, the SDK passes user- or config-supplied command and argument values directly to shell execution without sanitization — and the command can execute even when the target process fails to start.
It is important to separate three distinct layers here, since enterprise security teams often conflate them:
- The MCP protocol itself: defines STDIO as one of several transports, intended for local development and desktop tooling. The specification does not mandate how implementers handle trust boundaries between client and server.
- The SDK implementations: Anthropic's reference SDKs in Python, TypeScript, Java, and Rust are where the unsanitized command execution actually lives. This is the layer OX Security's disclosure targets directly.
- Downstream software: Products built on those SDKs — including LangFlow, LiteLLM, LangChain-based tools, Windsurf, and others — inherited the flaw without writing a single vulnerable line of their own code.
OX Security reported confirming arbitrary command execution on six live, production-grade platforms during coordinated disclosure, and issued more than 30 responsible disclosures resulting in at least 14 assigned CVEs to date. Anthropic, for its part, has characterized the STDIO execution behavior as expected by design and placed responsibility for input sanitization on downstream developers — a position that has become the center of ongoing industry debate about where protocol-level responsibility should sit.
What is verified: the SDK-level design flaw, the affected languages, the CVE count, and the six confirmed production exploits. What is analysis, not fact: the precise number of organizations currently exploitable in production, since the 200,000 figure is OX Security's estimate of vulnerable instances across the installed base, distinct from the roughly 7,000 servers it could directly scan and confirm as publicly reachable.
Why This Is Bigger Than One Vulnerability
AI ecosystems now behave like software supply chains, because that is what they are. A single agent framework depends on MCP SDKs, which depend on open-source packages, which depend on transitive dependencies several layers removed from anyone's direct review. Add third-party MCP servers, plugins, orchestration layers, memory systems, and vector databases, and the dependency graph looks less like a traditional application and more like the npm ecosystem circa 2021 — except every node in that graph now has the ability to take autonomous action.
The comparison to prior supply chain incidents is instructive, not alarmist. Log4Shell showed how a single ubiquitous, low-level library could compromise an enormous share of enterprise Java applications overnight. SolarWinds showed how trust in a vendor's build pipeline could be weaponized against thousands of downstream customers. Recurring npm and PyPI package-poisoning campaigns show how quickly a compromised dependency propagates once it is pulled into thousands of projects automatically.
The MCP disclosure combines elements of all three: a low-level, widely inherited design flaw (Log4Shell), propagation through trusted reference implementations (SolarWinds), and a package ecosystem where anyone can publish a server with minimal review (npm). What makes AI agents different — and more urgent — is that the compromised component is not passive code sitting in a library. It is a tool an autonomous agent is actively invoking, often with elevated permissions and no human reviewing each call.
The Rise of the Agentic AI Supply ChainA modern enterprise AI deployment is rarely a single model behind an API. It is a stack: MCP servers exposing tools, an orchestration or agent framework coordinating calls, memory stores and RAG pipelines feeding context, connections to external APIs and SaaS platforms, and one or more underlying model providers. A compromise anywhere in that stack can cascade through every layer above it, because each layer trusts the output of the one below it by default.
Trust boundary
Primary artifact
Update mechanism
Attack surface growth
Detection method
§54(2)
§54(3)
§55
§56
§58–59
§60
Ch. V.A
Traditional Software Supply Chain
Compiled code, packages, containers
Version-pinned dependency updates
New packages, new CVEs
SCA, SAST, dependency scanning
Human-in-command: override, suspension and kill-switch
Independent validation of third-party models regardless of vendor assurance
Agentic AI Supply Chain
Models, prompts, agent tools, memory
Live prompts, tool descriptions, MCP servers
New MCP servers, plugins, agent permissions
Runtime behavior and tool-call monitoring
Why Existing Security Tools Cannot Fully Protect AI Agents
Most enterprise security stacks were architected before agentic AI existed, and it shows. SAST and DAST scan code for known vulnerability patterns, not for a model's runtime decision to call an unexpected tool. CSPM secures cloud configuration, not the permissions an agent has been granted inside that cloud environment. API gateways enforce schema and rate limits, not whether a tool response has quietly altered an agent's next action. Endpoint security and traditional vulnerability scanners look for malware signatures and unpatched software, not a poisoned memory store or a manipulated tool description. SIEM platforms can ingest agent logs, but only if something upstream is generating structured, security-relevant signal from agent behavior in the first place — most agent stacks today are not instrumented to produce it.
Agentic AI introduces risk categories none of these tools were built to see: unauthorized tool calls, direct and indirect prompt injection, hallucinated actions taken as if they were real, excessive standing permissions, memory and RAG poisoning, context manipulation across multi-turn sessions, rogue or drifting autonomous behavior, and trust placed in third-party MCP servers with no formal vetting process. Closing that gap requires runtime-native tooling, not another layer of static scanning.
Runtime Risks Every Enterprise Must Monitor
• Unauthorized MCP connections: an agent or developer adds an unapproved MCP server to a workflow, and it silently gains the same tool access as vetted ones.
• Tool misuse: a legitimate tool is called with parameters or in a sequence outside its intended use, exfiltrating data through an approved channel.
• Sensitive data leakage: an agent passes regulated or confidential data into a tool call, a prompt, or a third-party API without policy enforcement in the loop.
• Prompt injection through connected tools: a tool's response — a webpage, a document, an email — contains hidden instructions the agent treats as legitimate user intent.
• Hallucinated actions: an agent takes a real, consequential action (a ticket, a transaction, a code change) based on a fabricated premise.
• Memory poisoning: a RAG or memory store is seeded with false content the agent later retrieves and treats as verified fact.
• Excessive agent permissions: an agent is provisioned with broader tool or data access than its actual task requires, widening blast radius.
• Rogue autonomous behavior: an agent's chained decisions drift from its intended task into actions no one explicitly authorized.
• Third-party MCP server trust: a community-published server is added without code review, security manifest, or ongoing monitoring.
• AI policy violations: an agent's behavior breaches an internal governance policy without triggering any existing control.
• Continuous runtime drift: an agent's behavior gradually diverges from its validated baseline as prompts, tools, and models change over time.
Each of these played out, in some form, across the products OX Security examined — an unauthenticated endpoint exposing an MCP configuration screen, a tool accepting unsanitized command arguments, a coding assistant executing a payload the moment a poisoned repository was opened. None of it required a user to knowingly do something unsafe.
What Defines an Enterprise MCP Security Platform?
Enterprises evaluating vendors in this category should look past the marketing language and check for a specific, verifiable set of capabilities. Use this as an evaluation checklist.
• Discovery of MCP servers across sanctioned and shadow deployments
• Inventory of AI agents, their tool access, and their permission scope
• Continuous runtime monitoring of tool calls, not point-in-time scans
• Prompt and response inspection for injection and manipulation attempts
• Tool usage visibility mapped to the data and systems each tool touches
• Policy enforcement and permission management, applied inline
• Runtime anomaly and behavioral-drift detection
• Hallucination and unsafe-action detection before consequences land
• Third-party and community MCP server connector monitoring
• Structured AI interaction logging for forensic and audit use
• Continuous compliance evidence generation, not manual point-in-time reports
• Risk scoring and governance dashboards for security and compliance stakeholders
Why Enterprises Need an Agentic Supply Chain Security Platform
Securing agentic AI means securing every layer an agent touches: the models it calls, the agents themselves, the prompts that steer them, the memory they draw on, the orchestration logic that sequences their actions, the MCP servers and external tools they invoke, the APIs and plugins in between, and the identities and permissions attached to all of it. No single point solution covers that whole surface — which is exactly why runtime governance is emerging as a foundational security layer, sitting alongside AppSec, cloud security, and API security rather than replacing any of them.
Picture this layer as a control plane that spans the AI stack horizontally: it sits below the agent orchestration layer (observing every tool call and decision), beside the identity and access layer (enforcing permission boundaries in real time), and above the raw infrastructure (translating runtime signal into audit-ready evidence for compliance frameworks like the EU AI Act, NIST AI RMF, and ISO/IEC 42001). An Agentic Supply Chain Security Platform is the product category built to occupy that position.
Building a Secure MCP Strategy
1. Inventory every MCP server in use, including ones added informally by individual developers.
2. Continuously monitor dependencies across the MCP SDKs and packages your agents rely on.
3. Verify trusted publishers before approving a new MCP server for production use.
4. Restrict tool permissions to the minimum an agent's task actually requires.
5. Apply least privilege at the agent, tool, and data layer, not just the network layer.
6. Validate tool outputs before an agent acts on them, especially for consequential actions.
7. Monitor prompts and responses continuously for injection and manipulation.
8. Detect runtime anomalies against a validated behavioral baseline.
9. Govern AI behavior continuously, not through periodic point-in-time reviews.
10. Map identified risks to the compliance frameworks your organization is accountable to.
11. Conduct regular AI red-team exercises that simulate real attacker techniques against your live MCP deployments.
How Trusys Strengthens Enterprise MCP Security
Trusys is built as an operations layer for AI agents that spans discovery, evaluation, runtime monitoring, guardrails, and governance — orchestrated by Argus, the platform's autonomous governance engine. Rather than one module claiming to do everything, each capability maps to a distinct part of the MCP risk surface the OX Security disclosure exposed.
• Discovery and governance (Argus): automatically discovers tool inventories, memory stores, and egress paths across connected agents — including agents and MCP servers connected via API or SDK — and continuously enforces policy across every framework in use.
• Runtime observability (TruPulse): monitors production AI traces in real time, giving security teams visibility into tool calls, anomalies, and behavioral drift as they happen rather than after an incident.
• Inline enforcement (TruGuard): applies policy guardrails inline, in production, so a tool call that violates a defined boundary can be blocked rather than merely logged.
• Adversarial testing (TruScout): runs continuous red-team campaigns mapped to the OWASP Agentic AI Top 10 and MITRE ATLAS, testing agents against poisoned tools, hostile MCP responses, and prompt injection the way an actual attacker would.
• Code-level scanning (TruScan): catches insecure patterns in AI-generated and agent-adjacent code earlier in the development lifecycle.
• Compliance evidence (Argus): generates continuous, audit-ready evidence mapped to frameworks including the EU AI Act, NIST AI RMF, ISO/IEC 42001, and the OWASP Agentic AI Top 10, replacing manual point-in-time reporting.
Together, these capabilities give enterprises a way to discover what MCP servers and agents are actually running, watch how they behave in production, stop violations inline, and prove it to auditors — the combination that defines both an MCP Security Platform and an Agentic Supply Chain Security Platform in practice, not just in name.
Frequently Asked Questions
What is an Agentic Supply Chain Security Platform?
It is a security category purpose-built to protect every layer an AI agent touches — models, agents, prompts, memory, orchestration, MCP servers, tools, and APIs — with continuous discovery, runtime monitoring, and governance rather than one-time code review.
What is an MCP Security Platform?
It is a platform focused specifically on securing Model Context Protocol deployments: discovering MCP servers, monitoring tool calls, inspecting prompts and responses, and enforcing policy on agent-to-tool interactions in real time.
How does an MCP Security Platform protect AI agents?
By giving security teams continuous visibility into which MCP servers and tools an agent is calling, inspecting those interactions for injection or misuse, and enforcing permission and policy boundaries inline rather than after the fact.
What caused the recent MCP vulnerability?
OX Security identified an architectural flaw in Anthropic's official MCP SDKs across Python, TypeScript, Java, and Rust, where the STDIO transport passed unsanitized configuration values directly to shell execution, enabling remote command execution.
Why is runtime AI security important?
Because agents make dynamic, model-decided tool calls that static code scanning was never designed to evaluate — the risk lives in what an agent decides to do in production, not just in the code it was built from.
How can enterprises secure Model Context Protocol deployments?
By inventorying every MCP server in use, restricting tool permissions to least privilege, monitoring prompts and tool calls continuously, and running regular adversarial testing against live deployments.
What are the biggest risks in the AI agent supply chain?
Unauthorized MCP connections, prompt injection through connected tools, memory poisoning, excessive agent permissions, and unvetted third-party MCP servers are among the most consequential.
How does AI governance reduce MCP-related risk?
Continuous governance turns scattered runtime signals into enforceable policy and audit-ready evidence, closing the gap between a detected anomaly and an actual enforced control.
What capabilities should enterprises evaluate in an MCP Security Platform?
Discovery, inventory, continuous runtime monitoring, policy enforcement, anomaly and hallucination detection, third-party connector monitoring, structured logging, and continuous compliance evidence — see the evaluation checklist above.
How does Trusys improve AI runtime security and compliance?
Trusys combines Argus-orchestrated discovery and governance, TruPulse runtime observability, TruGuard inline enforcement, and TruScout adversarial testing into one operations layer, giving enterprises continuous visibility and audit-ready evidence across their AI agent and MCP footprint.
Stop guessing.
Start measuring.
Join teams building reliable AI with TruEval. Start with a free trial, no credit card required. Get your first evaluation running in under 10 minutes.
Questions about Trusys?
Our team is here to help. Schedule a personalized demo to see how Trusys fits your specific use case.
Book a Demo
Ready to dive in?
Check out our documentation and tutorials. Get started with example datasets and evaluation templates.
Start Free Trial
Free Trial
No credit card required
10 Min
To first evaluation
24/7
Enterprise support
The MCP Vulnerability That Put 200,000 Enterprise AI Instances at Risk — Why Every Enterprise Needs an Agentic Supply Chain Security Platform
Written by
Manish Tewari
Published on
Aug 04, 2026
ASI05: Unexpected Code Execution (RCE)
What it is: Agents increasingly generate and execute code to solve problems, creating a direct path from a manipulated prompt to arbitrary command execution on the underlying system.
Real-world example: A self-repairing coding agent generates unreviewed shell commands to fix a broken build and, through manipulation or plain error, deletes production data. In a more direct attack, an adversary embeds shell syntax inside a file the agent is asked to process, and the agent executes it as if it were a legitimate part of the task.
Business impact: Data loss, service outages, and in the worst case, full compromise of the execution environment.
Detection challenges: Code-generation agents produce plausible, syntactically correct commands constantly, which makes it hard to distinguish a legitimate fix from a malicious one without execution-time review.
Recommended mitigations: Sandbox all agent-generated code execution, require human approval before any destructive or irreversible command runs, and log every generated command together with the agent's stated rationale for post-hoc review.
AI agents no longer just answer questions. They call tools, read and write to enterprise systems, chain actions together, and increasingly operate with minimal human oversight. The Model Context Protocol (MCP) has become the connective tissue behind this shift — the standard that lets AI copilots, coding agents, and autonomous workflows reach into databases, SaaS platforms, and internal APIs on command.
That growth has outpaced the security review it deserved. On April 15, 2026, OX Security disclosed a systemic, architectural vulnerability in Anthropic's official MCP SDKs across Python, TypeScript, Java, and Rust — a flaw in how the STDIO transport handles server configuration that allows arbitrary command execution on any host an attacker can influence. The exposure is enormous: more than 150 million cumulative package downloads, roughly 7,000 publicly reachable MCP servers, and an estimated 200,000 vulnerable deployments across the ecosystem, with 14 or more CVEs assigned as investigations continue.
The disclosure is not really a story about one flawed SDK. It is a preview of what happens when enterprises adopt a new class of software — autonomous AI agents with tool access — faster than they build the controls to govern it. That is why the conversation among CISOs, Chief AI Officers, and platform engineering leaders has shifted from "which MCP servers do we run" to a bigger question: does our organization have an Agentic Supply Chain Security Platform and an MCP Security Platform at all, or are we relying on tools that were never built to see this layer of risk?
Understanding Model Context Protocol (MCP)
MCP is an open protocol, introduced by Anthropic in late 2024, that standardizes how AI models connect to external tools, data sources, and services. Before MCP, every integration between an LLM and an enterprise system — a CRM, a ticketing system, a code repository — required custom, one-off plumbing. MCP gives that connection a common shape.
The architecture is a client-server model. An MCP client (an IDE, an AI copilot, an agent framework) connects to one or more MCP servers, each of which exposes a defined set of tools, resources, or prompts the model can call. A server might wrap a database, a filesystem, a SaaS API, or an internal microservice. The client requests a tool call; the server executes it and returns a result the model can reason over.
That simplicity is exactly why adoption exploded. Within roughly eighteen months, the ecosystem grew to thousands of community-built server packages published across npm, PyPI, and language-specific registries, embedded in coding assistants, IDEs, and agent frameworks used across the enterprise. Growth this fast, across this many independently maintained packages, is precisely the pattern that has preceded every major software supply chain incident of the last decade.
What Happened: Breaking Down the OX Security MCP Vulnerability
OX Security's research, published under the title "The Mother of All AI Supply Chains," traced a single root-cause design decision through Anthropic's four official MCP SDKs. When an MCP client launches a local server over the STDIO transport, the SDK passes user- or config-supplied command and argument values directly to shell execution without sanitization — and the command can execute even when the target process fails to start.
It is important to separate three distinct layers here, since enterprise security teams often conflate them:
- The MCP protocol itself: defines STDIO as one of several transports, intended for local development and desktop tooling. The specification does not mandate how implementers handle trust boundaries between client and server.
- The SDK implementations: Anthropic's reference SDKs in Python, TypeScript, Java, and Rust are where the unsanitized command execution actually lives. This is the layer OX Security's disclosure targets directly.
- Downstream software: Products built on those SDKs — including LangFlow, LiteLLM, LangChain-based tools, Windsurf, and others — inherited the flaw without writing a single vulnerable line of their own code.
OX Security reported confirming arbitrary command execution on six live, production-grade platforms during coordinated disclosure, and issued more than 30 responsible disclosures resulting in at least 14 assigned CVEs to date. Anthropic, for its part, has characterized the STDIO execution behavior as expected by design and placed responsibility for input sanitization on downstream developers — a position that has become the center of ongoing industry debate about where protocol-level responsibility should sit.
What is verified: the SDK-level design flaw, the affected languages, the CVE count, and the six confirmed production exploits. What is analysis, not fact: the precise number of organizations currently exploitable in production, since the 200,000 figure is OX Security's estimate of vulnerable instances across the installed base, distinct from the roughly 7,000 servers it could directly scan and confirm as publicly reachable.
Why This Is Bigger Than One Vulnerability
AI ecosystems now behave like software supply chains, because that is what they are. A single agent framework depends on MCP SDKs, which depend on open-source packages, which depend on transitive dependencies several layers removed from anyone's direct review. Add third-party MCP servers, plugins, orchestration layers, memory systems, and vector databases, and the dependency graph looks less like a traditional application and more like the npm ecosystem circa 2021 — except every node in that graph now has the ability to take autonomous action.
The comparison to prior supply chain incidents is instructive, not alarmist. Log4Shell showed how a single ubiquitous, low-level library could compromise an enormous share of enterprise Java applications overnight. SolarWinds showed how trust in a vendor's build pipeline could be weaponized against thousands of downstream customers. Recurring npm and PyPI package-poisoning campaigns show how quickly a compromised dependency propagates once it is pulled into thousands of projects automatically.
The MCP disclosure combines elements of all three: a low-level, widely inherited design flaw (Log4Shell), propagation through trusted reference implementations (SolarWinds), and a package ecosystem where anyone can publish a server with minimal review (npm). What makes AI agents different — and more urgent — is that the compromised component is not passive code sitting in a library. It is a tool an autonomous agent is actively invoking, often with elevated permissions and no human reviewing each call.
The Rise of the Agentic AI Supply ChainA modern enterprise AI deployment is rarely a single model behind an API. It is a stack: MCP servers exposing tools, an orchestration or agent framework coordinating calls, memory stores and RAG pipelines feeding context, connections to external APIs and SaaS platforms, and one or more underlying model providers. A compromise anywhere in that stack can cascade through every layer above it, because each layer trusts the output of the one below it by default.
Trust boundary
Primary artifact
Update mechanism
Attack surface growth
Detection method
§54(2)
§54(3)
§55
§56
§58–59
§60
Ch. V.A
Traditional Software Supply Chain
Compiled code, packages, containers
Version-pinned dependency updates
New packages, new CVEs
SCA, SAST, dependency scanning
Human-in-command: override, suspension and kill-switch
Independent validation of third-party models regardless of vendor assurance
Agentic AI Supply Chain
Models, prompts, agent tools, memory
Live prompts, tool descriptions, MCP servers
New MCP servers, plugins, agent permissions
Runtime behavior and tool-call monitoring
Why Existing Security Tools Cannot Fully Protect AI Agents
Most enterprise security stacks were architected before agentic AI existed, and it shows. SAST and DAST scan code for known vulnerability patterns, not for a model's runtime decision to call an unexpected tool. CSPM secures cloud configuration, not the permissions an agent has been granted inside that cloud environment. API gateways enforce schema and rate limits, not whether a tool response has quietly altered an agent's next action. Endpoint security and traditional vulnerability scanners look for malware signatures and unpatched software, not a poisoned memory store or a manipulated tool description. SIEM platforms can ingest agent logs, but only if something upstream is generating structured, security-relevant signal from agent behavior in the first place — most agent stacks today are not instrumented to produce it.
Agentic AI introduces risk categories none of these tools were built to see: unauthorized tool calls, direct and indirect prompt injection, hallucinated actions taken as if they were real, excessive standing permissions, memory and RAG poisoning, context manipulation across multi-turn sessions, rogue or drifting autonomous behavior, and trust placed in third-party MCP servers with no formal vetting process. Closing that gap requires runtime-native tooling, not another layer of static scanning.
Runtime Risks Every Enterprise Must Monitor
• Unauthorized MCP connections: an agent or developer adds an unapproved MCP server to a workflow, and it silently gains the same tool access as vetted ones.
• Tool misuse: a legitimate tool is called with parameters or in a sequence outside its intended use, exfiltrating data through an approved channel.
• Sensitive data leakage: an agent passes regulated or confidential data into a tool call, a prompt, or a third-party API without policy enforcement in the loop.
• Prompt injection through connected tools: a tool's response — a webpage, a document, an email — contains hidden instructions the agent treats as legitimate user intent.
• Hallucinated actions: an agent takes a real, consequential action (a ticket, a transaction, a code change) based on a fabricated premise.
• Memory poisoning: a RAG or memory store is seeded with false content the agent later retrieves and treats as verified fact.
• Excessive agent permissions: an agent is provisioned with broader tool or data access than its actual task requires, widening blast radius.
• Rogue autonomous behavior: an agent's chained decisions drift from its intended task into actions no one explicitly authorized.
• Third-party MCP server trust: a community-published server is added without code review, security manifest, or ongoing monitoring.
• AI policy violations: an agent's behavior breaches an internal governance policy without triggering any existing control.
• Continuous runtime drift: an agent's behavior gradually diverges from its validated baseline as prompts, tools, and models change over time.
Each of these played out, in some form, across the products OX Security examined — an unauthenticated endpoint exposing an MCP configuration screen, a tool accepting unsanitized command arguments, a coding assistant executing a payload the moment a poisoned repository was opened. None of it required a user to knowingly do something unsafe.
What Defines an Enterprise MCP Security Platform?
Enterprises evaluating vendors in this category should look past the marketing language and check for a specific, verifiable set of capabilities. Use this as an evaluation checklist.
• Discovery of MCP servers across sanctioned and shadow deployments
• Inventory of AI agents, their tool access, and their permission scope
• Continuous runtime monitoring of tool calls, not point-in-time scans
• Prompt and response inspection for injection and manipulation attempts
• Tool usage visibility mapped to the data and systems each tool touches
• Policy enforcement and permission management, applied inline
• Runtime anomaly and behavioral-drift detection
• Hallucination and unsafe-action detection before consequences land
• Third-party and community MCP server connector monitoring
• Structured AI interaction logging for forensic and audit use
• Continuous compliance evidence generation, not manual point-in-time reports
• Risk scoring and governance dashboards for security and compliance stakeholders
Why Enterprises Need an Agentic Supply Chain Security Platform
Securing agentic AI means securing every layer an agent touches: the models it calls, the agents themselves, the prompts that steer them, the memory they draw on, the orchestration logic that sequences their actions, the MCP servers and external tools they invoke, the APIs and plugins in between, and the identities and permissions attached to all of it. No single point solution covers that whole surface — which is exactly why runtime governance is emerging as a foundational security layer, sitting alongside AppSec, cloud security, and API security rather than replacing any of them.
Picture this layer as a control plane that spans the AI stack horizontally: it sits below the agent orchestration layer (observing every tool call and decision), beside the identity and access layer (enforcing permission boundaries in real time), and above the raw infrastructure (translating runtime signal into audit-ready evidence for compliance frameworks like the EU AI Act, NIST AI RMF, and ISO/IEC 42001). An Agentic Supply Chain Security Platform is the product category built to occupy that position.
Building a Secure MCP Strategy
1. Inventory every MCP server in use, including ones added informally by individual developers.
2. Continuously monitor dependencies across the MCP SDKs and packages your agents rely on.
3. Verify trusted publishers before approving a new MCP server for production use.
4. Restrict tool permissions to the minimum an agent's task actually requires.
5. Apply least privilege at the agent, tool, and data layer, not just the network layer.
6. Validate tool outputs before an agent acts on them, especially for consequential actions.
7. Monitor prompts and responses continuously for injection and manipulation.
8. Detect runtime anomalies against a validated behavioral baseline.
9. Govern AI behavior continuously, not through periodic point-in-time reviews.
10. Map identified risks to the compliance frameworks your organization is accountable to.
11. Conduct regular AI red-team exercises that simulate real attacker techniques against your live MCP deployments.
How Trusys Strengthens Enterprise MCP Security
Trusys is built as an operations layer for AI agents that spans discovery, evaluation, runtime monitoring, guardrails, and governance — orchestrated by Argus, the platform's autonomous governance engine. Rather than one module claiming to do everything, each capability maps to a distinct part of the MCP risk surface the OX Security disclosure exposed.
• Discovery and governance (Argus): automatically discovers tool inventories, memory stores, and egress paths across connected agents — including agents and MCP servers connected via API or SDK — and continuously enforces policy across every framework in use.
• Runtime observability (TruPulse): monitors production AI traces in real time, giving security teams visibility into tool calls, anomalies, and behavioral drift as they happen rather than after an incident.
• Inline enforcement (TruGuard): applies policy guardrails inline, in production, so a tool call that violates a defined boundary can be blocked rather than merely logged.
• Adversarial testing (TruScout): runs continuous red-team campaigns mapped to the OWASP Agentic AI Top 10 and MITRE ATLAS, testing agents against poisoned tools, hostile MCP responses, and prompt injection the way an actual attacker would.
• Code-level scanning (TruScan): catches insecure patterns in AI-generated and agent-adjacent code earlier in the development lifecycle.
• Compliance evidence (Argus): generates continuous, audit-ready evidence mapped to frameworks including the EU AI Act, NIST AI RMF, ISO/IEC 42001, and the OWASP Agentic AI Top 10, replacing manual point-in-time reporting.
Together, these capabilities give enterprises a way to discover what MCP servers and agents are actually running, watch how they behave in production, stop violations inline, and prove it to auditors — the combination that defines both an MCP Security Platform and an Agentic Supply Chain Security Platform in practice, not just in name.
Frequently Asked Questions
What is an Agentic Supply Chain Security Platform?
It is a security category purpose-built to protect every layer an AI agent touches — models, agents, prompts, memory, orchestration, MCP servers, tools, and APIs — with continuous discovery, runtime monitoring, and governance rather than one-time code review.
What is an MCP Security Platform?
It is a platform focused specifically on securing Model Context Protocol deployments: discovering MCP servers, monitoring tool calls, inspecting prompts and responses, and enforcing policy on agent-to-tool interactions in real time.
How does an MCP Security Platform protect AI agents?
By giving security teams continuous visibility into which MCP servers and tools an agent is calling, inspecting those interactions for injection or misuse, and enforcing permission and policy boundaries inline rather than after the fact.
What caused the recent MCP vulnerability?
OX Security identified an architectural flaw in Anthropic's official MCP SDKs across Python, TypeScript, Java, and Rust, where the STDIO transport passed unsanitized configuration values directly to shell execution, enabling remote command execution.
Why is runtime AI security important?
Because agents make dynamic, model-decided tool calls that static code scanning was never designed to evaluate — the risk lives in what an agent decides to do in production, not just in the code it was built from.
How can enterprises secure Model Context Protocol deployments?
By inventorying every MCP server in use, restricting tool permissions to least privilege, monitoring prompts and tool calls continuously, and running regular adversarial testing against live deployments.
What are the biggest risks in the AI agent supply chain?
Unauthorized MCP connections, prompt injection through connected tools, memory poisoning, excessive agent permissions, and unvetted third-party MCP servers are among the most consequential.
How does AI governance reduce MCP-related risk?
Continuous governance turns scattered runtime signals into enforceable policy and audit-ready evidence, closing the gap between a detected anomaly and an actual enforced control.
What capabilities should enterprises evaluate in an MCP Security Platform?
Discovery, inventory, continuous runtime monitoring, policy enforcement, anomaly and hallucination detection, third-party connector monitoring, structured logging, and continuous compliance evidence — see the evaluation checklist above.
How does Trusys improve AI runtime security and compliance?
Trusys combines Argus-orchestrated discovery and governance, TruPulse runtime observability, TruGuard inline enforcement, and TruScout adversarial testing into one operations layer, giving enterprises continuous visibility and audit-ready evidence across their AI agent and MCP footprint.
Stop guessing.
Start measuring.
Join teams building reliable AI with Trusys. Start with a free trial, no credit card required. Get your first evaluation running in under 10 minutes.
Questions about Trusys?
Our team is here to help. Schedule a personalized demo to see how Trusys fits your specific use case.
Book a Demo
Ready to dive in?
Check out our documentation and tutorials. Get started with example datasets and evaluation templates.
Start Free Trial
Free Trial
No credit card required
10 Min
to get started
24/7
Enterprise support