DEV Community: Michael "Mike" K. Saleme

The x402 payment layer has a state-synchronization gap, and four agent-payment attacks fall out of it

Michael "Mike" K. Saleme — Fri, 03 Jul 2026 16:27:42 +0000

Agent payments crossed from prototype to infrastructure faster than the security work did. The x402 protocol now carries more than 130 million transactions and sits inside Google Cloud, Cloudflare, and Stripe. Last week two papers put that infrastructure under a microscope, and one of them is a peer-reviewed conference result, not a preprint.

"Free-Riding the Agentic Web: A Systematic Security Analysis of x402 Payments" (arXiv:2605.30998), reports resource-leakage ratios up to 100 percent against official x402 SDKs and production deployments. A companion architecture paper, "Agent-to-Agent Finance" (arXiv:2607.00245), makes wallet risk a first-class channel and states it plainly: "a malicious service description can trigger prompt injection, which leads the agent to misinterpret the payment purpose, which causes wallet authorisation to approve an unintended transfer."

These are not one-vendor bugs. They come from something structural.

The gap: synchronous request, asynchronous finality

x402 bridges an HTTP request, which is synchronous and returns in milliseconds, to a blockchain settlement, which is final only after confirmations. Between "the client says it paid" and "the network agrees it paid" there is a window. Everything in that window is attack surface, and anything that settles on top of x402 inherits it.

The paper organizes the exploitable surface into four attack primitives. Each one lives in that gap.

The four primitives

Cross-resource substitution. A payment proof generated for one resource is replayed against a different resource. The payment is real; the binding between payment and thing-paid-for is missing.

Duplicate-settlement race. In the window between payment broadcast and on-chain finality, the same payment pulls the resource more than once. One payment, many deliveries.

Allowance overdraft. An approved token allowance is drained beyond the transaction it was scoped to. This is where session keys with over-broad approvals turn one authorized action into an open tab.

Denial of settlement. The attacker consumes the resource, then blocks or delays finality so the payment never lands. This one is not about extracting money. It is about taking the service for free while withholding settlement.

The paper also proves an impossibility result: no output-only pricing can be both fair to honest users and bounded against inflation of hidden computational tokens. Reasoning-token stuffing cannot be solved at the pricing layer alone. That is a design boundary, not a bug to patch.

What a conformance suite catches

Three of the four primitives are testable today, and they map onto existing vectors in the open-source agent-security-harness (532 tests across the agentic-payments stack):

Cross-resource substitution is caught by binding a payment to exactly one target: FB-015 (Voucher Resource-Hash Binding), X4-044 (Payment Replay Against Different Endpoint), and AP2-007 (Mandate Chain Link, which ties a payment mandate to a specific checkout hash).

Duplicate-settlement race is caught by refusing a second delivery on one authorization: X4-038 (Double-Spend Detection), AP2-013 (Double-Spend on Open Mandate), FB-017 (Escrow Over-Redemption), and FB-014 (Batch Voucher Replay and Monotonicity).

Allowance overdraft is caught by bounding what an approval can spend: CTK-003 and CTK-004 (Per-Transaction Amount Cap and Cumulative Velocity Cap), FB-011 and FB-012 (Amount Cap and Velocity Budget), and AP2-015 (Funding-Instrument Scope Binding).

Every one runs as a tamper-then-reject differential. You mutate the input the way the attack does, and a conformant implementation rejects it:

PASS  AP2-013: Double-Spend on Open Mandate
PASS  FB-017: Escrow Over-Redemption
PASS  CTK-004: Cumulative Velocity Cap

What it does not catch

Denial of settlement has no test in the suite. It is a liveness attack, not an integrity one: the malicious move is withholding finality, not tampering with a payload. Rate-limiting vectors are adjacent but not equivalent, and pretending otherwise would be the coverage theater that makes a green test run lie. The honest state is that this attack class is named, understood, and currently untested. It is the next vector to build.

The impossibility result sits even further outside a conformance suite's reach. You cannot write a pass-or-fail vector for a pricing model that is provably unsolvable at its own layer. That belongs in protocol design, not test coverage.

The one decision that closes the race

Most of the duplicate-settlement race collapses to a single architectural choice: what is the authoritative point at which your stack treats a payment as final before it releases the resource?

If the answer is "the facilitator's callback," the race is wide open, because the callback fires before the chain agrees. If the answer is "N on-chain confirmations" or "a signed settlement receipt," the window closes, at the cost of latency you design for.

Test coverage tells you whether your verifier rejects a tampered payment. It cannot tell you where you drew your finality line. That line is where agent payments are won or lost.

If you build on x402, ship the tests for the three primitives you can catch, and write down your finality point for the one you cannot.

Full test-ID mapping and discussion: harness thread #231

Agent payment standards are standardizing the cap, not the binding

Michael "Mike" K. Saleme — Tue, 30 Jun 2026 13:27:35 +0000

Agent-to-agent payments are settling into a clean decomposition. The protocol owns the state transition. A receipt layer owns the evidence. A trust layer reads the receipts. The field lists now circulating for a machine-readable "payment required" state — network, asset, amount cap, recipient, expiry, idempotency key, proof-header shape, denial reason — are the right instinct.

They standardize what is present. They leave open what is provable.

A spend cap that is present on the wire is not a spend cap a downstream verifier can prove was the one the mandate authorized. An intermediary forwards a well-formed challenge whose cap, recipient, or expiry no longer matches the authority that issued it. The receipt looks valid. The drift goes uncaught. That is scope-widening — a different failure than replay: replay reuses a valid authorization, scope-widening mutates one in transit.

The fix is a binding, not another field.

A content-addressed reference — call it guardrail_ref — ties amount_cap + recipient + expiry to the authorizing mandate and travels into the post-payment receipt. The verifier evaluates the action against the authority that actually permitted it, not against a number an intermediary asserted. The cap value stays implementation-local. The binding to the mandate is the one thing that has to be machine-checkable at the boundary.

This is where conformance testing earns its keep. Three vectors define the boundary: a forwarded cap that diverges from its mandate, a recipient or expiry broadened in transit, and a double-spend chained across agent calls. Wire-level adversarial suites for x402 and L402 already catalog dozens of payment-protocol attacks. The authority-binding layer above them is still silent.

Every agent passport layer is grading its own exam

Michael "Mike" K. Saleme — Sun, 21 Jun 2026 17:11:47 +0000

A new layer is consolidating in the agent stack, and it has a name now: pre-action authorization. The idea is clean. Before an agent executes a tool call, a deterministic policy engine intercepts it, checks it against declarative rules, and signs an audit record. The model proposes; the gateway disposes.

This pattern is real and it is shipping.

In Before the Tool Call: Deterministic Pre-Action Authorization for Autonomous AI Agents (arXiv 2603.20953), Uchi Uchibeke specifies it precisely: authorization "runs at the framework layer, not the model's reasoning layer. Prompt injection cannot override it." Same inputs, same decision, no model in the evaluation path. The Agent Passport System (APS) ships the same shape in production form — Ed25519 identities, scoped delegation that can only narrow, a three-signature action chain.

The architecture is right. The protocol layer cannot enforce safety, so a deterministic gateway above it must. NSA's June MCP advisory says the same thing from the defensive side: deny-by-default, scope everything, sign every message.

So the design is converging. Here is the part that isn't.

Self-attestation is not resistance

Every implementation in this layer is tested by the people who built it.

OAP reports a striking number: social engineering succeeded against the bare model 74.6% of the time, and 0% against a restrictive OAP policy across 879 attempts. Read the limitations section, in the author's own words: the attackers "self-select and skew toward social engineering rather than protocol-level attacks; results may not generalize to APT-grade adversaries." It's a self-run bounty, by the spec author, against a self-selected crowd. That's not a criticism of OAP — it's an honest disclosure most of this field doesn't make.

APS goes further and says the quiet part in its own README: "A valid signature is not a valid claim." It enumerates receipts that are cryptographically perfect and must still be rejected — wrong claim, expired delegation, revoked delegation. The team clearly understands the gap. And its conformance suite? Byte-level. It verifies that two implementations canonicalize identically — interoperability — and states plainly it "does not replace dynamic test execution."

So we have two kinds of testing in this layer, and neither is the one that matters most:

Self-run adversarial evals, tied to the implementation that's being graded.

Byte-level conformance, which proves two systems agree, never that either one is right.

Conformance proves agreement. It never proves resistance.

The missing discipline

What this layer does not have is a neutral adversary — a third-party harness that takes any pre-action-authorization gateway, regardless of who built it, and attempts protocol-level bypass, scope-boundary escalation, delegation-chain abuse, and replay. One that scores resistance, not self-attested policy.

This pattern already exists everywhere else in security. TLS implementations don't get to publish their own interop test as proof of security — they face independent test suites and external attack. Payment terminals submit to PCI test labs they don't control. The entire premise of a trust layer is that its trust is externally verifiable. A passport you grade yourself is a name tag.

The agent-identity layer is being built right now, fast. NIST's AI Agent Standards Initiative (Feb 2026) made identity one of three pillars. OWASP's Top 10 for Agentic Applications (2026) added ASI04 — agentic supply chain — and ASI07, insecure inter-agent communication. MCP moved to OAuth 2.1 with RFC 8707 resource-scoped tokens. Every one of these is a control surface that will ship with a vendor's own test results attached.

The slot for the independent adversary is open. Not because no one can fill it — because the people building the gateways are, understandably, building gateways, not the thing that attacks them.

What an adversarial conformance harness looks like

I've been building the attacker's half of this for the protocol below it. The Agent Security Harness runs 474 adversarial tests against MCP and agent endpoints — it forges elevated OAuth scopes and checks they're rejected (AUTH-003), it plants command-execution canaries in the handshake (MCP-017), it walks delegation chains looking for authority that should have narrowed and didn't.

That last category is exactly what the passport layer needs and doesn't yet have a neutral version of: take a signed delegation, attempt to use it beyond its scope, and score whether the gateway holds. APS's own model says authority "can only decrease at each transfer point." Good. Now prove it against an adversary who didn't write the gateway.

The honest framing: I test the protocol layer today, not the passport layer. The passport layer's adversarial conformance is unbuilt — by me or anyone. I'm naming it because the design has converged far enough that the gap is now the most important thing in the picture.

A passport proves who an agent is. It does not prove that identity can't be turned against you. The first one is a signature. The second one only a determined adversary can certify — and right now, in this layer, the only adversary in the room is the one who built the lock.

Sources: arXiv 2603.20953; github.com/aeoess/agent-passport-system; NIST AI Agent Standards Initiative (Feb 2026); OWASP Top 10 for Agentic Applications 2026; MCP Authorization spec (RFC 8707).

The whole payments industry now co-signs the agent payment rail. Who red-teams it?

Michael "Mike" K. Saleme — Wed, 17 Jun 2026 13:14:58 +0000

x402 moved to the Linux Foundation this quarter, and the contributor list is the story: Coinbase, Cloudflare, and Stripe at the core, now joined by Google, AWS, Visa, Mastercard, American Express, Circle, Shopify, Microsoft, Solana, and Polygon. The agent payment rail just became shared utility infrastructure.

That's the right outcome for a payment standard. It also opens a structural blind spot.

The co-signer problem

When the entire payments industry co-governs a protocol, every governing member shares one incentive: ship it, adopt it, settle on it. None is positioned to adversarially attack the rail it jointly stewards — a consortium cannot credibly red-team itself. The wider the consortium, the wider the blind spot.

This is an industry pattern, not an x402 flaw. Shared infrastructure gets standardized faster than it gets attacked — HTTP, OAuth, and BGP each became load-bearing years before the adversarial literature caught up. x402 is on that trajectory, compressed into months.

What gets exposed

x402 turns any endpoint into a paywall an agent navigates without a human: the 402 response carries machine-readable price and settlement, the agent signs and retries, a facilitator settles on-chain. Each step is an attack surface that does not exist in human-in-the-loop payments:

the price/settlement object the agent parses — inject the terms
the signing step — authority to spend with no confirmation
the facilitator — the verify-and-settle trust boundary
the retry loop — cascade one 402 into a payment chain

These map directly onto the dispute-as-DoS and budget-exhaustion test classes already in the open-source x402/L402 security modules I maintain.

The opening

A protocol commoditizing does not reduce the need to test it — it raises it. A rail the whole industry runs on is a rail whose failure modes are everyone's problem and no single steward's mandate.

Someone outside the consortium has to test the rail the consortium can't.

For anyone building on x402: when your agent signs a payment payload, what sits between the injected 402 and the signature — and who tested that path?

When the guardrail becomes the target: reasoning-extension DoS against LLM safety layers

Michael "Mike" K. Saleme — Mon, 15 Jun 2026 15:05:57 +0000

New research from HKUST (arXiv:2606.14517, June 12) turns the agent safety layer into the attack surface.

What happened

Reasoning-based guardrails — the LLM safety layers that screen an agent's actions — can be trapped in their own analysis. Crafted inputs mimic the guardrail's internal schema (risk enumerations, assessment matrices), and the model, in the authors' words, "mechanically fills a template it has constructed for itself, trapped by its own instruction-following fidelity."

The measured effect: 13–63× token amplification in isolation, and 148× end-to-end latency in a LangGraph multi-agent deployment — a single guardrail call stretched to 730 seconds. Because the payload is fluent natural language, an injection classifier scored it below 0.001 probability and passed it through.

Why it matters

The attacker needs no model weights, no system prompt, no infrastructure access — only the ability to place text where the agent will read it: a web page, a repo comment, a tool result.

And every candidate fix the authors tested fails. A token-budget cutoff only relocates the failure: fail-open lets the attack bypass safety entirely; fail-closed converts it into agent-level DoS that starves co-located agents on shared guardrail infrastructure. A more capable guardrail performs worse — stronger reasoning produces longer loops.

This is a structural property of the reasoning-guardrail paradigm, not a defect to patch.

What catches it today

Part of it — and it's the part most test harnesses get wrong. A guardrail that stalls or crashes under load must never be scored as a successful defense.

In our open-source agent-security harness, the verdict-correctness suite encodes exactly this: the rejection primitive treats transport failure and 5xx responses as not a rejection — the code comment reads "a 5xx may itself be the attack succeeding." The tests assert that a dead or faulting defender cannot earn a passing verdict.

The paper closes by calling for "cost-bounded safety architectures." That is precisely what a governance layer enforces: a THROTTLE→FREEZE state machine halts discretionary spend the moment a gate fails, and a hard constraint surfaces any guardrail that has gone dark.

What's missing

The honest gap: protocol-layer DoS (batch bombs, oversized payloads, rate floods) and verdict-correctness are covered. Reasoning-extension DoS — a schema-mimicking payload that inflates an LLM guardrail's own token and latency budget — is not. That's a net-new test class, and it's going on the roadmap.

A guardrail that can reason can be made to reason forever.

One question for operators

When your LLM guardrail hits a compute ceiling mid-evaluation, does it fail open or fail closed — and how do you distinguish a real "blocked" verdict from a guardrail that simply ran out of budget?

The Agentic Maturity Model Is Missing an Axis: Who Validated the Claim

Michael "Mike" K. Saleme — Mon, 08 Jun 2026 16:24:26 +0000

On June 3, the OWASP GenAI Security Project published State of Agentic AI Security and Governance 2.0, and with it an Enterprise Adoption Maturity Model that grades two things at once.

One axis measures deployment: AT0 Shadow AI through AT5 custom in-house agents that you built and whose identity, tools, and boundaries you control. The other measures governance maturity: Level 0 ad hoc through Level 3, where agents are treated as critical infrastructure with governance-as-code, kill switches, and real-time drift dashboards.

It is the clearest two-axis picture we have seen published. It also shares a blind spot with the maturity models that preceded it.

Both axes describe what the organization does. Neither captures who verified that it does it.

Two organizations, same cell, different truth

Take two organizations that both self-place at Governance Level 3. Both claim governance-as-code. Both claim kill switches. Both claim continuous drift monitoring.

One arrived there through an internal red-team's self-attestation. The other arrived through independent adversarial assessment with a published, reproducible evidence base. On the matrix, they occupy the same cell. In a procurement review, in an incident post-mortem, in front of a regulator, they are not the same artifact.

A maturity model that measures what an organization does, but not who validated it, grades the claim and not the control.

The pattern already exists in established assurance

This is not a novel demand. Assurance practice has separated self-attestation from independent validation for decades. A SOC 2 Type I report describes controls as designed; a Type II report tests whether they operated over time. A vendor security questionnaire and a third-party penetration test answer different questions, and no mature buyer treats them as interchangeable. Vulnerability scoring encodes the same instinct: CVSS tempers a finding by its Exploit Maturity — Unproven, Proof-of-Concept, Functional, High — grading the evidence behind a claim, not only the claim's severity.

Agentic governance has not yet imported that distinction. The EU AI Act's high-risk obligations — now deferred to December 2027 because the supporting standards aren't ready — turn on demonstrable oversight, not asserted oversight. The maturity model needs the third axis the regulation will require: evidence type.

What the third axis looks like

Evidence type asks one question of every governance claim: what class of evidence supports it, and is the claim stronger than that evidence permits?

This pattern exists in disciplined evaluation work. For example, in the public agent-security-harness VS-R01 evaluation of agent-payment infrastructure, every finding is tagged with an evidence class:

E1 — static or documentation observation
E2 — admission-time runtime observation (the API's response at the input gate, before settlement)
E3 — settlement-time runtime observation
E4 — adversarial replay and persistence validated
E5 — cross-context isolation confirmed against both negative and positive controls

Each class maps to a maximum permitted claim strength. An E2 observation may describe how an API admits or refuses a crafted input; it may not claim the platform enforces a limit, because enforcement is a settlement-time property and settlement was not measured. A recurring failure mode in agent-security writeups — making an enforcement claim from admission evidence — becomes visible at review time instead of in production.

That is the third axis made concrete. It is reproducible from a public branch state by any reviewer with their own test enrollment, which is the property that separates evidence from assertion.

The cell isn't the credential

The OWASP model is a real advance, and the right place to put this. Adoption tells you how much autonomy an organization has handed its agents. Governance maturity tells you how much control it claims to have built. Evidence type tells you whether anyone outside the organization can check.

For agents that hold credentials, move money, and act on untrusted input, the third question is the one that survives contact with a regulator. Grade the evidence, not the claim.

Sources

OWASP — State of Agentic AI Security and Governance 2.0
Infosecurity Magazine — OWASP Introduces Agentic AI Security Maturity Framework
VS-R01 evidence taxonomy — msaleme/red-team-blue-team-agent-fabric

98% of Agents Carry the Lethal Trifecta. Last Week Showed Why.

Michael "Mike" K. Saleme — Sat, 06 Jun 2026 14:09:23 +0000

Adversa's Q2 2026 AI Risk Quadrant Report, published June 3, scored 100 production agent systems against three dimensions: attack surface, blast radius, and defenses. Two numbers worth holding.

98 of the 100 carry the lethal trifecta — Simon Willison's framing for the combination of access to private data, exposure to untrusted content, and the ability to take outbound actions, on the same execution path.

Only 11% qualify as adequately defended.

At least 87% don't lack the trifecta. They've got it; they just haven't built around it.

Tool execution alone explains 76% of blast-radius variance across the cohort. That's the headline finding. The capacity to act in the world — to write to APIs, push commits, install packages, send messages — is what converts an agent failure from a logged exception into an operational incident.

What an unbounded trifecta looks like in production

The Miasma worm, first observed June 1 in compromised @redhat-cloud-services npm packages, was that 87% number expressed as an event. The campaign republished 96 versions across 32 packages with a preinstall payload that harvested AWS, GCP, and Azure credentials, Vault tokens, SSH keys, and .env files, then propagated itself through every package the victim's account had permission to publish.

By June 5, a variant — "Phantom Gyp" — had reached Microsoft Azure's durabletask repository via a compromised contributor. The payload was 4.3 megabytes, wired to auto-execute inside Claude Code, Gemini CLI, Cursor, VS Code, and npm test. GitHub disabled 73 Microsoft repositories across four organizations in a 105-second sweep.

Trace what happened to the AIRQ scorecard for the targeted environments:

Private data: cloud provider credentials, SSH keys, source-controlled secrets — the entire .env file
Untrusted content: a package update from a compromised maintainer account
Outbound action: the preinstall hook running with the developer's local privileges, including outbound HTTP for exfiltration and write access to every package the developer could publish

Three trifecta legs, on the same execution path, inside the developer's agent tool environment. The defense layer that was supposed to exist between "I installed a dependency" and "I am now exfiltrating credentials" did not.

The agent dev environment is the enforcement surface

The thing AIRQ's measurement implies, and Miasma demonstrates, is that the trifecta's enforcement surface is no longer the application boundary. It is the developer's tool environment.

A Cursor session, a Claude Code session, a Gemini CLI run — these are agent execution contexts with privileged access to the developer's local credentials, source tree, and outbound network. When a compromised npm package executes a preinstall hook inside that context, the trifecta closes on the agent environment, not on a deployed application.

That changes what the defense layer has to do. Vendor-managed sandboxing of the LLM doesn't help, because the lethal capability — install a package, run npm test, execute a tool — is on the developer's machine, not in the model provider's data center. Token scoping doesn't help unless the scopes are tight enough to refuse credential reads from arbitrary preinstall hooks. Vault integration doesn't help if the agent environment can read environment variables on behalf of the user.

The application-layer trifecta is a structural pattern across enterprise agent systems; the AIRQ report measures it. Miasma extended that pattern by one rung up the stack: the developer's tool environment now carries the same trifecta with strictly higher privileges. The 11%-adequately-defended threshold gets harder to clear at this layer, not easier.

The trifecta moved up a layer. The enforcement surface moved with it.

What the structural defense actually looks like

Defenses that survive when the agent environment is the enforcement surface have three properties.

Admission-time gates, not post-hoc detection. A preinstall hook that reads credentials and exfiltrates them runs in seconds. Detection-based defense is the wrong tier. The gate has to sit at the layer that decides whether the hook runs at all.

Capability scoping that survives the developer-trusts-the-tool assumption. The agent tool environment runs commands the developer authorized. The credential surface has to be narrow enough that "the developer authorized this" doesn't imply "the credentials are reachable."

Identify-and-revoke posture for credential exposure, not credential rotation. When a hook has read .env and shipped the contents, the credentials are exposed regardless of whether they've been rotated since. The operational response is to identify the affected scopes and revoke their permissions, not generate new tokens for the same scopes.

Miasma's design exploits the absence of all three. The preinstall hook ran at admission time because admission was uninstrumented. The credentials were reachable because tool-environment scoping is rare. The remediation guidance from most affected vendors named rotation as the response, which preserves the attacker's foothold across the rotation cycle.

What the harness covers, what it doesn't

The agent-security-harness community plugin runtime and MCP server modules exercise the equivalent of preinstall-hook code paths inside MCP plugin loading: untrusted YAML, eval-injection patterns, file size caps, regex safety, delay caps. The community runner's plugin validator is the closest defensive analog the harness contains to what Miasma exploited at the npm layer.

What the harness does not cover today:

The npm preinstall-hook surface itself — that is an upstream package-manager attack vector, not an MCP or A2A protocol attack
The Claude Code / Cursor / Gemini CLI agent tool environment as a measured execution context — these are vendor-managed sandboxes the harness does not directly probe
Cross-package contributor-account-compromise propagation — that is a registry-governance question, not an agent-protocol-runtime question

The AIRQ measurement is the right anchor for what the harness does measure: the application-layer trifecta defense gap. The Miasma case is the canonical example of why that gap matters at the layer immediately above.

Sources

The EU AI Act Was Written for Models. Your Agents Need Runtime Compliance.

Michael "Mike" K. Saleme — Tue, 26 May 2026 13:04:09 +0000

The EU AI Act's high-risk obligations were due to apply on 2 August 2026. On 7 May 2026, the Council and Parliament agreed to move them: to 2 December 2027 for stand-alone high-risk systems under Annex III, and to 2 August 2028 for high-risk systems embedded in regulated products under Annex I. The agreement is provisional — pending formal adoption and Official Journal publication, expected before the original August date.

Read why it moved. The deferral is tied to the availability of the harmonised technical standards the regime runs on, and those standards are not ready. A compliance regime does not extend its own flagship deadline by sixteen months unless the evidence it asked for cannot yet be produced.

The evidence the Act was designed to evaluate — model cards, training-data lineage, evaluation suites, conformity assessments — describes a model artifact at rest. The systems enterprises are actually deploying are autonomous agents that use those models at runtime.

The extension is a confession about runtime evidence

The Act's runtime obligations already exist: automatic logging over the system lifecycle (Article 12), deployer monitoring (Article 26), post-market monitoring (Article 72). They were written for system-level events, not for the tool-call boundary where agent behavior actually lives. That boundary is what the harmonised standards have to make demonstrable — and it is the part no one has standardized.

The deadline did not slip because regulators went soft on autonomous AI. It slipped because the industry cannot yet produce the runtime evidence the Act demands — and the standards bodies know it.

The extension buys sixteen months. It does not change what the evidence has to show.

Three runtime gaps the act was not written to see

MCP transport and the sanitization handoff

Tool-protocol transports define the trust boundary between a model's intent and the system it is allowed to touch. When the transport assumes a trusted local context, every downstream control inherits that assumption.

The National Security Agency published MCP security guidance in May 2026 — the first time a national-security authority has issued an advisory on an agent tool protocol. The guidance addresses the STDIO transport design and the implicit local-trust assumption that flows from it. Anthropic confirmed the behavior is by design: sanitization is the integrating developer's responsibility.

That sentence is the entire compliance gap. The protocol shipped a default; the regulation evaluated the model; the boundary control is somebody else's problem. There are more than 200,000 MCP servers exposed, 30+ disclosures across the ecosystem, and ten CVEs across the official SDK languages. None of that surface is what a model-card evaluator looks at.

Anthropic's response to the systemic risk was MCP Tunnels and Self-Hosted Sandboxes, shipped May 19 as a limited research preview. Private-network MCP deployment is the right architectural direction. It is also a tacit acknowledgement that public-network MCP is not a posture an enterprise can take to a regulator.

x402 spend governance arrived from the security vendor, not the protocol

Payment-capable agents define a new category of compliance surface. The model can be perfectly aligned at training time and still authorize a spend at runtime that the deployer cannot defend in an audit.

x402, the HTTP 402 revival for agent-initiated payments, shipped without native spend governance. Fireblocks joined the x402 Foundation on May 20, 2026 and released a security extension that adds request integrity and spend-policy controls on top of the base protocol. AWS launched Bedrock AgentCore Payments in preview on May 7, with policy-based spend controls and an audit trail as managed-service primitives.

The pattern is consistent. The protocol shipped the capability; security and policy enforcement arrived as a second layer from vendors who took the runtime-control problem seriously. The AI Act will hold the deployer accountable for the spend, not the protocol for the omission.

Payment-tool authorization and the AP2/ACP interop layer

Agent-to-merchant payment flows define a new authorization surface that did not exist when the AI Act text was finalized. Stripe shipped its Link agent wallet and ACP/AP2 interop at Sessions 2026. The flows are real, the volume is small, and the standards are still being negotiated in public.

The compliance question is not whether the model approved the purchase. It is whether the operator can produce, on demand, a runtime audit trail that shows which constraint gated the authorization, which credential signed the request, and which policy revoked it when the spend pattern drifted.

That evidence is not produced by a model card. It is produced by the runtime, or it is not produced at all.

Static model audits and the time-shift problem

A model audit evaluates an artifact at training time. An agent violation occurs at tool-use time. The two events are separated by every input the agent will ever receive in production and every tool it will ever be granted.

A model card cannot tell you which MCP server an agent called yesterday at 3am. A conformity assessment cannot tell you which x402 endpoint absorbed an unbounded spend. A datasheet cannot show you which constraint failed open when a prompt injection rewrote the agent's plan.

Models pass audits at training time. Agents fail them at tool-use time. The deadline moved to December 2027; the gap did not move with it.

What runtime compliance actually looks like

The control surface the AI Act implies but does not specify has three layers.

Adversarial testing of the agent's tool surface. Not red-teaming the model — red-teaming the runtime composition. Prompt injection against the actual tool list. Spend-bound bypass against the actual x402 client. MCP transport abuse against the actual server set. The artifact under test is the deployed agent, not the model behind it.

Decision-gate governance with hard constraints. A constraint is not a system-prompt instruction. It is a runtime gate the agent cannot route around, with an amendment protocol that produces a paper trail when the constraint changes. The AI Act's high-risk obligations imply this; they do not specify the mechanism.

Runtime audit trails that survive a regulator's read. What was authorized, by which credential, against which policy, with what evidence — and when exposed credentials are detected, the operator's first move is to identify and revoke, not to rotate after the fact. Rotation assumes you already know what needs rotating. Identification is the regulatory question.

This is the work category I have been publishing under for the last year. The harness on PyPI as agent-security-harness runs adversarial coverage across MCP, A2A, x402, and L402 — pre-cert against AIUC-1 and aligned to NIST AI 800-2 — and grades every finding by evidence class, so an admission-time observation never reads as an enforcement guarantee. The governance package constitutional-agent carries six decision gates, twelve hard constraints, and an amendment protocol that produces a paper trail when a constraint changes. We have not found another open framework that covers both the adversarial-testing layer and the constitutional-governance layer as a paired stack. That is the point — the gap is real enough that the two layers had to be built separately and composed.

What the bifurcation actually splits

Vendors will claim model compliance. Most of those claims will be defensible at the artifact level, in the narrow technical sense the act evaluates. None of them will close the runtime gap, because the runtime is not the vendor's artifact — it is the deployer's composition.

The bifurcation is not about who is compliant. It is about which layer of the stack the compliance evidence describes. Deployers who can produce runtime audit trails, hard-constraint enforcement logs, and adversarial coverage reports will have evidence that maps to high-risk obligations. Deployers who can only forward a vendor's model card will have a document that describes something other than the system that actually shipped.

The clock reset to December 2027. The model evidence is the vendor's to provide; the runtime evidence is yours to produce.

Stop Babysitting What? The Trust Boundary You Just Relocated.

Michael "Mike" K. Saleme — Fri, 22 May 2026 15:52:15 +0000

On 2026-05-19, Sid Bidasaria — founding engineer and tech lead of Claude Code at Anthropic — gave a talk at Code with Claude London titled "Stop babysitting your agents." The talk lays out three patterns that compound: verification loops, parallelization, and background routines. The argument is genuine, the engineering is real, and the patterns work.

But each pattern shares an unstated assumption: that the automation you put in place to remove human oversight is itself trustworthy. The talk scales the things you can automate. It does not scale the question that decides whether the automation is safe.

The trust boundary doesn't disappear when you automate. It relocates. Each of the three patterns moves it to a different surface, most of which teams have not built infrastructure for yet.

Pattern 1 — Verification loops move the trust boundary from "code review" to the harness itself

When an agent verifies its own work, the question "is this code safe?" is replaced by "is the verification harness adversarially robust?" The two are not the same.

The structural failure mode is concrete. Over the past six months, the AI agent framework ecosystem has shipped a coherent cluster of CWE-502 (insecure deserialization) vulnerabilities:

CVE-2026-26210 — ktransformers ≤ 0.5.3, CVSS 9.8 — ZMQ ROUTER socket binds 0.0.0.0 with no authentication; worker calls pickle.loads() on raw network bytes.
CVE-2026-28277 — langgraph ≤ 1.0.9, CVSS 7.2 — SQLite checkpoint loader reconstructs Python objects from msgpack without an allowlist.
CVE-2025-68664 — langchain-core < 0.3.81, CVSS 9.3 — dumps()/dumpd() allow user-controlled lc keys, enabling Jinja2 template injection and credential extraction on deserialize.
CVE-2026-7712 — MindsDB ≤ 26.01, CVSS 6.3 — pickle.loads() in the Pickle Handler without input validation; vendor declined to patch.

An agent that resumes from a poisoned checkpoint will self-verify successfully, because the verification runs in the same process that just got compromised. The prompt injection that lets an agent write malicious code can corrupt the agent's "I checked it" claim by the same mechanism. The verifier and the thing being verified share a substrate, and that substrate is the attack surface.

The fix is not "tell Claude to check more carefully." The fix is adversarial tests for the verifier itself: prompt-injection vectors that target the verification claim, checkpoint poisoning that survives self-verification, tool-output manipulation that flips PASS to FAIL.

When Pattern 1 lands, the trust boundary has moved. "Did a human read the diff" is replaced by "is the harness verified." Don't conflate "Claude verified it" with "the verification is verified."

Pattern 2 — Parallelization moves the trust boundary to agent-to-agent attestation

The Bidasaria framework's natural extension is the asymmetric notification architecture: agents seek aid from adjacent specialized agent processes rather than escalating to humans. Ten Claudes verifying each other. Cross-agent attestation as the gate.

This is where lived evidence gets uncomfortable. Operating on AI agent standards-body threads (a2aproject/A2A, microsoft/autogen, x402-foundation/x402) for two months has surfaced a recurring pattern: an account named kenneives "independently verifies" a proposal from Liuyanfeng1234. Both validate arian-gogani's receipts in a parallel thread. On 2026-05-16, arian-gogani publicly admitted that SpeedGenius00 — which had been "independently verifying" the same proposals — was an old account of his, accidentally posted under.

That cluster operates exactly the architecture the asymmetric-notification prescription describes. Agents validating each other to reduce human notification load. The closed loop sells itself as "independent verification" because the human in the loop has been removed by design.

Cross-agent attestation cannot be the trust boundary. It has to reference a trust boundary that lives somewhere the agents do not control. Out-of-band identity (W3C DIDs, cryptographically-signed agent attestations), verifiable evidence schemas that compose across providers, substrate-neutral standards bodies — these are not features to add later. They are the surface where Pattern 2 either works or collapses.

When Pattern 2 lands, the trust boundary has moved. "Did a human verify each agent's output" is replaced by "is the substrate the agents reference independent of the agents themselves." Trust the substrate, not the peers.

Pattern 3 — Background routines move the trust boundary to policy enforcement at the gate

When agents run continuously without you, the question "did anyone check this?" is replaced by "did the gate enforce the policy?" An autonomous routine that patches a dependency, refactors a service, or queues a PR is, by design, accountable only to the constraints it cannot override.

Two recent disclosures expose how brittle this gets without hard constraints. On 2026-05-13, Akamai disclosed three MCP database-server vulnerabilities; Alibaba Cloud's RDS MCP response was "not applicable" for a fix. On 2026-05-03, MindsDB declined to patch CVE-2026-7712. Two confirmed instances of vendor-refusal-as-disclosure-failure-mode in three weeks. The coordinated-disclosure pipeline has no machine-readable "refused" status code. A continuous autonomous maintenance routine has no signal to act on. The dependency gets pulled, the patch gets queued, the verification gets run — and the trust boundary the operator thought they had is sitting in a private email between a researcher and a vendor.

Non-overridable hard constraints at the policy gate are what make Pattern 3 survive contact with this environment. The autonomous routine that pulls a new dependency must pass through a gate that asks: does this dependency violate a constraint the agent cannot rewrite, even if it "verified" the change?

When Pattern 3 lands, the trust boundary has moved. "Did a human approve each change" is replaced by "are the gate's hard constraints non-overridable, even by the agent itself."

The fourth pattern

Each of Bidasaria's three patterns is real. Each makes you faster. Each is necessary if agents are going to operate at scale.

But each relocates the trust boundary to a surface most teams have not built yet:

Pattern 1 moves it to the harness. Verify the harness.
Pattern 2 moves it to inter-agent attestation. Trust the substrate, not the peers.
Pattern 3 moves it to the gate. Enforce constraints the agent cannot override.

The talk says stop babysitting. The right question is: stop babysitting what? You can stop babysitting the keystrokes. You can stop babysitting the diff. You can stop babysitting the wall clock.

You cannot stop babysitting the trust boundary. You can only relocate it. The work has not disappeared; it moved into the verification infrastructure, the identity substrate, and the policy gate.

Operator prescriptions

For Pattern 1 (verification loops):

Build adversarial tests for the verifier itself, not just the code under test.
Specific surfaces: prompt-injection against the verification claim, checkpoint poisoning that survives self-verification, tool-output flips on PASS/FAIL.
Treat "Claude verified it" as untrusted until verified out-of-process.

For Pattern 2 (parallelization):

Out-of-band identity for cross-agent attestation: signed DIDs, evidence schemas that compose across providers.
Reference a substrate the agents do not control. The work being done in MCP, A2A, x402, and the OWASP Agentic Security Initiative is exactly this.
Treat agent-to-agent "I verified this" as the cluster pattern until anchored to identity.

For Pattern 3 (background routines):

Non-overridable hard constraints at the policy gate. The agent that wrote the constraint cannot rewrite it.
Audit log with bilateral co-signature (one party signs, another verifies on independent infrastructure).
Machine-readable "refused" status for vendor disclosure outcomes — pending standards-body work; until then, route around refusing-vendor surfaces explicitly.

The compounding effect

Stacked, the three patterns are powerful. Stacked with the fourth — verify the verifier, trust the substrate, enforce non-overridable constraints — they survive contact with the threat environment the talk does not mention.

Without the fourth, the three patterns are an attack surface multiplier. Each layer of automation removes a human-in-the-loop check while assuming the agents below it are honest. The CWE-502 cluster, the authority-laundering cluster, and the vendor-refusal pattern are not edge cases. They are the operational present.

Bidasaria's vision is correct. The babysitting can stop. But the relocation work has to happen first — and the engineering organizations that do that work before scaling agent fleets will be the ones whose automation survives the first adversarial contact.

Stop babysitting what? Stop babysitting the keystrokes. Keep babysitting the trust boundary. That is the actual work.

Saleme, Michael K. — ORCID 0009-0003-6736-1900

References: Sid Bidasaria, "Stop babysitting your agents," Code with Claude London, 2026-05-19. Open-source artifacts: agent-security-harness (470 adversarial tests across MCP, A2A, x402, L402) · constitutional-agent (six-gate governance with 12 hard constraints).

May 2026: The MCP Attack Surface Tripled — Three Disclosures and a Bank's SEC Filing Tell You What to Test

Michael "Mike" K. Saleme — Fri, 15 May 2026 16:46:50 +0000

In the past two weeks, four publicly-documented events made the AI agent attack surface concrete in a way vendor marketing usually obscures. They share a single structural property: the agent's trust model is wrong, and the consequences are now measurable.

The exposure count tripled in nine months

Trend Micro's 2026-04-28 update on exposed MCP servers reports the population grew from 492 (July 2025) to 1,467 — a near-tripling over nine months. Seventy-four percent are hosted on AWS, Azure, GCP, or Oracle. Per Trend Micro, exposed MCP servers "have become powerful vectors for cloud attacks, enabling threat actors to not only access sensitive data but also take control of the cloud services themselves."

The attack chain is mundane and operationally serious. A command-injection bug in a community-maintained MCP server like aws-mcp-server (CVE-2026-5058, CVSS 9.8) lets an attacker execute as the EC2 instance the MCP process runs on. That process queries the EC2 instance metadata service for the role's temporary credentials. From there: S3, DynamoDB, Lambda, IAM user creation, EC2 launches for persistence. Classic IMDS credential theft via a new entry point, not novel cloud-attack tradecraft.

The structural fact is that MCP servers were designed for localhost/stdio and got bound to 0.0.0.0 over a deprecated SSE transport because that's what "make it work over HTTP" looked like to the people deploying them.

Three database-wrapper MCPs, one structural failure mode

On 2026-05-13, Akamai researcher Tomer Peled disclosed three vulnerabilities in MCP servers that wrap analytical databases. The pattern is consistent across all three.

Apache Doris MCP (CVE-2025-66335). The exec_query tool wraps a SQL execution surface. The db_name parameter is unsanitized; a downstream SQL validator only inspects the first portion of the constructed query and therefore sees only the attacker-controlled prefix. Patched in doris-mcp-server 0.6.1.

StarTree mcp-pinot (issue #90, unpatched at disclosure). Verbatim from Peled's filing: "By default the server is binding to 0.0.0.0 and OAuth is off by default." The read_query tool's validation is one line — if not query.strip().upper().startswith("SELECT"): raise ValueError(...) — trivially bypassed via UNION, stacked queries, or comments. StarTree later added OAuth-over-HTTP, but the SQLi in read_query remains.

Alibaba Cloud RDS MCP (no CVE). Unauthenticated access to the RAG retrieval tool. Alibaba classified the issue as "not applicable" for a fix.

All three share one failure mode: the MCP tool wraps a SQL-execution surface and inherits the trust model of the AI agent instead of the database. The validator-as-theatre pattern (Doris), the transport-without-auth pattern (Pinot), and the RAG-as-side-door pattern (Alibaba) are different surface manifestations of the same trust-boundary error.

Sandbox isolation as a checkbox

CVE-2026-42302, disclosed 2026-05-08, is the cleanest single-CVE artifact of the month. FastGPT's agent-sandbox entrypoint.sh launches code-server with --auth none bound to 0.0.0.0:8080. Any network-reachable attacker gets unauthenticated remote code execution. CVSS 9.8. Affects FastGPT 4.14.10–4.14.12, patched in 4.14.13 (GHSA-34rc-438g-7w78).

The sandbox component existed because someone designed isolation into the product. The --auth none flag was a deployment choice that nullified it. Sandbox-as-checkbox is not isolation.

The shadow-AI class shows up on Form 8-K

On 2026-05-12, The Register reported that a US commercial bank self-disclosed to the SEC: employees fed customer data — including Social Security Numbers — into an unauthorized third-party AI application, outside the bank's approved systems.

Notice what this isn't. It isn't a framework CVE. It isn't a misconfigured MCP server. It isn't a sandbox that lost its --auth. The agent attack surface here is the absence of a sanctioned alternative — employees route work to an unapproved tool because the sanctioned path is slower than the deadline.

The bank's disclosure puts shadow AI in the regulatory record. That's the first thing about the SEC filing that matters. The second thing is that it forces every CISO of a federally-regulated firm to assume the same path exists in their org.

What this means for any operator

Across all four events, three things are simultaneously true:

The agent's trust model is wrong. MCP servers inherit the agent's authority, not the database's; agent sandboxes inherit the deployer's network config, not the threat model; shadow-AI tools inherit the employee's session credentials.
Vendor responsibility is asymmetric. Doris shipped a patch in master in December 2025. StarTree fixed half the problem. Alibaba returned "not applicable." When the same class of vulnerability is a CVE for an open-source ASF project and out-of-scope for a hyperscaler SKU, operators absorb the asymmetry.
The detection surfaces don't compose yet. Endpoint probing catches handler-side bugs. Chain reading catches declaration-versus-behavior drift. DLP catches employee exfiltration. None of those tools see the others' artifacts.

What to test now

For the MCP class:

Probe every MCP tool that wraps a SQL surface for parameter injection (Doris pattern, Pinot pattern).
Test whether tool registration accepts admin overrides without authentication (Alibaba pattern).
Audit deployment scripts for --auth none, 0.0.0.0 binds, and SSE transport (FastGPT pattern, Trend Micro at scale).

For the governance class:

Inventory unapproved AI tools your workforce already uses. The number is non-zero.
Map each sanctioned tool to a maximum data-class permitted; refuse SSN/PHI/PCI exposure on tools that aren't certified for it.
Treat shadow AI as a sanctioned-alternative gap, not a discipline failure.

Identify and revoke

When a managed-plane vendor declares unauthenticated access to a RAG retrieval tool "not applicable," the operator response isn't to rotate credentials. There is nothing to rotate. The response is to identify which agent workflows route through that surface and revoke the trust the workflow assumed it had — until the vendor's posture changes or the workflow migrates.

When an employee posts customer SSNs to an unapproved AI app, the response isn't to retrain the employee. The trust boundary the employee bypassed was tooling-shaped, not training-shaped. The response is to identify the gap in the sanctioned toolset and close it — and revoke the workforce's reliance on a tool the firm cannot audit.

MCP database servers ship the database's blast radius with the agent's trust model. The four events of the past two weeks make that fact citable.

Saleme, Michael K. — ORCID 0009-0003-6736-1900

Open-source artifacts referenced: agent-security-harness (github.com/msaleme/red-team-blue-team-agent-fabric, 470 tests covering MCP, A2A, x402, L402 — direct mappings: MCP-001, MCP-003, MCP-010, MCP-015, MCP-016, CREW-001, CREW-010, AUTH-001, DATA-001, DATA-003, IR-007). constitutional-agent (github.com/CognitiveThoughtEngine/constitutional-agent-governance, HC-6, HC-12, GovernanceGate, EpistemicGate).

When prompts become shells: the tool registry is the attack surface

Michael "Mike" K. Saleme — Sun, 10 May 2026 16:00:00 +0000

On May 7, 2026, Microsoft published "When Prompts Become Shells: RCE vulnerabilities in AI agent frameworks" — a retrospective on two Critical (9.9) CVEs in Semantic Kernel that landed in February and were patched within days.

The CVEs are bad. The framing is worse — and worth reading carefully.

The two CVEs

CVE-2026-26030 — `eval()` on attacker-controlled filter strings

InMemoryVectorStore accepts user-supplied filter expressions and evaluates them. Filter strings are interpolated into a Python expression and executed via eval():

expr = f"' or {user_filter} or '"
result = eval(expr, {"__builtins__": {}}, {})

An AST blocklist exists. It enumerates dangerous node types: Import, Call to known names, attribute access on a denylist. The blocklist was bypassable through undocumented attribute traversal — __name__, load_module, BuiltinImporter — none of which the filter explicitly denied. From there the attacker reaches os.system through the importer machinery without ever hitting an Import node.

Patched: semantic-kernel Python 1.39.4. Three external researchers credited.

CVE-2026-25592 — `DownloadFileAsync` exposed as a kernel function

In SessionsPythonPlugin, the DownloadFileAsync method was decorated with [KernelFunction]. That single attribute makes a function callable by the LLM as a tool. The method accepts a localFilePath parameter with no canonicalization, no directory allowlist, no validation of any kind.

[KernelFunction]
public async Task DownloadFileAsync(string remoteUrl, string localFilePath)
{
    // No path validation. No scope check. No allowlist.
    await File.WriteAllBytesAsync(localFilePath, content);
}

A prompt that gets the agent to call this tool with localFilePath = "C:\\Windows\\Start Menu\\Programs\\Startup\\malware.exe" writes a file that executes on the next user login. Sandbox escape, host-level persistence, in one tool call.

Patched: Microsoft.SemanticKernel.Plugins.Core 1.71.0. Same three researchers.

Microsoft's load-bearing line

"Vulnerabilities in the AI layer are no longer just a content issue and are an execution risk... because these frameworks act as a ubiquitous foundational layer, a single vulnerability in how they map AI model outputs to system tools carries systemic risk."

That's not throwaway language. They're naming a class.

A registered tool that wraps eval() turns prompt injection into a syscall.

Every agent framework has a tool registry. Every registry maps LLM-generated strings to functions. If any registered function wraps a dangerous primitive — eval, exec, Download*, raw filesystem write — prompt injection is no longer a content problem. It's a scope problem.

What runtime testing catches

Most agent security tools — including the harness I work on (msaleme/red-team-blue-team-agent-fabric) — operate at runtime. They send adversarial prompts, observe what the agent does, and flag deviations from declared behavior. Several tests in that suite map directly to these CVEs:

MCP-010: injects path traversal, template injection, and command substitution payloads into tool call arguments. Catches the DownloadFileAsync exploit if you've already invoked the tool.
SS-002: scans declared permissions against actual code, fails when exec:none is declared but eval() appears in the body. Catches CVE-26030's pattern if a permission declaration exists.
SS-007: enforces sandboxing tiers — a tool wrapping filesystem-write should be Tier-1, never auto-promoted to Tier-3.

Each is useful. None is sufficient.

What runtime testing misses

The upstream cause of both CVEs is structural: a function that could call eval() was registered as a tool. A function that could write any path was decorated with [KernelFunction]. The vulnerability existed at registration time, not at invocation time.

Runtime probes can't see this. They observe the symptom — a bad call happens — and report it after the fact. They don't enumerate the framework's tool registry at load time and traverse the call graph of each registered callable looking for dangerous primitives.

That gap is closer to a Semgrep-over-the-tool-registry rule than a runtime test. Roughly:

rules:
  - id: kernel-function-wraps-dangerous-primitive
    pattern-either:
      - patterns:
          - pattern-inside: |
              [KernelFunction]
              ... $METHOD(...) { ... }
          - pattern-either:
              - pattern: eval(...)
              - pattern: exec(...)
              - pattern: subprocess.$ANY(...)
              - pattern: File.WriteAllBytesAsync(...)
              - pattern: File.WriteAllText(...)
      - patterns:
          - pattern-inside: |
              @kernel_function
              def $METHOD(...): ...
          - pattern-either:
              - pattern: eval(...)
              - pattern: exec(...)
              - pattern: __import__(...)
    message: |
      Function registered as an LLM-callable tool wraps a dangerous primitive.
      The LLM can now invoke this primitive with attacker-influenced arguments.
    severity: ERROR
    languages: [python, csharp]

That rule would have flagged both CVEs in CI before they reached production.

The harder version of this problem is transitive: a registered tool that calls a helper that calls eval(). That requires whole-program analysis. But the first-order cases — direct calls inside the function body — are catchable with the same tooling teams already use for SQL injection and unsafe deserialization.

What I take away

The LLM is not a security boundary. Microsoft says this in their architectural recommendations and they're right. Treat every LLM-generated string as untrusted input at every system call.

The tool registry is the trust boundary. Whether a function is callable by the model is a security decision, not a developer-convenience decision. Every @tool / [KernelFunction] / register_tool() decorator is a capability grant.

Runtime tests catch what registration audits should have caught upstream. Both layers are necessary. Neither is sufficient on its own.

I'm interested in how teams are currently auditing this — whether at PR-time as a Semgrep rule, at registration time as a runtime check, or trust-on-load with downstream gating. Drop a note in the comments if your stack does any of these.

Full test mappings (SS-002, SS-007, MCP-010, MCP-001, HC-5, HC-6, RiskGate) and the cross-link to the constitutional governance layer (CognitiveThoughtEngine/constitutional-agent-governance) are in the GitHub Discussion.

When a protocol vendor declines to patch, the test harness becomes the spec

Michael "Mike" K. Saleme — Sat, 02 May 2026 13:16:13 +0000

When a protocol vendor confirms that a critical vulnerability is intentional, the question shifts from "when does the vendor patch this?" to "where does mitigation live now?"

The answer in this case is no longer in the protocol layer, no longer in the vendor SDK, but in the harnesses, sandboxes, and runtime guards that sit between the protocol and the host.

That is the news this week.

The pattern

Vendor-confirmed by-design vulnerabilities are not new. They are a recurring class. The shape repeats: a vendor ships a primitive, the security community discloses a flaw, the vendor reviews, and instead of patching, declares the flaw intentional. The protocol becomes a constraint, not a contract. Mitigation moves downstream.

When this happens, the question for enterprise security teams is no longer "what version do we update to?" The question is: which downstream layer enforces what the protocol does not? And how do we test that downstream layer, since the protocol itself has become a published constraint rather than a fixable bug?

This is the layer where adversarial test harnesses become load-bearing. They stop being "nice-to-have" pre-deployment checks and start being the actual specification for how the protocol is allowed to behave in production.

The proof point: Anthropic's MCP STDIO execution model

This week, Anthropic confirmed that a critical vulnerability in the Model Context Protocol's STDIO transport layer is intentional. Researchers had disclosed a systemic by-design weakness affecting the STDIO command execution path: the protocol passes configuration directly to command execution, and any unsanitized argument lands in argv of a spawned process. Across more than 7,000 publicly accessible MCP servers and 150 million SDK downloads, the affected behavior is identical because the SDK ships the same primitive in Python, TypeScript, Java, and Rust.

Anthropic's response declined a protocol-level fix. The position: the STDIO execution model represents a secure default, and sanitization is the developer's responsibility.

Translation for enterprise readers: the protocol is not going to defend you. Anthropic has documented the contract; the contract says you are responsible for what happens at process spawn. JPMorganChase, Citi, and BNY have all said they are building agentic AI on MCP. Their security teams now have an explicit, vendor-confirmed design constraint to work around — not a patch to wait for.

The 18-day gap

Adversarial testing for this attack class shipped April 12, 2026, in the agent-security-harness v4.2.0 release. Public CHANGELOG entry, public Git tag, public PyPI artifact. The tests target exactly the path Anthropic now confirms is by-design: MCP-015 and MCP-016 cover SSRF and STDIO pre-handshake injection patterns; MCP-017 extends to the configuration-to-command surface; MCP-018 (added April 17) covers unbounded request body DoS in the same execution path.

The disclosure cycle hit April 30. The harness coverage preceded the disclosure by 18 days.

That is not a prediction; it is a test record. Adversarial coverage of a known-weak primitive doesn't require advance vendor notice. It requires a willingness to systematically test what the protocol allows rather than what it documents.

What the tests actually do

The harness sends crafted MCP requests against a target server and analyzes the responses. The tests do not exploit the target; they probe whether the target's defensive controls — sandbox boundaries, capability allowlists, syscall filters, audit logging — fire when given input designed to trigger the by-design path.

Concrete examples:

MCP-015 sends a tool call where the configured command resolves through argv[0] interpretation that the documented allowlist accepted. The probe checks whether the target intercepts at the process-spawn layer.
MCP-016 sends a STDIO pre-handshake message that exercises the configuration-load path before the protocol's own handshake completes. The probe checks whether the target's sandbox has been activated by then.
MCP-017 sends a configuration argument structured to invoke the spawned process with input that would clearly fail the contract Anthropic now points developers at as their responsibility.
MCP-018 sends an unbounded request body to the same path, checking whether the target's body-size limits engage before the spawn.

A target that passes these probes has implemented the runtime guarantees the protocol no longer claims. A target that fails them is shipping the by-design path with no downstream mitigation. The pass-or-fail outcome is the operationalized form of Anthropic's "sanitization is the developer's responsibility" — except now the developer can measure whether they did it.

What the right mitigation looks like

When the protocol layer declines to enforce, three downstream layers can:

Capability declarations. The MCP server descriptor publishes the filesystem paths and network destinations it actually needs. The host enforces against the declared capability set, not against a binary name. This is a static contract, not a moving allowlist. Allowlist policies that don't constrain argv are checking the cover of the book; capability declarations describe the lambda the interpreter is allowed to evaluate.

Syscall-layer enforcement. seccomp on Linux, sandbox-exec on macOS, AppArmor/SELinux profiles. The kernel blocks the process from reaching what it shouldn't reach, regardless of which interpreter the protocol spawned. This is the only layer where the boundary is durable; everything above it is configuration.

Pre-execution verification. Before a process spawns, a sidecar verifies the configuration against the declared capability set and a signed policy reference. If the configuration drifts from the policy, the spawn doesn't happen. This is the layer where adversarial testing harnesses operationalize: the harness sends inputs that should fail pre-execution verification and measures whether they do.

The architectural through-line: protocol layer publishes the contract, capability layer translates the contract into a constraint, syscall layer enforces the constraint, harness measures whether enforcement is real. When the protocol layer publishes "responsibility is downstream," the only valid response is to make the downstream verifiable.

What this means for enterprise readers

Two questions to ask your platform team this week:

What does the harness say about your MCP servers? Not "do you have a scanner running" — what does adversarial test output show? If the answer is "we don't run adversarial tests," the protocol's by-design admission has just made that the highest-priority gap on your agent-stack roadmap.
Where is the syscall-layer enforcement? If your MCP servers run with the host process's filesystem and network access, the protocol's by-design path has full reach. The mitigation is not better allowlists; it is a kernel-level boundary that does not depend on the protocol behaving correctly.

The harness's MCP module is open source and Apache 2.0; pip-installable; runnable against any MCP server with a URL. That is not a marketing line — it is the structural reason the April 12 timestamp matters. The 18-day lead is real because the tooling shipped publicly, with a CHANGELOG entry and a Git tag, before the disclosure cycle. There is no proprietary version to license, no vendor relationship to maintain, no support contract to wait on.

The signature

When a protocol vendor declines to fix a critical flaw, the test harness becomes the spec.

Anthropic's by-design admission this week shifts MCP mitigation from the protocol layer to the runtime layer. The runtime is where attackers already are. The harness is where defenders measure whether the runtime is doing its job.

The April 12 release timestamp is documentation that the measurement has been available. The next 18 weeks will determine whether enterprise teams pick it up or wait for vendor-bundled scanners that ship the same coverage with a six-month delay.

The lead is real. It is also short. Test what the protocol no longer protects.

The agent-security-harness is open source under Apache 2.0. The MCP module documentation is at github.com/msaleme/red-team-blue-team-agent-fabric; the test catalog at docs/TEST-INVENTORY.md.