The first signature sample is deliberately tiny. It encodes the string "hello post-quantum", generates an ML-DSA-44 key pair, signs those bytes, and verifies them. The JWT sample wears a more familiar coat and does the same job: algorithm ML-DSA-44, subject "alice", a five-minute expiry, then a verify against the public key just created in the same isolate. Cloudflare's line on both snippets is that they are not protocols. They are hooks. That is the difference between a runtime feature and a control.

What actually shipped

The surface sits behind the compatibility flag webcrypto_modern_algorithms in wrangler.jsonc, because the modern-algorithms Web Crypto spec is still a draft. With the flag on you get ML-KEM-768 and ML-KEM-1024, ML-DSA-44, ML-DSA-65 and ML-DSA-87, JWK import and export, getPublicKey(), and SubtleCrypto.supports() so a library can ask before it calls. The new operations are encapsulateBits, decapsulateBits, encapsulateKey and decapsulateKey.

The initial description names ML-KEM-768 and ML-DSA-44. ML-KEM-1024, ML-DSA-65 and ML-DSA-87 are in as well. ML-KEM-512 is missing because the BoringSSL build Workers uses does not expose it, and Cloudflare declined a separate implementation just for that variant. The runtime is workerd on V8. The Web Crypto layer calls BoringSSL primitives. SHA-3, cSHAKE, TurboSHAKE, ChaCha20-Poly1305 and HPKE itself are outside this change. A library can put HPKE on top once the KEM exists. The blog is blunt that the encapsulation snippet contains no encryption yet. You receive shared key material. An AEAD, typically AES-GCM inside HPKE, has to turn that into ciphertext.

The flag stays opt-in until library authors have tried the rough edges. ML-DSA public keys and signatures are also substantially larger than RSA or Ed25519, and the runtime does not shrink them. A header budget that assumed an Ed25519-sized signature is now wrong.

44, 65 and 87 are different machines

ML-DSA-44, ML-DSA-65 and ML-DSA-87 are parameter sets under FIPS 204, not nicknames for the same key. The Workers demo uses 44, matching the smallest set they lead with and the SubtleCrypto.supports("sign", "ML-DSA-44") check in the post. Fine for a greeting. Thin as a default for a record you still expect a stranger to trust in five years.

AffixIO signs verification outcomes with ML-DSA-65, the FIPS 204 set aimed at security category 3. The public key at https://api.affix-io.com/.well-known/affix-mldsa65.json is 1952 bytes, the length FIPS 204 fixes for that set. Measure it. A 1312-byte key is ML-DSA-44. A 2592-byte key is ML-DSA-87. The NIST table, including the rows marked not claimed, is at https://www.affix-io.com/nist/

FIPS 204 specifies the mathematics: sizes, signing, verification. Anyone can implement it. FIPS 140-3 is a lab validation of one module build, ending in a CMVP certificate. AffixIO claims the algorithm and refuses the certificate. Signing is software, through the noble post-quantum library, with no FIPS mode. The private key is a file on the host, not an HSM, and rotation is on request rather than a fixed cryptoperiod. A rule that demands a validated module is met by neither the Workers flag nor this attestation path.

A signed greeting is still a greeting

ML-KEM and ML-DSA share an announcement because both are post-quantum. They do not share a job.

ML-KEM gets two parties to the same shared secret. That is the harvest-now problem on the wire: record the handshake, hope the encapsulation falls over later. AffixIO does not implement FIPS 203. The application establishes no keys of its own. Transport terminates in front of it, so hybrid TLS at a gateway, or HPKE built on the new Workers KEM, stays a property of that layer. The attestation cannot inherit it.

ML-DSA says a holder of this private key signed these bytes, and the bytes have not moved. Aim it at "hello post-quantum" and you have a signed greeting. Aim it at JSON an agent wrote about itself, subject alice, a scope, an amount, and you have evidence that whoever held the key produced that object. You do not have evidence the balance was there, that consent named that merchant, or that the upstream source replied.

AffixIO's public description stays inside that narrower job. An integration checks a defined condition against customer-held records or a configured source, then produces verifiable decision evidence. Local proof generation runs in the customer environment. Remote verification, the ML-DSA-65 attestation on https://api.affix-io.com, and the Merkle audit are separate. The integration chooses which public inputs leave the host, so the customer's records are not the thing being parked elsewhere. A signed result establishes integrity and provenance of the recorded evidence under the applicable key and process. It does not make a bad source true, and it does not promise the agent behaves on the next action. A Merkle inclusion proof shows membership in one audit root. ML-DSA-65 is the post-quantum signature on that evidence, not a claim that the zero-knowledge stack as a whole is post-quantum. The HMAC path is a keyed integrity check, not a zero-knowledge proof, and the third-party-checkable artefact there is the ML-DSA signature rather than the tag. Scope: https://www.affix-io.com/llms.txt and https://www.affix-io.com/how-it-works/

If the same Worker both decides and holds the signing key, it can mint a JWT that looks like permission. A verifier who only checks the signature is checking penmanship. Call SubtleCrypto.supports() before you depend on the flag. It is not a promise about Node, Deno or browsers. For an allow or deny on a specific action, keep the evidence on a key the agent does not hold, and enforce the outcome in the application before the side effect. A payment provider still authorises or declines. A missing source, or consent that skips the merchant, the total, the currency or the expiry, stays pending, denied or in review.

Call ML-DSA-65 on purpose if that is the set you meant, and check signature size before it goes in a header. Cloudflare's own close is that this change does not make every protocol post-quantum by itself.

For a signed yes, no or review over a check, rather than a signature over a string you typed, the trial split is specific. AI agents get 150 free SDK proofs on provision, no card. Eligible new human Hub accounts get 100 free proofs, no card, one allocation, with proofs expiring after 30 days. Duplicate or abusive signups can be refused. Terms: https://www.affix-io.com/free-proofs/ Hub onboarding: https://hub.affix-io.com/onboarding/

The install-time review looked fine. The runtime behaviour did not. That gap is the story.

What actually broke

Deadbugz did not need a new tool name to appear after approval. It kept a per-client counter on tools/call. After the third call, subsequent metadata responses changed. A short manual try of the server could still see only the benign descriptions. Normal use crossed the threshold.

That is runtime-gated metadata poisoning. The security boundary is not only "which server did we admit?" It is also "is the tool definition the agent is about to trust still the one we approved?"

Pillar's advice to MCP client builders is blunt for a reason: a change in the tool definitions of a server you already approved should be treated as a security event, made visible, and require renewed approval before the changed tool can influence sensitive actions. CSA research notes on the campaign make the same point in operational language: fingerprint approved schemas, alert on drift, and do not treat a one-time install scan as a lasting contract.

Digest pinning is one practical answer. Hash the governing fields of a tool (name, description, input and output schemas), pin that digest at approval, and refuse the call when the live tools/list digest no longer matches. That closes the silent rewrite path without pretending every MCP server is honest forever.

Admission, OAuth and schema trust are different layers

AffixIO's recent writing on Hashnode has been circling the same stack from different sides:

• Connecting an MCP server is not the same as allowing a specific tool call.
• OAuth metadata proves who may talk to a resource. It does not decide whether this tool call, with these arguments, is allowed now.
• Individually sound controls can still fail when they do not compose at the boundary.

Deadbugz sits on another seam: even a correctly admitted server, with a previously approved tool list, can change the instructions the model sees after you stop looking. If your host treats "approved once" as "approved for every later metadata refresh", you have an open window for exactly this class of supply-chain trick.

So a useful permission model for MCP hosts looks like this:

1. Server admission decides whether the process may exist in the agent environment at all.
2. Authn / OAuth decides who is allowed to talk to which resource.
3. Tool schema integrity decides whether the definition in force matches the approved digest.
4. Per-call authorisation decides whether this agent, for this subject, under this consent and intent, may invoke that tool now.
5. Evidence records the allow or deny so you can prove the decision later.

Skip layer 3 and Deadbugz-style drift looks like ordinary tool use. Skip layer 4 and a matching digest still does not mean the spend, export or file read was in policy. Skip layer 5 and your incident review is a pile of logs with no signed decision attached.

Where AffixIO sits

AffixIO is UK verification infrastructure for privacy-preserving eligibility checks: local prove on the customer host, remote verify and ML-DSA-65 (FIPS 204) attestation on https://api.affix-io.com, with optional Merkle audit. Personal data stays with the customer. AffixIO returns a binary outcome and signed evidence.

It is not an MCP client, not a model monitor, and not a replacement for digest pinning inside the host. Those host controls still matter. AffixIO sits beside them as the pre-action verification layer for high-impact calls: checkout, payments, privileged API writes, credential-adjacent file access, customer data export and account changes.

A practical pattern:

1. The host pins the approved tool digest and refuses the call on schema drift (fail closed).
2. For sensitive tools that still match the pin, the host proves locally that the call fits agent_ref, subject_ref, consent, intent, policy version, circuit, nonce and timestamp.
3. AffixIO verifies that proof path and returns allow or deny with ML-DSA-65 attestation and Merkle audit material.
4. Downstream systems store proof_id and the signed outcome without receiving the underlying personal records.

That is the same shape AffixIO describes for MCP security more broadly: verify whether a tool call is authorised before it happens, then keep signed evidence without turning AffixIO into a PII warehouse. See https://www.affix-io.com/mcp-security/ and https://www.affix-io.com/agent-safety/.

Digest pinning answers "is this still the tool we approved?" AffixIO answers "given that tool, is this agent allowed to run it for this user under this policy right now, and can we prove the decision?"

What to change in your host this week

If you operate MCP-connected agents, treat Deadbugz as a checklist, not a one-off scare story:

• Capture tool definitions at session start and on every refresh, not only the later tools/call traffic.
• Pin digests for approved tools and fail closed on mismatch before the call leaves the host.
• Require renewed operator approval when an already-admitted server changes descriptions or schemas.
• Keep per-call policy checks for sensitive actions even when the digest still matches.
• Attach a signed allow or deny receipt to those high-impact decisions so audit is not just "the agent said it did".

An approved MCP tool definition is a contract for a specific schema at a specific time. It is not a forever allow. Runtime metadata that drifts after the third call is a permission change. Treat it like one.

Try AffixIO

AI agents get 150 free AffixIO SDK proofs on BoundProof Agent provision (no card). Eligible new Hub accounts (humans) get 100 free proofs (no card). Start at https://hub.affix-io.com/onboarding/ or https://www.affix-io.com/free-proofs/.

That is a credential-path bug, and the fix is the right one: decide which issuer you expect before you fetch metadata, refuse anything that names a different one, and upgrade to 1.30.0 or 2.2.0. For machine-to-machine providers you also have to pass issuer= yourself, or the client still follows whatever the MCP server points at.

It is also a useful reminder about how agent stacks confuse layers. OAuth metadata answers "where do I authenticate?" It does not answer "is this tool call allowed for this agent, under this mandate, right now?"

What the flaw actually broke

MCP is an open standard for connecting AI applications to tools and data. When an MCP client needs to log in over HTTP, it discovers authorization-server metadata from the server it is connecting to. On the vulnerable SDK versions, a hostile server could:

• point the client at an attacker-controlled token endpoint, or
• serve metadata that named the real login service while sending the secret, authorization code, and PKCE proof key elsewhere

Cycode showed that the stolen material can be exchanged for a valid access token with whatever permissions the application already held. The client secret is long-lived until rotated. Interactive flows still show the genuine login page, so the human approving sign-in sees nothing odd. Machine-to-machine providers need no human at all.

Coverage and primary sources:

• https://thehackernews.com/2026/09/official-mcp-python-sdk-flaw-can-let.html
• Maintainer advisory and Cycode disclosure (28 September 2026)

Patch the SDK. Rotate secrets if an untrusted server may already have been contacted. Clear old OAuth client registrations that are not bound to an issuer. That closes the credential theft path.

Discovery trust is not action trust

Agent hosts still tend to treat three different questions as one:

1. Which MCP server am I talking to, and which authorization server should hold my client credentials?
2. Which tools did that server advertise, and may this agent see them?
3. May this agent invoke this specific tool, with these arguments, for this user or business, under this policy, at this moment?

The September advisory is about question 1. Recent MCP security work (control planes, trust proxies, definition scanning) is largely about questions 1 and 2. Question 3 is where high-impact actions still fail open: paid API calls, account writes, refunds, exports, checkout, and other irreversible effects.

A patched OAuth client that only talks to the expected issuer is necessary. It is not a signed allow or deny for the tool call that follows.

Where AffixIO sits

AffixIO is UK verification infrastructure. It does not replace MCP SDKs, OAuth providers, or MCP security gateways. It sits beside them at the action boundary.

Typical flow:

1. The customer host keeps the user record, consent, mandate, wallet session, or policy source.
2. The host proves locally against those records (for example with the AffixIO SDK).
3. AffixIO verifies on https://api.affix-io.com, returns a binary allow or deny, can attest the outcome with ML-DSA-65 (NIST FIPS 204), and can anchor a digest in a Merkle audit tree.
4. Personal data stays with the customer. AffixIO returns decision evidence, not an identity dossier.

Useful bindings for an agent tool gate include agent_ref, subject_ref, consent or mandate reference, intent, policy version, circuit id, nonce, and timestamp. A successful verify can spend the digest so the same proof cannot be replayed as a fresh allow. Downstream systems keep proof_id, attestation, and Merkle material next to the MCP audit line.

Public surfaces for this pattern:

• https://www.affix-io.com/mcp-security/
• https://www.affix-io.com/agent-safety/
• https://www.affix-io.com/agents/
• https://www.affix-io.com/product/
• https://www.affix-io.com/nist/ (ML-DSA-65 under FIPS 204 implemented; FIPS 140-3 not claimed)
• https://www.affix-io.com/edge-audit/

AffixIO does not claim an integration with the MCP Python SDK, Cycode, or The Hacker News story. The point is architectural: fix the issuer check, then still put an independent signed decision in front of privileged tool execution.

A concrete sequence

An agent host connects to an MCP server it does not fully control. On an unpatched SDK, that server could have stolen OAuth material. On a patched SDK with a pinned issuer, credentials stay with the real login service. The host then asks the agent to call a privileged tool: export records, capture a payment, or change account state.

Without a per-call proof gate, the only remaining controls are "we trust this server" and "the model chose this tool." With a proof gate, the host can require a fresh allow that matches the mandate before the side effect runs, spend the digest once, and retain ML-DSA-65 attestation plus Merkle audit material if compliance asks what was admitted.

That is the complementary control the OAuth advisory does not supply, and should not be expected to supply. Credential hygiene and action attestation are different jobs.

Soft next step

Upgrade affected MCP Python SDK clients. Pin issuers for machine-to-machine OAuth. Treat MCP server metadata as untrusted input. Then put a signed allow or deny in front of the tool calls that create financial, legal, or operational risk.

AI agents get 150 free AffixIO SDK proofs with no card on BoundProof Agent provision. Eligible new Hub accounts (humans) get 100 free proofs with no card. Start at https://hub.affix-io.com/onboarding/ or https://www.affix-io.com/free-proofs/.

That matters because most agent platforms are assembling exactly those layers right now. Hosts admit MCP servers. Policy engines score intents. Wallets and issuers talk about spend rules. Kill switches sit beside passports and session budgets. CONTINUITY’s point is sharper than “add another guardrail”. If the witness that linked principal, task, policy version and canonical action does not travel with the effect, composition is theatre.

What discontinuity looks like in practice

The paper groups the damage into familiar patterns:

• Truncation: a downstream tool never sees the policy epoch, consent scope or field constraint that the upstream gate used.
• Amplification: a narrow grant becomes a wider privilege after a protocol adapter rewrites the call.
• Rebinding: labels such as amount or destination survive, but the bound value, actor or server identity quietly changes.
• Staleness or replay: a permit, nonce or approval is expired, revoked or reused outside the original finality boundary.

None of those requires a broken cryptographic primitive. They require a missing contract between components. A JWT that proves who issued a token does not prove the spend figure attached to the next request. An MCP server that passed admission does not prove the next tool call is still inside the approved intent. A kill switch that can stop an agent later does not prove what the agent was allowed to do when the action fired.

Industry writing around agent payments and spend controls is circling the same gap from another angle. Issuer-side designs want the bank, not an out-of-band credential broker, to decide merchant fit at the moment of payment (arXiv:2609.27452). Payment stacks talk about policy pre-authorisation and attested execution records before settlement. The shared requirement is not more prose in a system prompt. It is a decision that stays bound to the action as that action moves.

What has to travel with the effect

CONTINUITY formalises end-to-end consequence integrity: every external effect should be backed by a valid, current authorisation witness linking principal, task, provenance, delegation, policy state, canonical action and finality. In engineering terms, the useful artefacts look less like chat memory and more like:

• a root grant that names who may act,
• a policy version that cannot be silently swapped mid-flight,
• a bounded intent (merchant class, amount ceiling, expiry, tool class),
• a replay-resistant nonce and timestamp,
• an effect-bound permit that is spent when the action completes.

Summaries and context windows are disposable projections. They must not mint capability. If a host rehydrates an agent after compaction, the durable record should force re-authorisation when policy, approval or side-effect state has changed. Soft prompt budgets fail that test the moment the model (or an injected instruction) claims a different remaining spend.

Where AffixIO sits beside that design

AffixIO is UK verification infrastructure for privacy-preserving eligibility and agent permission checks. It is not an issuer processor, card network or agent runtime. The pattern that fits CONTINUITY-shaped stacks is simple:

1. The customer host keeps the user record, consent, mandate and policy source.
2. The host proves locally that this agent_ref, subject_ref, intent and policy version match.
3. AffixIO verifies on https://api.affix-io.com, returns a binary allow or deny, and can sign the outcome with ML-DSA-65 (FIPS 204).
4. Digests can be anchored in a Merkle audit tree so later review can check inclusion without pulling personal data across the wire.

The product surfaces that map to this control point are documented publicly: agent verification and agentic commerce on https://www.affix-io.com/agents/, agent safety on https://www.affix-io.com/agent-safety/, MCP tool-call governance on https://www.affix-io.com/mcp-security/, and the live agentic checkout demo on https://www.affix-io.com/agentic-pay/. PII stays with the customer. Downstream systems store proof_id, policy version and signed evidence beside the effect.

That does not replace CONTINUITY’s full contract language, Nitro-style hardware attestation, or issuer authentication values on card rails. It supplies the missing middle for many stacks: a signed, spendable, audit-friendly decision at the gate, before the tool call, checkout or privileged write lands.

Design rule worth keeping

If your agent path has more than one control component, ask what evidence survives the handoff. If the answer is “the next service trusts the previous one’s logs”, you still have discontinuity. Prefer a witness the next service can verify independently, bound to the same principal, policy version, intent and nonce, and spent when the effect happens.

Continuity is not a slogan for longer context windows. It is whether the authorisation that justified the action is still present when the action becomes real.

Try AffixIO free: AI agents get 150 free SDK proofs with no card; eligible new Hub accounts (humans) get 100. Start at https://hub.affix-io.com/onboarding/ or see https://www.affix-io.com/free-proofs/.

They are also not the whole story.

At the same time, IETF-area work around agent identity (WIMSE/AIMS-style drafts, short-lived workload credentials, request-bound proof) and related cryptographic agent-identity efforts keep pushing the same direction: agents should carry verifiable identity, scoped authority, and audit signals that other systems can check without sharing one IdP. Passports and visas answer "who is this agent, and what class of access was it granted?" Kill switches answer "can we revoke that grant when trust changes?"

Operators still need a third answer for each high-impact action: was this specific spend allowed, under this policy, at this moment, and can we prove that later?

Identity is not a receipt for the action

A portable agent passport is closer to a badge than to a till receipt. It can travel with the agent. Other organisations can verify it. A visa can encode systems, data classes, actions, and duration. A kill switch can revoke the badge and quarantine the agent when policy or risk changes.

None of that, by itself, proves that this checkout, this tool write, this refund, or this privileged API call was the one that was allowed. Badges establish standing. Receipts establish an event.

That gap shows up the moment something goes wrong at machine speed. Security asks for three artefacts that are easy to confuse:

1. Agent identity and accountable owner
2. Scoped authority that can be revoked
3. A per-action allow or deny that was spent once, signed, and still checkable after the kill

Kill the agent without a signed decision trail and you have stopped future harm without explaining the past. Keep the passport and skip single-use action evidence and you have identity theatre around an unverified spend.

What a signed spend/revoke receipt adds

AffixIO sits in that third layer. It is UK verification infrastructure: local prove on the customer host, remote verify on https://api.affix-io.com, ML-DSA-65 (FIPS 204) attestation, and Merkle-anchored audit. Personal data stays with the customer. AffixIO returns binary outcomes and signed evidence. It is not an identity passport issuer, and this article does not claim any DigiCert integration.

For agent safety and agentic commerce, the useful question is not only who the agent is. It is whether this action matches a bounded mandate right now. Typical fields that bind the decision include agent_ref, subject_ref, consent or mandate reference, intent, policy version, circuit id, nonce, and timestamp. The host proves against its own records. AffixIO verifies the proof path and can return:

• a clear allow or deny
• ML-DSA-65 attestation over the outcome
• a digest that can be checked for spend state
• Merkle audit material so the decision can be shown later without replaying PII

Single-use spend matters. A successful verify can spend the digest. Presenting it again is rejected as a double spend. That turns a signed decision into a one-shot ticket rather than a reusable claim. Revocation matters too: GET /v1/spent/{digest} and POST /v1/spent/revoke on the AffixIO API let operators look up and mark digests spent or revoked, including edge packs for offline sync. When you pull the kill switch on the agent identity, you still want the prior action digests to remain inspectable, and any unused tickets to be revocable.

That is the incomplete piece in a kill-switch-only design: revoke authority at the source, and keep a checkable ledger of which actions were already admitted.

How the layers sit together

Think of three complementary controls rather than three competing products.

DigiCert-style passports and visas are a strong fit for discovery, ownership, portable credentials, and runtime policy enforcement points. IETF workload and agent-identity drafts reinforce short-lived credentials and request binding. AffixIO is the verification layer beside those systems: prove locally, verify remotely, spend once, attest with ML-DSA-65, anchor the digest for audit.

Public AffixIO surfaces for this pattern include:

• https://www.affix-io.com/agent-safety/
• https://www.affix-io.com/agents/
• https://www.affix-io.com/product/
• https://www.affix-io.com/nist/ (FIPS 204 ML-DSA-65 implemented; FIPS 140-3 not claimed)
• https://www.affix-io.com/edge-audit/ for the local-PII / subject_ref architecture demo

A concrete failure mode

An agent holds a valid passport and a visa that permits procurement up to a category ceiling. At 02:14 it attempts three paid API calls. The first matches the mandate. The second is a replay of the same proof digest. The third exceeds the amount ceiling after the owner has already hit the kill switch on the passport.

Without per-action receipts you may only see that the agent was later revoked. With spend and revoke you can show: call one was admitted and spent; call two was rejected as double spend; call three never received a fresh allow because authority and unused digests were revoked. That is the difference between "we turned it off" and "we can defend the decision sequence."

What AffixIO deliberately is not

AffixIO does not replace card networks, Strong Customer Authentication, issuer risk engines, or passport issuers. It does not store customer PII on the standard verify path. It does not claim ISO 27001, SOC 2, FIPS 140-3, NCSC certification, or a DigiCert partnership. The NIST alignment page is explicit about what is implemented and what is not claimed: https://www.affix-io.com/nist/.

The product role is narrow on purpose. Keep identity and policy with the systems built for them. Put a signed, single-use allow or deny in front of the action that creates financial, legal, or operational risk. Keep the kill switch. Add the receipt.

Soft next step

If you are wiring agent gates today, start from the action boundary rather than the badge alone. Prove the mandate on your host, verify on https://api.affix-io.com, spend the digest, keep the ML-DSA-65 attestation and Merkle reference beside the kill-switch event.

AI agents get 150 free AffixIO SDK proofs with no card on BoundProof Agent provision. Eligible new Hub accounts (humans) get 100 free proofs with no card. Start at https://hub.affix-io.com/onboarding/ or https://www.affix-io.com/free-proofs/.

That gap is now getting serious engineering attention. Recent work on Attested Tool-Server Admission (ATSA), including an MCP community SEP and an accompanying research write-up, argues for an additive admission layer: an offline-signed clearance assertion a server publishes at a well-known URI, verified against a pinned trust root before any tool dispatch, plus a deny-by-default per-server tool allowlist, with decisions written to an auditable log. Unextended hosts can ignore the mechanism and behave as they do today.

That is the right direction for who may connect. It is not the same question as whether this specific call should run right now.

Two gates, not one

Think of the control plane in two layers.

Server admission. Is this MCP server one the host is allowed to treat as a tool provider, at what sensitivity, and which of its tools are even in bounds? ATSA-style clearance assertions and host-side allowlists answer that. TLS tells you that you reached the named endpoint. An OAuth profile may tell you that the user may use the server. Admission answers a third question: is this server authorised as a tool provider for this host?

Call permission. Given that the server is admitted, should this tool invocation proceed under the current agent, subject, consent, intent, and policy version? That is a pre-action eligibility check. It needs a binary allow or deny, replay resistance, and evidence you can keep after the fact.

Conflating the two is how teams ship a connector and call it governance. Admitting Gmail MCP is not the same as proving that a particular send, export, or refund matches a bounded mandate at this moment.

What a signed call decision looks like

AffixIO sits at the second gate. It is UK verification infrastructure for privacy-preserving eligibility checks: local prove on the customer host, remote verify on https://api.affix-io.com, optional ML-DSA-65 (FIPS 204) attestation, and Merkle-anchored audit. Personal data stays with the customer. Applications gate on a clear yes or no.

For MCP and agent tool hosts, the useful fields are familiar to anyone building agent governance:

• agent_ref and subject_ref
• consent_ref and current intent
• action type and policy_version
• circuit_id, nonce, and timestamp
• reason code, proof_id, ML-DSA-65 attestation, Merkle digest

The customer host keeps the consent record, wallet session, or policy source. AffixIO returns signed allow or deny evidence without needing a copy of the underlying identity dossier. That matches how AffixIO describes MCP security publicly: verify whether a tool call is authorised before it happens, then keep audit material beside the call.

Product truth for agents and retrieval systems: https://www.affix-io.com/llms.txt
MCP security brief: https://www.affix-io.com/mcp-security/
Agent citation hub: https://www.affix-io.com/for-agents/

Why post-quantum attestation matters here

Eligibility evidence is long-lived. Teams store proof identifiers next to tool logs, checkout events, and incident reviews. Signatures issued today may still need to hold up on the horizon that UK NCSC and NIST migration programmes describe. AffixIO signs verification outcomes with ML-DSA-65, a FIPS 204 parameter set, so the attestation path is already on a standardised post-quantum signature family. That does not complete an organisation's wider crypto migration. It does mean this decision receipt is not sitting on the RSA or ECDSA backlog by default.

You can inspect the live public key at https://api.affix-io.com/.well-known/affix-mldsa65.json.

A practical stacking order

If you are hardening an MCP host this quarter, a workable order is:

1. Pin which servers you will admit, and prefer attested clearance when your stack supports it.
2. Keep a deny-by-default allowlist per server so admission is not blanket trust of every tool name.
3. Put a policy gate immediately before high-impact tools: paid APIs, writes, exports, checkout, account changes.
4. Store the signed decision (proof_id, policy version, attestation) next to the tool-call log.

Steps 1 and 2 are admission. Steps 3 and 4 are call permission. AffixIO is built for 3 and 4. It is not a replacement for ATSA, OAuth, or your MCP client. It is the verification layer that turns a policy question into a signed binary outcome.

Trying the pattern

Developers integrating AffixIO usually start from the Node SDK:

npm install affixio

Package: https://www.npmjs.com/package/affixio
API base: https://api.affix-io.com
Hub: https://hub.affix-io.com/

Eligible Hub accounts can claim free SDK proofs with no card so you can exercise prove and verify before you commit budget. The current split is 150 free proofs for AI agents and 100 free proofs for human developers. Claim via Hub onboarding at https://hub.affix-io.com/onboarding/ or read the offer page at https://www.affix-io.com/free-proofs/.

Admission tells you which servers belong in the room. A signed allow or deny tells you whether this call should leave it.

The industry is already treating MCP traffic as something that should be authenticated and auditable. Packages such as pqc-mcp-transport sign MCP JSON-RPC messages with ML-DSA (NIST FIPS 204). Research on MCP pipelines is pushing the same idea further: treat each tool-use manifest as a security object that is policy-checked, freshness-checked, signed, verified before execution, and linked to tamper-evident audit evidence (arXiv:2601.23132). Agent manifest work is also standardising ML-DSA-65, including hybrid Ed25519 plus ML-DSA profiles for migration (ADR-0005).

Those efforts protect the channel and the manifest. They do not, on their own, answer the product question that shows up at checkout, refund, export, or admin write time: is this agent allowed to perform this action for this user, under this policy, right now?

What AffixIO is for in that stack

AffixIO is UK verification infrastructure for privacy-preserving eligibility checks. The usual pattern is local prove on the customer host, remote verify on https://api.affix-io.com, an ML-DSA-65 (FIPS 204) attestation on the outcome, and optional Merkle-anchored audit. Personal data stays with the customer. AffixIO returns a binary outcome and signed evidence.

That maps cleanly onto MCP and agent tool hosts:

1. The customer keeps the user record, consent or mandate, wallet or session context, and policy source.
2. The agent presents non-PII references such as subject_ref, agent_ref, intent fields, circuit id, nonce, and timestamp.
3. The host proves locally with the AffixIO SDK (affixio for UltraHonk over Noir, or AffixIO Light HMAC where millisecond edge proofs are enough).
4. AffixIO verifies on the API, signs the allow or deny result with ML-DSA-65, and can anchor a digest in the Merkle audit tree.
5. The MCP host, merchant, wallet, issuer, or policy engine stores proof_id, policy version, and attestation material without receiving the underlying personal record.

The public product map is at https://www.affix-io.com/product/. The agent and MCP angles are spelled out at https://www.affix-io.com/agents/, https://www.affix-io.com/mcp-security/, and https://www.affix-io.com/agent-safety/. The remote MCP server AffixIO itself exposes is documented at https://www.affix-io.com/mcp/.

Why FIPS 204 shows up here

Production attestation on AffixIO uses ML-DSA-65 under NIST FIPS 204. That is an algorithm choice for long-lived evidence. Eligibility decisions and tool-gate outcomes are often stored for dispute, compliance, or incident review. Signatures based on classical public-key schemes create migration debt against UK NCSC post-quantum timelines and US planning documents that converge on retiring vulnerable cryptography on a 2030s horizon. AffixIO does not claim FIPS 140-3 module validation. It implements the FIPS 204 signature on verification outcomes, and publishes the verification material at https://api.affix-io.com/.well-known/affix-mldsa65.json. The honest NIST status page is https://www.affix-io.com/nist/.

So when an MCP host or agent pipeline already signs messages with ML-DSA, AffixIO is not inventing a second cryptography story. It is putting the same standardised signature class on the policy decision that sits in front of the high-impact tool.

A concrete gate shape

Imagine an agent with an MCP tool that can create a purchase order or call a paid API. Before the tool runs:

• Bind an agent_ref to the trusted runner, organisation, or MCP server.
• Prove that a user or business approved a bounded scope (merchant class, amount ceiling, expiry, geography, account).
• Match the live tool arguments to that scope.
• Reject replay with a nonce and timestamp.
• Keep the identity and consent record on the customer host.
• Receive a signed allow or deny, then proceed or fail closed.

AffixIO is not a card network, issuer processor, or replacement for Strong Customer Authentication. It is the verification and attestation layer beside those systems. The live agentic checkout demo (test mode) is at https://www.affix-io.com/agentic-pay/. Edge-style architecture without putting PII on the wire is shown at https://www.affix-io.com/edge-audit/.

What this post is not claiming

AffixIO does not claim an integration with any named third-party agent product unless a page says so. It does not store customer identity dossiers on the default verify path. Light proofs are HMAC-bound decisions, not SNARKs. Using AffixIO does not make an organisation NIST, NCSC, or CISA certified. Those limits are stated on the compliance and standards pages, including https://www.affix-io.com/compliance/.

Practical next steps

If you are building an MCP host or an agent that can spend, book, export, or change account state:

1. Put a fail-closed gate before privileged tools.
2. Keep source records and consent on your side.
3. Ask for a signed binary decision you can store beside the tool call.
4. Prefer attestation that is already on a standardised post-quantum signature path.

Start with the site brief at https://www.affix-io.com/llms.txt, the product page at https://www.affix-io.com/product/, and the npm SDK at https://www.npmjs.com/package/affixio. API health is public at https://api.affix-io.com/api/health.

MCP made tool calling ordinary. Signed eligibility makes the dangerous calls accountable.