We Tested 14 AI Agent Infrastructure Targets. Here's What Actually Breaks.

On April 19, Vercel disclosed a security incident tied to a compromise at Context.ai. According to third-party reporting, a Context.ai employee downloaded Roblox exploit scripts and was infected with Lumma Stealer. Stolen credentials later cascaded into Vercel's infrastructure through a compromised OAuth integration. Vercel says some customer environment variables were accessed, and that its investigation into the scope of exfiltration is ongoing.

The attack chain was not a zero-day. It was not a novel technique. It was a compromised third-party tool, a stolen OAuth token, and an environment variable store that treated integration credentials as trusted by default.

That same week, CISA issued an alert on the Axios npm supply chain compromise. Microsoft's analysis attributed the campaign to a North Korean threat actor that hijacked a maintainer account and published backdoored versions of a package with 70 million weekly downloads. The malicious payload was a cross-platform RAT deployed via a postinstall hook and was live for roughly three hours.

These are not isolated incidents. They are the integration layer breaking at scale.

The most immediate AI security risk is not in the model. It is in the integration layer.

We spent Q1 and early Q2 2026 running source-code and runtime security assessments against 14 AI agent infrastructure targets. We found over 200 confirmed vulnerabilities. This article describes the five patterns that keep appearing, why governance toolkits and platform-native scanning don't catch them, and what to do about it.

---

The Dataset

14 AI agent infrastructure targets. Source-code analysis of every public repository. Runtime validation against deployed, locally reproduced, or harness-based environments. Findings triaged by severity with CVSS 4.0 scores, CWE mappings, and reproduction steps.

The targets span the agent infrastructure stack: sandbox and runtime platforms, agent frameworks, MCP integration platforms, AI gateways and proxies, workflow orchestration systems, agent identity and auth providers, email and task agents, AI SDKs, and code security tools.

Combined: 200+ confirmed findings across all targets. 10+ critical, 50+ high, 80+ medium, plus additional low-severity findings.

Every finding is source-confirmed. Runtime findings were validated against locally deployed instances or harness-based scan environments. Targets are anonymized in this article. Findings have been or are being disclosed through responsible disclosure channels.

---

Pattern 1: Credential Exposure

Frequency: Found in 11 of 14 targets.

The most common vulnerability class across the dataset. Secrets stored in plaintext, committed to version control, cached beyond their lifetime, or exposed through transport layers.

What this looks like in practice:

One platform commits full SSH private keys (base64-encoded) to its git repository. The .gitignore excludes .env.local but not .env, allowing production secrets to be tracked in version control. The same platform stores its encryption key and salt as hardcoded default strings in committed configuration files.

A plugin platform's file-access hook fails to block a configuration file containing the API secret key in plaintext. Any agent or MCP tool can read the file and gain full tenant access.

An AI SDK logs complete API request/response payloads, including authorization headers and API keys, to external observability endpoints. The logging is enabled by default with no redaction.

The Vercel connection:

The Vercel/Context.ai incident followed this exact pattern. OAuth tokens stored as environment variables were treated as trusted data. Once those credentials were compromised through a supply chain escalation, the environment variable store became a high-value point of failure.

Trend Micro's analysis explicitly identifies the breach as an "OAuth Supply Chain Attack" exposing "the hidden risk in platform environment variables." That is not a new vulnerability class. It is the same credential exposure pattern we found in 11 of 14 targets.

OWASP Agentic mapping: ASI04 (Agentic Supply Chain Vulnerabilities), ASI03 (Identity and Privilege Abuse)

---

Pattern 2: Unsanitized Tool Inputs

Frequency: Found in 9 of 14 targets.

Agent tools accept user-controlled input and pass it directly into shell commands, file paths, URLs, or database queries without sanitization.

What this looks like in practice:

One sandbox platform's MCP file-deletion tool interpolates a path parameter directly into an rm -rf shell command via string formatting. No shell quoting, no path validation, no character filtering. An attacker invoking the tool can escape the file path and execute arbitrary commands in the tool or runtime context.

A CLI tool's environment variable substitution parses user-controlled YAML without escaping, enabling injection of arbitrary YAML directives that alter agent configuration at runtime.

An email agent's task assignment flow passes message content unsanitized into the agent's instruction context. Attacker-controlled content can redirect the agent to send unauthorized messages through the outbound pipeline.

Why this keeps happening:

Agent tool authors treat tool inputs like function parameters in a trusted codebase. But tool inputs cross a trust boundary: they originate from model outputs, user messages, or external data sources. The MCP specification defines tool schemas but does not enforce input validation. That responsibility falls on every individual tool implementation.

OWASP Agentic mapping: ASI02 (Tool Misuse and Exploitation), ASI05 (Unexpected Code Execution)

---

Pattern 3: Missing Authentication on Internal APIs

Frequency: Found in 8 of 14 targets.

Internal APIs that were designed for trusted, same-process communication get exposed across network boundaries without authentication.

What this looks like in practice:

One sandbox platform runs a daemon on a fixed port inside every container. The daemon accepts unauthenticated HTTP requests for file operations, command execution, git operations, and terminal sessions. An auth token is set during initialization but never validated on incoming requests. Any process that can reach the port can execute arbitrary operations.

An agent framework's MCP OAuth middleware accepts any bearer token when no token validator is configured. The default configuration ships with no validator, meaning all MCP tools are accessible without authentication out of the box.

An AI gateway retains a deprecated proxy route that still accepts requests and forwards them to upstream model providers without any of the authentication, rate limiting, or policy checks applied to the current API surface.

Why this keeps happening:

Development convenience. Internal APIs start as localhost-only services during prototyping. When the architecture evolves to multi-container, multi-service, or multi-tenant, the assumption that "this API is internal" persists in the code even after the network boundary has changed.

OWASP Agentic mapping: ASI03 (Identity and Privilege Abuse)

---

Pattern 4: Prompt and Context Injection

Frequency: Found in 7 of 14 targets.

Attacker-controlled content flows unsanitized into agent instruction contexts, model prompts, or template rendering pipelines.

What this looks like in practice:

A browser agent's rendering pipeline converts DOM content to markdown and injects it directly into the agent's perception context. An attacker who controls page content can inject instructions that redirect the agent to exfiltrate credentials from its own runtime context.

A prompt template renderer's escape function returns input strings unmodified. User-controlled variables in prompt templates can inject arbitrary content into model instructions, bypassing any intended safety constraints.

An email agent's task processing flow passes the full message body into the agent's instruction context. A crafted message can override the agent's parameters and trigger unauthorized actions.

Why this keeps happening:

The agent stack has a data/instruction confusion problem analogous to SQL injection, but distributed across multiple trust boundaries. DOM content, email bodies, API responses, and tool outputs all become "context" that the model treats as instructions. There is no standard separation between data channels and instruction channels in most agent frameworks.

OWASP Agentic mapping: ASI01 (Agent Goal Hijack), ASI06 (Memory and Context Poisoning)

---

Pattern 5: Sandbox and Isolation Failures

Frequency: Found in 5 of 14 targets.

Container isolation, network segmentation, or execution sandboxing that exists in documentation but not in implementation.

What this looks like in practice:

One platform runs every container with Docker privileged mode enabled, granting full kernel capabilities, device access, and expanded runtime access. Combined with an unauthenticated internal API and a shared hardcoded password, a compromise of any single container can collapse tenant or control-plane trust boundaries.

A workflow orchestration system uses unsigned serialized payloads as task tokens. Any caller with a valid token can modify identifiers and redirect task completion to a different workflow. The serialization layer provides no integrity guarantees.

One platform defaults inter-container networking to enabled, meaning containers share the bridge network and can freely communicate. Combined with unauthenticated internal APIs, this collapses multi-tenant isolation entirely.

Why this keeps happening:

Sandbox isolation requires defense in depth: container hardening, network segmentation, authentication on internal services, and least-privilege execution. Most platforms implement one or two of these layers and assume the rest. The gap between "we use containers" and "our containers are isolated" is where the real vulnerabilities live.

OWASP Agentic mapping: ASI05 (Unexpected Code Execution), ASI08 (Cascading Failures)

---

Why Governance Toolkits Don't Catch These

In April 2026, Microsoft shipped the Agent Governance Toolkit, an open-source runtime security solution covering all ten OWASP Agentic Top 10 risks. OWASP published the Agentic Top 10 itself. OpenAI acquired Promptfoo to integrate security testing into its Frontier platform. Anthropic launched Project Glasswing with Mythos Preview for defensive cyber work.

These are real advances. They raise the floor for agent security.

But they solve a different problem than the one we keep finding.

Governance toolkits enforce policy at runtime: "this agent is not allowed to call this tool with these parameters." They assume the underlying tools, APIs, and infrastructure are correctly implemented. They do not test whether your MCP tool sanitizes input, whether your internal API requires authentication, whether your sandbox actually isolates, or whether your OAuth middleware validates tokens.

The OWASP Agentic Top 10 names the risks. It does not test your system against them.

Platform-native scanning tests against known vulnerability patterns at the model and prompt layer. It does not audit your specific tool implementations, infrastructure configuration, or credential management.

The gap is at the integration layer. Between the framework documentation and the actual deployment. Between "we use OAuth" and "our OAuth middleware validates tokens." Between "we use containers" and "our containers are isolated."

That gap is where 200+ vulnerabilities live.

---

What This Means

The Vercel breach, the Axios supply chain compromise, and the findings in this dataset all point to the same conclusion:

The most immediate AI security risk is not in the model. It is in the integration layer.

Agent systems are being built on top of tool APIs, MCP servers, OAuth flows, container runtimes, and dependency chains that were not designed for the trust relationships agents impose on them. When an agent calls a tool, it implicitly trusts the tool's input handling, authentication, and execution isolation. That trust is rarely verified.

The OWASP Agentic Top 10 gives this problem a taxonomy. Microsoft's governance toolkit gives it a runtime enforcement layer. But neither substitutes for actually testing whether the implementation holds.

---

What To Do About It

Test at the integration layer before deployment. Not just model-level evals. Not just prompt injection tests. Test the tool implementations, the internal APIs, the credential stores, the container configurations, and the network boundaries.

Validate every trust boundary. Every tool call crosses a trust boundary. Every MCP server connection crosses a trust boundary. Every environment variable is a trust boundary. Treat them accordingly.

Don't assume isolation. Verify container hardening, network segmentation, and authentication on internal services. "We use containers" is not a security posture.

Rotate credentials proactively. The Vercel incident showed that a single compromised OAuth token can cascade across an entire platform. Assume credentials will be stolen. Design for revocation and rotation, not just protection.

---

Methodology

Our 168-attack taxonomy is open-source. The scanner covers 210 total attack patterns (168 taxonomy + 42 built-in). Runtime scans are triaged through a 15-heuristic engine that filters false positives before analyst review. Every finding in this dataset was source-confirmed or runtime-reproduced.

We run 48-hour assessments for teams that want to test their own agent infrastructure. Book a scoping call if you want to know what breaks in your system.