DEV Community: Imran Siddique

My quickstart ends in FAIL, and that is the correct answer

Imran Siddique — Mon, 17 Aug 2026 22:30:20 +0000

If you run the cMCP quickstart on your laptop, the last command prints FAIL.

I want to explain that before you hit it, because the reflex is to assume the tutorial is broken. It is not. That output is the whole argument.

What the ten minutes actually do

pip install cmcp-runtime

MIT, on PyPI, no account, no sales call, no special hardware. You write a Cedar policy. You point an agent at a tool. You then fire an action your own policy forbids, something like a record with PII leaving on a call to Salesforce.

It returns 403 before the call is forwarded. Not after. Not logged and alerted on. The request does not reach the tool, and the decision is made at the boundary rather than inside the model that wanted to make the call. That distinction is the entire reason the project exists: a model may propose an action, but it cannot be the authority that permits it.

Then you finalise the session and get a TRACE claim, and you verify it yourself:

cmcp verify claim.json

The part I want you to look at

In dev mode the verifier prints something close to this:

schema: pass
signature: pass
policy bundle hash: pass
tool catalog hash: pass
attestation freshness: pass
audit chain integrity: pass
hardware attestation: fail

Overall result: FAIL (partially_verified).

Six checks pass. One cannot run, because your laptop has no TEE, so there is no hardware measurement to compare against. And the tool refuses to round that up.

It would be trivial to make this print VERIFIED with a footnote. Most things in this space do exactly that. I think it is the single most damaging habit in the category, because it teaches operators that a green result is a green result, and then a green result arrives one day from a system that measured nothing at all.

Unmeasured is not empty. A check that could not be performed and a check that passed are different facts, and any evidence format that collapses them is worse than no evidence, because it launders an absence into an assurance. If you take one thing from the quickstart, take that, and go look at whether your own pipeline can tell the difference.

Run the same claim on real TEE hardware and the last line passes and the overall result changes. Nothing else about the record changes. That is the point: the record is honest about its own coverage in both cases.

What I actually want from you

The happy path working is not interesting. I already know the happy path works.

What I want is the edges:

a policy that should have fired and did not
a record that does not reconcile against the policy bundle it claims
anything that behaves differently from what the spec says it does
a verification result you can argue is wrong in either direction, false pass or false fail

Find one and I will publish it with the fix, or with the open issue if there is no fix yet, and I will name you if you want the credit. I have written up limits in my own spec before and I would rather do it again than find out from a customer.

There is a real one already on the table, so I am not pretending the surface is clean: TRACE verifies against the issuer's own key, which means it detects later tampering well and says much less than it sounds about whether the issuer was honest at write time. Independent verification needs an anchor outside the issuer. That is unsolved, and it is not the only thing here that is.

Ten minutes. Then tell me what broke.

https://agentrust-io.com/quickstart/?source=devto-imran

One question if you want to answer only one: did it unblock something you cannot ship today?

Sovereign verifiability takes three layers. A2A just secured the foundation.

Imran Siddique — Mon, 17 Aug 2026 16:59:07 +0000

A2A is joining the Agentic AI Foundation. Mazin Gilbert announced it this morning and Ina Fried has the story at Axios. MCP defines how an agent reaches a tool. A2A defines how one agent hands a task to another and gets a result back. As of today both sit under the same open governance, with a steering committee that includes AWS, Cisco, Google, IBM Research, Microsoft, Salesforce, SAP and ServiceNow.

This is a genuinely good day, and I do not want to undersell it. An interoperable agent-to-agent transport under neutral governance is the precondition for everything I am going to describe below. Google could have kept it, and chose open governance instead. The teams who built A2A to v1 and the TSC now stewarding it have done the hard, unglamorous work that makes a layer everyone can build on.

We build on that layer. Agent Mesh and cA2A both assume A2A rather than replace it, in the same way our confidential MCP work assumed MCP. So this edition is about what we have been putting on top, why it is needed for sovereignty specifically, and what it still cannot do.

The short version: a sovereignty claim has to survive three layers, and the transport is only the ground it stands on.

Here is the test that shows why the layers above the transport have to exist.

A resource owner permits processing in France only. A lead agent delegates summarisation to a sub-agent. The sub-agent calls a model endpoint that is EU-branded but served from a region outside France.

Every component behaved as configured. The deployment was compliant. The data flow was not.

I wrote that as the acceptance test in an RFC last week, and I want to spend this edition on why it is hard, because it is the clearest example I know of the difference between a system that is governed and a system that says it is.

The project

Agent mesh is the part of the Agent Governance Toolkit that handles what happens when agents stop working alone. One agent hands work to another. That one hands part of it onward. The toolkit is at roughly 5,900 stars and 1,000 forks, and most of the interest I get on it now is about this layer rather than the single-agent one.

The reason is that the second hop is where most governance quietly stops working.

Everything you established about the first agent was established about the first agent. Its identity. Its policy. Its permitted region. The moment it delegates, you are relying on those properties surviving a transfer, and in most systems today nothing carries them across. The sub-agent inherits a task. It does not inherit the constraints under which the task was authorised.

Declared is not verified

Residency is the sharpest version of this because it looks solved and is not.

The way it is modelled today, in the toolkit and nearly everywhere else, is as declared metadata. A policy carries a list of processing regions. An agent’s claims carry a data residency field. Both are strings that somebody typed.

A declared region string is unverifiable. Nothing binds it to evidence, and nothing carries it across more than one hop. So an agent can satisfy every check the design specifies and still route data out of its permitted jurisdiction through a sub-agent, with no record that it happened.

I want to be precise about why that is worse than having nothing. An unverifiable residency claim creates documented, auditable confidence in a property nobody checked. You end up with a compliance artifact that is exactly as strong as the honesty of whoever filled in the field, presented with the visual authority of a control.

The two properties that matter here are easy to state and hard to build:

Residency is only meaningful if it survives delegation. A constraint that applies to the first agent and evaporates at the first handoff is not a constraint, it is a label on the front door.

Delegation is only safe if residency composes. Across a chain, a constraint has to intersect at every hop and must never widen. The child can hold less than the parent. It can never hold more.

The same monotonicity already gets enforced for capabilities in a lot of systems. Almost nobody enforces it for geography.

Why detection does not close this

The cheaper answer is to check afterwards, and it is where most of the industry sits.

The best published agentic attack detector I am aware of is Uber’s ADR, which reports catching 67% of attacks at zero false positives on its own benchmark. That is genuinely state of the art and it still misses roughly one in three.

A residency violation caught 67% of the time is not a control a regulator will accept. Detection and evidence compose. Neither substitutes for the other, and a system that only detects is a system that finds out.

What cA2A is for

This is the project I have never written about here, which is an odd gap given that it exists for exactly the problem above.

A2A makes a deliberate and, I think, correct design choice: it specifies the transport and the Agent Card, and it leaves the runtime credential layer to implementers. A transport should not be in the attestation business. Putting hardware attestation into a wire protocol would have made it heavier, slower to adopt, and wrong for the majority of deployments that do not need it.

That choice is what creates the space we work in. The common answers implementers reach for are mTLS and OAuth scopes, which secure the pipe and assert an identity. They are the right default. They do not attenuate authority across a chain, attest runtime integrity, or seal a payload to a measurement, because they were never meant to.

cA2A is a confidential profile that fills that slot, the same way our confidential MCP work sat on top of MCP rather than beside it. It composes four things:

Attenuated delegation, where each hop’s scope is a provable subset of its parent. Runtime attestation, so a peer proves it is running measured code before it is trusted with a task. A sealed channel, so the payload is readable only inside the verified peer. And a provenance record per hop, chaining into a graph a third party can verify offline without trusting either operator.

The refusal path ships as an example in the repo: an agent asks for authority nobody delegated to it, is refused, and hands over a record a third party can check offline without trusting the operator that produced it.

What it does not do yet

I would rather you read this from me than discover it.

cA2A is alpha. The published runtime is 0.1.0a1. The delegation semantics are real and tested, but they live mostly in a sibling project, and the runtime peer path is under construction.

The sealed channel is implemented as encryption and is not yet bound to a hardware-verified measurement on a live call. Until that lands, do not assume a payload is confined to a specific attested measurement. The reference transport runs in software mode by default, where assurance is explicitly none. Mutual attestation on real silicon in both directions is still outstanding.

Until this morning the delegation credential had no validity period at all. It signed who issued it, to whom, for what scope, at what depth, and under which parent, and said nothing about when the grant started or ended. So chain verification could check structure and scope narrowing and could not decide whether a grant covered the moment it was being used.

I am leaving that in rather than quietly editing it out, because how it got fixed is the more interesting fact. It was filed against us on 13 August by somebody outside the project, and closed on 17 August by a different person outside the project, who added not_before and not_after, enforced them per hop, and wrote the conformance cases for expiry and not-yet-valid. That is in main and not yet in a release, so the published 0.1.0a1 still has the gap.

Three people outside the project have landed commits on this repo in the last week, and a fourth filed the issue that produced one of them. The repo has three stars. I would rather have the four people.

And the limit that constrains all of this, which I think is the most important sentence in the RFC:

Hardware attestation proves what code is running. It does not prove where the machine is. There is no trustworthy geography in an SEV-SNP or TDX report, because nothing in the silicon knows what country it is in.

So the honest ceiling on attested residency is not proof of location. It is a split claim: what is running, rooted in hardware and verifiable offline against a vendor root with no trust in the operator, and where it is running, rooted in a signed statement from an identified operator who can be held to it afterwards. The second half is operator trust, not hardware trust. An operator with physical control of the machine can defeat it.

What that buys is non-repudiation rather than prevention. Somebody accountable signed a statement, bound to a specific attested instance, and cannot later say they did not. I think that is the strongest claim available, and any project telling you it has cryptographic proof of location is telling you something that is not true.

Three layers, one claim

I have been building these as separate things for long enough to see that they are one thing.

Agent OS is the kernel layer. It governs a single agent: what it is allowed to do, evaluated and enforced at the runtime rather than asked of the model, and written down as it happens. A kernel is the right metaphor because the point is that the governed program does not get to opt out.

Agent Mesh is the layer above, where agents stop working alone. One agent hands work to another. Constraints have to survive that handoff, and they have to narrow rather than widen at every hop.

cA2A is the layer that crosses organisations. Inside your own mesh you can plausibly trust your own operator. Across trust domains you cannot, so the payload has to be sealed to a peer whose code you verified, and the record has to be checkable by a third party who trusts neither of you.

Sovereignty is the claim that needs all three at once. A jurisdiction constraint is meaningless if the runtime does not enforce it, useless if it evaporates at the first delegation, and unprovable if the only evidence is a log written by the party whose behaviour is in question. That is the whole argument: sovereign verifiability is not a deployment region, it is a property that has to hold at the kernel, across the mesh, and between organisations, and be checkable afterwards by someone who trusts nobody.

Almost every sovereignty story on the market today is layer zero, which is a region on a purchase order.

The question

I am fairly confident about the properties: attested rather than declared, composing transitively, failing closed before data moves, verifiable offline by someone who trusts nobody.

I am much less confident about the geography half, because it is the one part that cannot be rooted in hardware.

So: if you cannot prove where a machine is, and you can only prove who signed a statement about where it is, is attested residency worth building at all, or does a signed operator statement bound to an attested instance just relocate the trust problem somewhere it is easier to ignore?

I think it relocates it somewhere it is at least attributable, which is not nothing. Tell me where that is wrong.

The RFC is open at microsoft/agent-governance-toolkit#3658. cA2A is at github.com/agentrust-io/ca2a, alpha, with its limits written down in LIMITATIONS.md rather than in a footnote. The validity-window fix is PR #110, landed this morning, against issue #108.

The LiteLLM compromise is not in any of the places you would look for it

Imran Siddique — Fri, 14 Aug 2026 09:00:00 +0000

Both poisoned versions 404 on PyPI, no CVE was ever issued, and the KEV entry filed two days later belongs to the scanner rather than the gateway.

In March, two poisoned releases of LiteLLM went up on PyPI. CloudSEK reported on 11 August that they may have reached more than 2,500 companies and 434,000 CI/CD pipelines. On 13 August Hudson Rock published its analysis of a 153GB archive taken in the attack: 433,909 files, of which 118,829 CI runner dumps were attributed to 2,488 corporate domains.

I went to check the figures and found something more interesting than the figures. If you go looking for this incident in the three places an engineer would normally look, it is not in any of them.

PyPI

litellm 1.82.7 and 1.82.8 are not on PyPI. Not yanked, which would leave them visible and installable by exact pin. Gone. Both return HTTP 404 from PyPI's own API, and neither appears anywhere in an index that currently lists 1,189 versions of the package.

What the record shows instead is 1.82.6 on 22 March, then 1.83.0 on 31 March, with nothing between them and no 1.82.9 at all. A reader arriving at the release history today sees a nine day gap and a minor version bump. Nothing on that timeline says an incident happened.

Removing the artifacts was right. Leaving no marker where they stood is a separate decision, and it is the one that makes the package's own history misleading.

The CVE

There is no CVE for the LiteLLM package compromise. Searching NVD across March and April 2026 returns only ordinary code vulnerabilities: an unauthenticated /config/update endpoint, a JWT authentication flaw, a guardrails sandbox escape. LiteLLM appears twice in CISA's Known Exploited Vulnerabilities catalog and both are red herrings, CVE-2026-42208 added on 8 May and CVE-2026-42271 on 8 June, unrelated injection bugs found months later.

The KEV entry that does exist

Two days after the poisoned releases there is a KEV entry, and it is worth being precise about whose it is. CVE-2026-33634, added 26 March, is Aqua Security's Trivy, not LiteLLM. CVSS 4.0 base score 9.4. CISA's own description: an embedded malicious code vulnerability that could allow an attacker to reach everything in the CI/CD environment, including all tokens, SSH keys, cloud credentials, database passwords and any sensitive configuration in memory.

This matters because Trivy was the way in. CloudSEK describes a leaked automation token that was rotated but not fully revoked, leaving roughly a 20 day window in LiteLLM's release pipeline. The MITRE record for the Trivy CVE is more specific: on 19 March a threat actor published a malicious Trivy v0.69.4, force-pushed 76 of the 77 version tags in aquasecurity/trivy-action to credential-stealing malware, and replaced all seven tags in aquasecurity/setup-trivy. It was a continuation of an attack that began in late February, and after the 1 March disclosure the credential rotation "was not atomic".

The dates sit close enough that it is easy to file the 26 March listing under LiteLLM and move on, which inverts the lesson. The component that earned a critical CVE and a federal remediation deadline was the scanner inside the build.

What that does to the usual advice

The standard response to a poisoned package is to pin your dependencies, and for the PyPI half of this that holds. For the Trivy half it fails in the most literal way available: 76 of 77 tags were force-pushed. Anyone pinned to a version tag got the malware precisely because they were pinned. Only a commit SHA survives a force-push, and almost nobody pins actions by SHA.

Pinning is not integrity. It is a stable name for something somebody else can still overwrite.

The part I cannot help with

Five months on, 2,488 organisations established their own exposure by reading someone else's analysis of a stolen archive. Kevin Beaumont tried the credentials belonging to one large US technology company and reported that almost every one still worked.

That gap is not a detection failure. Detection worked, and the packages were live for about forty minutes. It is that nothing produced a durable record of what the build actually did while it ran, so the only surviving account of the incident is the attacker's copy.

I should be straight that this sits outside everything I have built. cMCP records what crosses the gateway and TRACE signs the records so a third party can check them, and neither is anywhere near a CI runner at build time. A poisoned package executing inside your pipeline never touches either one.

What did not survive checking

"CISA added the CVE two days in." Cut. No CVE exists for this compromise. The 26 March KEV entry is Trivy's.
"Shipped a clean version six days later." Corrected. 1.82.6 is 22 March and 1.83.0 is 31 March, so nine days after the last clean release and seven after the poisoned ones.
"PyPI quarantined them inside forty minutes." Narrowed. CloudSEK gives forty minutes as the period the packages were live and does not say who removed them. No source I could reach names the actor.
"An unpinned Trivy scanner." Corrected. The vector was a leaked automation token and a non-atomic rotation, not an unpinned dependency.
"2,488 corporate domains" from 433,909 files. Scoped. The domains were attributed from the 118,829 CI runner dumps, a subset of the archive.
Whether LiteLLM's maintainers disclosed the same day: I could not verify it, so it is not here.

Checked against

What the encrypted reasoning paper actually counted

Imran Siddique — Thu, 13 Aug 2026 09:00:00 +0000

Coverage of the reasoning-trace harvest reported three different totals as if they disagreed. They are all the paper's own numbers, at three different denominators.

A paper posted on 10 August showed that the encrypted reasoning blocks Anthropic, OpenAI and Google hand back to API clients were interchangeable inside each provider. A block issued in one session could be replayed into a different session, a different account, a different model in the same family. Hand it to a weaker sibling model and ask it to transcribe, and it reads the contents back in plain text.

No cipher was broken. The ciphertext was confidential and it was bound to nothing.

I want to record two things that the coverage got wrong, because both are the kind of error that survives into everyone's slide deck.

The three totals are not a disagreement

Different outlets reported the harvest as 182 credentials plus 367 pieces of personal information, or as 704 artifacts, or as 912. Read side by side those look like sources contradicting each other, and at least one write-up said so.

They are all in the paper, and they count different things:

912 is every privacy artifact recovered, including the ones that came from benchmark sources rather than real users.
704 is the subset from genuine, non-benchmark user sessions. That is the number that means something, because those are real people's secrets.
182 credentials and 367 pieces of personal information are two of the paper's three artifact categories, which is what its abstract leads with.

Within the genuine-session set, the breakdown is 62 API keys, 33 passwords, 24 access tokens, 7 private keys and 30 personal email addresses. The scan covered 6,708 publicly posted agent trajectories and decoded 315,320 reasoning blocks.

The lesson is not about this paper. It is that coverage reliably repeats a number and drops the scope attached to it, and two correctly-reported numbers at different denominators then read as a contradiction. If you find yourself adjudicating between outlets, the answer is usually that nobody disagreed and the denominators were thrown away in the retelling.

The dismissals were not a response to this paper

Matthew Green reported the replay behaviour on 29 May, three months earlier. His account of what came back is worth quoting exactly, because a shortened version of it is now circulating with the causality reversed:

OpenAI said my report was unreproducible

Anthropic quite reasonably told me they don't see any security implications in side channels or replays

Several summaries have welded those quotes onto the August paper, producing a story where providers waved the researchers away and the team ran the harvest to force the issue. That story is not in the paper. Its disclosure section says all model providers acknowledged receipt of its report, and it attributes the earlier dismissals to Green's May disclosure by citation. Green himself calls Anthropic's answer a fine decision.

So the honest version is duller and more interesting: a cryptographer flagged the primitive in May, the providers judged it low severity, and a paper in August measured what the primitive was costing in the wild. Nobody in that sequence behaved badly. The gap was that no one had counted.

The paper's reproducibility statement notes that as of August the results no longer reproduce, because of mitigations the providers implemented following the disclosure. It does not date those mitigations, and I have not seen anyone who can.

The part that is mine

The missing control is a binding check at decrypt: this block was issued for this session, this account, this model, or it is refused. It runs at the provider's API boundary, because that is the only place the plaintext exists. No gateway, no agent framework and no policy layer can validate a binding on a payload it cannot open. That is enforcement, and it prevents the replay.

The evidence layer has a different job and it does not prevent anything. It decides what is allowed into the record in the first place.

Here is where that lands on my own work. The TRACE specification says, in its stated limitations:

does not record the model's internal chain-of-thought, intermediate reasoning, or context window contents

We file that under Known Limitations and it belongs there, because reasoning that changes behaviour without producing a tool call never reaches the record. It is also the reason a TRACE record contains nothing we cannot read back, which is the property this paper makes expensive to lack. Sixty-four of the recovered artifacts appeared only inside the opaque blocks and nowhere in the visible transcript. Some developers had cleaned the readable session before publishing it and shipped the secrets anyway.

A retention policy is a claim about fields you can read. If your trace carries a field you cannot open, you do not have a retention policy for it. You have a hope.

Checked against

What a signature does not prove

Imran Siddique — Wed, 12 Aug 2026 15:54:56 +0000

Updated after correction from Muhammad Usama Sardar, who reported this CVE. The original version of case two overstated the difficulty of exploitation and wrongly described the vulnerability as patched. Both are fixed below.

I spend most of my time building evidence layers for AI agents. The reflex in that work is to reach for a signature. Something happened, sign the record, hand it to the auditor, done.

Three things from the last five months say that reflex is wrong, or at least badly incomplete. One is a governance draft that never asks for a signature at all. One is a CVE where the signature verified correctly and the client still ended up talking to an attacker. One is a limit in a spec I wrote myself.

Read together they point at the same thing. A signature is a statement about an object. Almost every security question you actually care about is a statement about a relationship.

Case one: the requirement that is not there

The Open Secure AI Alliance published its Shared AI Findings Exchange draft on GitHub on August 3. It is an incident-reporting compact for AI agents. Members agree to report when an agent they operate accesses or disrupts a third-party system without authorization, and to do it on a clock: notify the affected organisation as soon as possible, notify customers with credible exposure within 72 hours, file a confidential report within four business days.

The clock is well specified. So is the evidence. Members must preserve and provide affected organisations with "prompts, traces, tool calls, logs, configurations, model and safeguard versions and third-party dependencies", plus agent and workload identities, permissions and credentials available during the run, human approval events, and a complete incident timeline.

That is a good list. It is close to the one I would have written.

Now search the draft for signing. It appears exactly once, in a list of example recommendations that incident reviews might produce: "signed evaluation manifests". The draft also asks, in its review framework, whether "data boundaries [were] independently verified".

Both of those are about keeping an agent inside its box. Neither applies to the record of what happened when it got out. The evidence list carries no integrity requirement at all. No signature, no hash, no attestation, nothing tamper-evident.

So the operator produces the trace, holds it, and decides what to send. Every artefact on that list is a mutable file on infrastructure controlled by the party with the most to lose from the report.

To be fair to the draft, one of its own principles is "Learning is separate from enforcement", and I am not asking a disclosure framework to prevent anything. But evidence is neither learning nor enforcement. An evidence layer has one job, which is to be believable by someone who does not trust you.

This is the easy case. Nobody has claimed anything false. A requirement is simply missing, and the comment period is open.

Case two: the signature that verified and lied

The hard case is CVE-2026-33697, published on March 26, against CoCoS, a confidential computing system for AI from Ultraviolet.

Attested TLS is the mechanism that is supposed to close the last gap in confidential computing. You do not just want an encrypted channel, you want proof that the other end is a genuine enclave running the code you expect. So you bind hardware attestation evidence into the TLS handshake. The client checks the evidence, sees a real TEE with the right measurements, and proceeds.

In CoCoS versions v0.4.0 through v0.8.2, on both AMD SEV-SNP and Intel TDX, that check could pass while the client talked to an attacker. From the advisory:

Because the attestation evidence is bound to the ephemeral key but not to the TLS channel, possession of that key is sufficient to relay or divert the attested TLS session.

Read that twice. The attestation report is real. It came from a genuine enclave. It is correctly signed by hardware and it validates. The client is not fooled about the existence of a real TEE. It is fooled about which endpoint it is speaking to, because nothing tied the signed evidence to the channel carrying it.

Two details make this worth more than a routine advisory.

The first is that the attestation subsystem was fully redesigned in v0.7.0 and the flaw survived the rewrite. It was not an implementation bug. Getting the code right does not help when the design binds the wrong two things together.

The second is that this is not one vendor's mistake. Muhammad Usama Sardar and co-authors formally analysed attested TLS in ProVerif and found diversion attacks against two candidate standardisation protocols, Intel's Interoperable RA-TLS and the intra-handshake draft-fossati-tls-attestation. In their published property table, server identity, server authentication, compound authentication and agreement of all parameters evaluate to false for both. A follow-on paper extended this to seven distinct intra-handshake binding designs. All seven fail to stop a relay attack. The work went to the IETF, and draft-fossati-tls-attestation was withdrawn by its authors at revision 10.

The CVE record still reads "As of time of publication, there is no patch available." Five months later that is still accurate. CoCoS tagged v0.9.0 in the advisory's patched-version field, but the advisory text says no patch and no complete workaround, and the people who reported the flaw say the underlying problem is unfixed. The IETF draft does not offer a patch either. Its recommendation is that maintainers of intra-handshake attestation must move to post-handshake attestation, and it concedes that the mechanism it proposes reaches only level 2 binding, not level 3.

The two scorers disagree about how bad it is, and the reason is not a disagreement about what attestation covers. GitHub scored the vulnerability as found: 7.5, Scope: Changed. NVD scored it after the recommended mitigations: 6.3, Scope: Unchanged. The mitigation the lower score leans on is a strict attestation policy that validates every available report field, and that is where it comes apart. No field in the report tells you which machine you reached. Intel has a mechanism for this, Platform Ownership Endorsements, which binds a per-platform identifier to an owner. Cloud providers are not willing to release the identifiers for their fleets. So the policy that would pin the endpoint cannot be written, and the score that assumes it can is the optimistic one.

Worth stating plainly, because the advisory's own wording sent me the wrong way first time. The advisory frames exploitation as extracting the ephemeral TLS private key, through physical access to the hardware, transient execution attacks, or side channels. That reads like a high bar. It is not the attack. The attacker does not need the target's key. They need a key they already hold on some machine that produces a valid attestation report, which is any machine they can rent and run the same image on. The client checks that the report is genuine, that the measurements match policy, and that the report is bound to the key in front of it. All three pass. Nothing in the report says which machine it came from, so the client cannot distinguish the enclave it meant to reach from an identical one the attacker is paying for by the hour. No physical access, no side channel, no extraction. The formal analysis states it in the abstract: intra-handshake attestation fails in practice, even without physical access.

Case three: mine

TRACE is a trust-record format I maintain. A gateway emits a signed record for each agent tool call, and an auditor can verify that a record was not altered after the fact. That part works, and there is a conformance suite full of forged-signature and broken-chain vectors to prove it.

It has two limits, and they are the same shape as case two.

The record set is not provably complete. TRACE captures what is observable at the gateway boundary. If a call routes around the gateway, there is no record, and a missing record looks identical to an action that never happened. Signing fixes forgery. It does nothing about omission. A signed set of records is a signed claim about the records that exist, not about the ones that should.

And verification runs against the issuer's own key. The self-hosted verifier confirms cryptographic validity against the key of the party that produced the record. That is fine for detecting later tampering by a third party. It is much weaker than it sounds if the question is whether the issuer was honest at write time, because the issuer holds the key. Independent verification needs an anchor outside the issuer, and that is a separate mechanism, not a property of the signature.

So a signature from my gateway is not something your incident responder can independently check. I would rather say that than have someone discover it.

The common shape

In all three cases the signature is not the interesting part.

SAFE never asks for one, so the evidence is whatever the reporting party says it is.

CoCoS had a perfectly valid signature over a genuine attestation report, bound to an ephemeral key rather than to the channel. The signature was true and the conclusion the client drew from it was false.

TRACE signs each record correctly and cannot speak to the completeness of the set or to its own issuer's honesty.

Signing is the easy part. It is a well-understood operation with good libraries. The hard part is binding: tying the signed thing to the other thing you actually care about. This record to the complete set. This evidence to this channel. This signer to a trust root you did not choose.

Every one of these failures is a missing binding, not a missing signature. And bindings are where formal analysis earns its money, because a missing binding is invisible in code review and obvious in ProVerif. Seven designs, all reviewed by competent people, all failing the same property.

What I would change in SAFE

The concrete version, since a criticism you cannot file is just a complaint. SAFE's Evidence Preservation section should say roughly this:

Evidence must be integrity-protected at the point of capture, not at the point of reporting. Each preserved artefact carries a digest recorded when it is written, and the digest set is signed by the runtime that emitted it rather than by the process that files the report four business days later. A gap in the record must be distinguishable from an absence of activity, so the record needs a sequence that reveals holes. And the receiving party must be able to verify all of it without trusting the sender, which means an anchor the reporting operator does not control.

I do not have a complete answer to that last requirement, and neither does my own spec. Someone has already filed the adjacent half in the repo: issue #6 proposes a pre-connection attestation for the thing an agent connects to, and correctly notes that the draft gestures at signed artefacts without specifying their representation. The integrity of the preserved evidence itself is still open.

If you build agent infrastructure, the question to sit with is not whether you sign your logs. It is what your signature is bound to, and whether the party who has to believe you can check that binding without taking your word for it.

Two of the three endpoints checked authorization

Imran Siddique — Wed, 12 Aug 2026 09:00:00 +0000

The gym booking story is being told as an API with no authorization. The agent's own account says two of the three operations it touched returned 403, and one did not.

An Australian man asked his personal assistant agent to book him a gym class. He was fourth on the waitlist. Minutes later he was third, because the agent had cancelled the booking of the person in first place.

The agent explained itself in plain text, and its wording matters:

the API has zero authorisations checks on cancelling other people's reservations

Nothing was jailbroken. There was no prompt injection. The agent read the API and used it exactly as documented.

The detail that changes the story

Most coverage stopped at "the API had no authorization". The agent's second message, which one outlet carried and the rest did not, says something more specific: createReservation and joinWaitlist both returned 403 Forbidden. Only cancelReservation was missing the ownership check.

So this was not a platform built without a security model. It was a platform with a security model and one handler where somebody forgot to apply it. Two of the three operations the agent touched behaved correctly.

That is a much more uncomfortable finding, because "we never did authorization" is a project you can schedule and "one of our handlers is missing a check" is a condition every codebase is in right now and cannot easily prove it is not.

I am scoping that carefully on purpose. Three operations were reported. That says nothing about how many endpoints the booking platform has, and I do not know the ratio. When I first wrote this up I said "two thirds of the API worked", which generalises three data points to a whole system, and I had to correct it after publishing. The honest statement is the narrow one.

What kind of bug this is

Broken Object Level Authorization: the caller is authenticated, the caller is permitted to invoke the operation, and nobody checks that the caller owns the specific object being operated on. It is the first entry on the OWASP API Security Top 10, and it has been for years.

The gap was presumably always there. Human customers only ever clicked the buttons the web interface gave them, and the interface never offered to cancel a stranger's reservation. The agent is not a new class of attacker. It is the first client in that API's history that tried every request the API allowed.

The missing control is per-request object authorization: does this caller own this object, not is this caller logged in. It has to run in the endpoint's own handler, on the server, next to the data that answers the question.

Why my own layer would not have caught it

AGT puts a deterministic policy engine between an agent and its tools, with no model anywhere in the safety path. On this incident it would have seen the agent issue a cancel call. It would not have known the reservation belonged to a stranger, because that fact lives in the gym's database and appears nowhere in the request.

A governance layer on the agent's side cannot make a check that only the server can make. This is the boundary, and I would rather state it than let a diagram imply otherwise.

There is a second thing worth separating, because I blurred it in the first version of this and it is worth not repeating. Enforcement runs at the service, before the operation executes, and it prevents. Evidence is written after the fact, it is tamper-evident, and it proves. A log would not have saved the person whose class was cancelled. It would only have made the conversation afterwards short.

OpenClaw was at 385,960 stars when I read the repository. Every latent authorization gap in your API now has a client that will find it, and it will find it while trying to be helpful.

What did not survive checking

One outlet placed the man in Melbourne. The Register says only "Australian" and the other coverage names no city, so the city is not here.
Reports of how far ahead the agent could book range from "several weeks" to "months", so no number is here either.
Several outlets called this Australia's first autonomous cyberattack. That is a characterisation and not a finding, and it argues the story on the wrong axis.
The original ABC News report is the primary source. abc.net.au blocks the crawler I use, so I have not read it directly. Everything above comes from two outlets that quote it and agree with each other.

Checked against

The approval prompt stops working after fifty clicks

Imran Siddique — Tue, 11 Aug 2026 19:35:36 +0000

On Friday, auto mode becomes the default in Claude Code for Pro, Max and Team plans. The agent will act without asking unless something is irreversible, destructive, or pointed outside your environment.

The easy reading is that a vendor just removed a safety control. The data Anthropic published alongside it says something more uncomfortable, which is that the control was not doing much work in the first place.

The numbers, and what they are measured over

In a controlled study of 1,053 paid testers, auto mode blocked 89% of the commands that humans caught “just 13.6% of the time (143 of 1,053)”. Same commands, both arms.

The first is that users approve 97% of permission prompts in Claude Code. They reject 39% of the plans Claude presents, so this is not people clicking through everything. It is specific to the approval prompt.

The second is the one I have not been able to stop thinking about. Humans blocked about 17% of dangerous commands early in a session, and about 5% after fifty or more prior prompts. The classifier’s block rate stayed flat regardless of session length.

A control that gets worse the more you use it is not really a control. It is a ritual with a decay curve.

The honest limit on those numbers: participants worked in a test environment built for the study, not in their own codebases. Somebody reviewing their own repository, with their own production credentials, may well pay more attention. Anthropic’s production telemetry points the same direction but less dramatically, 6.3% of manually approved sessions contained a harmful action the user had not asked for, against 2.4% for auto mode.

The gate is now a target

On 4 August the UK AI Security Institute published what it found testing frontier models: 19 unauthorised actions across 10 of 122 evaluation runs, 17 involving Anthropic’s Mythos 5 and two involving OpenAI’s GPT-5.6 Sol. Those runs had cyber safety classifiers disabled and open internet access, which is not how either model reaches the public, and AISI says none of it caused real-world harm. That caveat is load-bearing and I am not going to bury it.

But one incident in that set is not about detection at all. An agent tried to get malicious code into a real open-source project. It researched the maintainers, created fake online identities, and used them to pressure a human reviewer into approving the change.

It did not attack the system. It attacked the approval.

Detection does not close the gap either

The obvious answer is to replace the tired human with a good detector. The best published one I know of is Uber’s agentic detection work, which catches 67% of attacks at zero false positives on their benchmark, beating the next best systems by two to four times on F1, after ten months in production.

Sixty-seven per cent, from the state of the art, running at real scale. Roughly one attack in three still gets through.

So the position we are actually in is this. The approval gate is the weakest control in the stack. It degrades with use. It is now being deliberately targeted. And the best available replacement misses a third of what it is aimed at.

What follows is not better gates

If you assume that a meaningful share of bad actions will be approved, by a tired human or a good classifier or both, then the question stops being how to stop them all and becomes what survives afterwards.

Today an approval leaves a boolean. Somebody clicked yes. When the question arrives six months later, and it always arrives as a question about one specific action, what the approver actually saw is gone. The proposal has been regenerated, the policy has moved twice, the model version changed in April, and the person has left.

The cheap fix, and we did not find it obvious at the time, is to pin the thing being proposed, the policy in force at that moment, and the identity of the approver into a single record at the point of approval. Not a log line. A record that can be checked later by somebody who was not there and has no reason to trust whoever ran the system.

That turns the gate from a control into evidence.

We have been building that record in the open, as TRACE. It pins the proposal, the policy in force and the approver into one artifact a third party can check later without trusting whoever ran the agent, and it ships with a conformance suite that will fail a record for you, which is the honest way to find out whether a format survives contact: https://github.com/agentrust-io/trace-spec

Here is the part I want to be straight about, because it is where this argument is weakest. None of that prevents the AISI attack. A reviewer who has been socially engineered into approving still approves, and the record faithfully captures a genuine approval of a malicious change. Evidence does not stop the failure. It makes the failure reconstructible and attributable afterwards, which is a much smaller claim than prevention, and it is the one that survives contact with how these systems actually fail.

I would rather make the small claim and have it hold.

The question

Auto mode is the right call on this evidence. I would make the same one. But it moves the industry from “a human approved this” to “a classifier allowed this”, and both of those are still booleans.

So: would you accept an agent that acts without asking you, if every action it took left a record you could independently check afterwards?

Most people I put that to say no immediately. Then I ask what their current approval prompt is proving, six months after the fact, to someone who was not in the room. That one takes longer.

If your answer is a Slack thread and a timestamp, the gate was never the control you thought it was.

Sources: Anthropic, “Auto mode is now the default in Claude Code”; UK AI Security Institute findings reported 4 August 2026; Uber’s published agentic detection results.

You downloaded a model. What did you actually get?

Imran Siddique — Thu, 06 Aug 2026 22:15:35 +0000

We sign containers, packages and commits. Model weights we take on trust.

You downloaded a model last week. What did you actually get?

You got a file. It came from a hub, or a mirror of a hub, or a helpful colleague who re-uploaded it somewhere faster. You checked the file size. Possibly. Then you loaded it and started serving traffic.

I do not think anyone is being careless. I think the tooling simply never asked the question, so nobody got in the habit of answering it.

Everything else in the pipeline is signed

Look at what a normal deployment already insists on.

Container images have digests, and you pin them. Packages have signatures and attestations, and your build fails when they do not verify. Commits get signed, and the review UI puts a badge on them. Every one of those was a fight at some point, and every one of those fights is now settled. Nobody argues that a container should be pulled by mutable tag in production.

Then the same pipeline pulls twenty gigabytes of weights over HTTPS and loads them into a GPU with no signature, no publisher identity, and no record of what was expected.

HTTPS tells you the bytes arrived unmodified from whoever served them. It does not tell you who built them, whether the thing you got is the thing that was trained, or whether the checkpoint in front of you is the one that was evaluated for safety before release.

The weights are the artifact that decides what your product says to customers. They are the least verified thing you ship.

Why this is worse than it sounds

Three things make weights a nastier case than a package.

First, you cannot read them. A reviewer can skim a diff and notice something odd. Nobody is eyeballing 2.8 trillion parameters. There is a line in our demo output that I keep coming back to:

no human reads 2.8T parameters; the hash does the reading.

That is the whole argument. Verification of an artifact this size is not a human activity, so it has to be a mechanical one, or it does not happen at all.

Second, tampering does not look like breakage. A poisoned checkpoint loads fine, serves fine, and scores fine on the benchmarks you happen to run. There is no crash to alert you. Model behaviour is diffuse enough that a targeted change can sit undetected for a long time.

Third, the distribution path is long and informal. Weights get mirrored for bandwidth, converted between formats, quantised by third parties, and re-uploaded by enthusiasts. Every one of those steps is a place where the artifact changes hands, and almost none of them carry provenance forward.

What a manifest actually does

The fix is not exciting. That is a feature.

A Weight Custody Manifest is a small signed document that travels with a checkpoint. It states the exact weights_hash of the artifact, who built it, and what they are asserting about it. It is signed, so you can check the assertion came from the party you think it did.

That gives you the thing you did not have before: an expectation. Before the weights load, you compare what you downloaded against what the builder signed. Same hash, proceed. Different hash, stop.

Not “log a warning”. Stop, before the file is loaded, because after loading is too late to be interesting.

If a fine-tune is involved, the derivative gets its own manifest that points back at the base it came from, so the chain of custody resolves instead of dead-ending at a filename.

Run it

I would rather you did not take my word for any of this. It runs on a laptop in about a minute, with no confidential-computing hardware, no cloud account, and no signup.

pip install weight-custody-manifest
git clone https://github.com/agentrust-io/demos && cd demos
python demo.py 6

What you get is real output, not a slideshow:

weights_hash bound : sha256:99b3e4e7...3a39f9
manifest signature : True (jointly signed builder + custodian)
gate released key : True

certified hash : sha256:99b3e4e7...3a39f9
downloaded hash : sha256:b3a36b54...b9758e
matches manifest : False -> REFUSE to load

derivative : lineage verified True depth 1 root is a base: True

The third block is the one that matters. A tampered checkpoint is refused on the hash, before load, without anyone reading anything.

What this does and does not give you

Worth being precise, because precision is the point of the exercise.

This gives you integrity and provenance for open weights. Hashing and signatures are old, boring, well understood cryptography, and they do exactly what they claim here. If the artifact changed, you find out.

What it does not give you is protection against an adversary who physically owns the machine. That is a different problem with a different answer, and anyone who tells you a hardware boundary solves it completely is overselling. But that is a separate post, and it is not the problem most teams have today. Most teams have the first problem: they cannot say what they loaded.

Where to look

The demos are open source and there are nine of them, four on weight custody and five on governing what an agent does at the tool boundary. The SDK is on PyPI.

agentrust-io.com/demos

github.com/agentrust-io/demos

weight-custody-manifest on PyPI

If you think the model is wrong, or the threat model is wrong, I would genuinely like to hear it. Tell me where it breaks.

The best agent detector in production catches 67%. Plan for the rest.

Imran Siddique — Tue, 04 Aug 2026 20:41:41 +0000

Last week two of the strongest engineering organizations in this industry open-sourced their agent security stacks three days apart. Uber released ADR, the detection and response system it has run in production for ten months. Perplexity released Numbat, an Apache-2.0 agent security suite already deployed across thousands of its own endpoints. Both are real, running, well-built software, and if you operate agents at any scale you should read both this week.

Then read ADR’s paper, because it contains a number that almost nobody quoting the release has repeated. On ADR-Bench, Uber’s own benchmark of 302 tasks, 17 attack techniques and 133 MCP servers drawn from real telemetry, ADR detects 67% of attacks at zero false positives. That result beats ALRPHFS, GuardAgent and LlamaFirewall by two to four times on F1. It is, as far as the public record goes, the best agentic attack detection anyone has published.

State of the art, ten months in production, benchmarked against its own real-world telemetry, and roughly one attack in three gets through.

67% is not a failure. It is the ceiling.

I want to be precise about the compliment here, because it matters. Uber published that number. They built the benchmark that exposes their own limit, put it in a paper, put the sensor and the detector and the benchmark on GitHub, and let you check. That is proof rather than promises, and it is rarer than it should be.

The number is not an indictment of ADR. It is a property of the category. A detector is a bet on the attacks you thought of. ADR-Bench encodes 17 techniques, which is 17 more than most teams have enumerated, and the honest reading of 67% is that even an excellent detector, tuned against real traffic by a team with production scar tissue, cannot close the set. The residual is not sloppiness you can engineer away with better rules. It is the part of the threat space that was not in the training distribution, and it will exist in every version of this product forever.

So the operational question is not how do we get to 100%. It is what do you have left when the detector does not fire?

If the answer is your logs, you do not have much. Logs are written by the host, on the host, and they are editable by whoever just took the host. The single most common shape of a serious incident is that the record of the incident is controlled by the party you are investigating.

Detection is a probability. Evidence is a record. You need both, and only one of them still works after you lose.

Controls act only to the left of the ceiling. The record is drawn undivided because it does not depend on classification.

RufRoot is what the other third looks like

While those two releases were landing, the agent ecosystem produced a near-perfect illustration.

CVE-2026–59726, which Noma Security named RufRoot, is a CVSS 10.0 in Ruflo, an agent meta-harness in very wide use. Every version before 3.16.3 shipped an unauthenticated MCP bridge, open to the network by default, exposing 233 tools, including shell execution, database operations, agent management and memory storage. One unauthenticated HTTP request gets remote code execution. It was disclosed on June 30 and, to the maintainer’s credit, patched inside 24 hours.

Here is the part that should change how you think about your own deployment. The remediation guidance does not stop at upgrade. It tells you to rotate every LLM API key, close ports 3001 and 27017, inspect MongoDB for tampering, and audit the AgentDB pattern store for malicious entries, because a patched redeploy alone does not undo the poisoning.

Read that again as an operator. The researchers demonstrated writing attacker-controlled entries into the agent’s persistent memory, so that future responses incorporate attacker instructions. You patch to 3.16.3. Your scanner goes green. Your dependency report is clean. And your agent is still compromised, because the compromise is no longer in the code. It is in the state.

Detection did not catch this, because there was nothing anomalous to catch: an authorized tool wrote to an authorized store. Patching did not clean it. And nothing in the ordinary stack can tell you whether that store is the one you started with.

The redeploy replaces the measured image and never reaches the pattern store, so the poisoned entry survives the patch.

Unmeasured is not empty

The mistake underneath all of this is treating agent memory as a cache.

If memory were retrieval, RufRoot would be a nuisance and you would flush and move on. But agent memory is accumulated state that changes future behavior, which makes its integrity a security property of the running system, exactly like a policy bundle or a tool catalog. We already accepted this for code. Nobody ships a container without a digest. Then we hand the same agent a persistent store that shapes every subsequent decision, and we measure nothing.

A store you never measured is not a clean store, and it is not a corrupted store. It is a store about which you can say nothing at all.

Which is why “no evidence of tampering” is a statement about your instrumentation rather than about your agent. The fix is not exotic and it is not new thinking. It is what we do everywhere else: measure the state, bind the measurement to hardware, and make a change that nobody recorded detectable rather than invisible. If the pattern store’s digest is measured into an attestation and anchored in an append-only registry, an attacker who poisons it either leaves an entry you can find or breaks a chain you can verify. The poisoning stops being a silent non-event.

What attestation does not do

This newsletter is called Proof not Promises, so here is the part that cuts against me.

Attestation does not stop the action. Numbat’s pre-action hook does something a signed record fundamentally cannot: it evaluates a proposed command before it reaches the operating system and refuses it. Fifty-two rules across eleven behavior categories, expressed in CEL, running in a Go binary on the endpoint. That is a real-time no. Evidence arrives afterward, and afterward is not always good enough. Anyone telling you attestation replaces controls is selling you something.

The two layers do different jobs and you want both. Controls reduce the probability. Evidence removes the deniability. ADR and Numbat are strong work in the first category. What I am arguing is that the second is not optional once your detector’s honest number is 67%.

And the harder admission: the memory half of this is not built. We have measured policy bundles and tool catalogs into hardware attestation for a while now. Persistent agent memory, the pattern stores and long-term state that RufRoot went after, is open work in our stack as much as anyone’s. I am writing that down in public deliberately rather than filing it away, because I would rather it get built than owned.

Where the evidence layer already is

The receipt half exists today, in the open, and you can run it.

TRACE produces a signed, hardware-rooted, offline-verifiable record of what ran: which model, under which policy version, on what hardware, with the full tool transcript. github.com/agentrust-io/trace-spec
cMCP enforces policy inside a hardware-attested enclave at the MCP boundary, the same boundary RufRoot left unauthenticated. The policy bundle is measured into the attestation report before any code runs, so a compromised host cannot quietly swap it. github.com/agentrust-io/cmcp
Agent Manifest binds what an agent is, its prompt, policy, tool schemas, model identity, provenance and delegation chain, to hardware, so that not being sure what was running stops being an available answer. github.com/agentrust-io/agent-manifest
AGT covers the deterministic allow and deny layer at the action and tool-call boundary, against 10 of 10 of the OWASP Agentic Top 10. github.com/microsoft/agent-governance-toolkit

Two invitations, both real. If measuring agent memory state is your problem, come build it with us, because it is the gap I would most like closed this year. And if you run agents in production, read the ADR paper and the Numbat rules properly, adopt what fits, then ask the question the 67% forces: when the detector stays quiet, what will I be able to prove?

Detect what you can. Record what you cannot. And measure the state, because unmeasured is not empty.

Sources

ADR paper, 67% at zero false positives on ADR-Bench: arxiv.org/abs/2605.17380
ADR sensor, detector and benchmark: github.com/uber/ADR
Numbat, Securing Agents Across Perplexity’s Client Endpoints: research.perplexity.ai
RufRoot technical write-up, Noma Security: noma.security/blog
CVE-2026–59726: app.opencve.io/cve/CVE-2026–59726

Ruflo v3.16.3 security release: github.com/ruvnet/ruflo/releases/tag/v3.16.3

Our Quickstart Did Not Work, And That Is The Interesting Part

Imran Siddique — Tue, 04 Aug 2026 15:59:25 +0000

What we learned shipping a ten-minute governance demo, and why we test docs against the published artifact instead of the working tree.

Yesterday our product manager opened a pull request adding a quickstart to agentrust-io.com. Install the cMCP runtime, write a Cedar policy, watch it block a tool call, verify the signed receipt. Ten minutes, on a laptop, no hardware. The copy was good. The design was good. The demo could not work.

Not “was awkward”. Could not work. Every visitor would have hit a connection error where the page promised a 403.

Here is how, because the failure is more instructive than the fix.

The rule that never fired

The policy forbade a Salesforce tool once the session had touched PII:

forbid ( principal, action == cMCP::Action::"call_tool",
         resource == cMCP::Resource::"salesforce.contacts" )
when { context.session_max_sensitivity == "pii" };

Reads fine. Tells a good story: the agent already handled sensitive data, so this call is now off limits.

The problem is when session_max_sensitivity changes. It starts at "public", and it only rises when the runtime inspects a tool response and finds sensitive content. On a fresh session, the first call evaluates with sensitivity still at "public". The forbid does not match. The permit rule below it wins, and the call is forwarded to an upstream server at localhost:9001 that the page explicitly told you not to run.

So the page’s core promise, “no tool server needed, the policy blocks before it forwards”, was true of the architecture and false of that particular rule.

The rule that could not match anyway

There was a second, independent failure. pip install cmcp-runtime gives you 0.3.0, the latest on PyPI. On 0.3.0, the Cedar resource key was never populated, so resource == Resource::"salesforce.contacts" could never match anything. That was fixed after the release, in code that is not published yet.

The page had been validated against a local checkout, which is 77 commits ahead of the newest release. Editable installs are excellent at hiding this class of bug. Your working tree passes. Every reader fails.

This is the part I would tattoo on a docs process: test your quickstart against the artifact your reader installs, in a clean environment. Not your repo. Not your editable install. A fresh virtualenv and the published wheel.

The security bug hiding in the config

One more, and this one shipped as a security issue rather than a broken demo. The config omitted listen_addr. Dev mode deliberately skips the bearer token requirement so you can try things quickly. On 0.3.0 the default bind is 0.0.0.0:8443. Following our page to the letter stood up an unauthenticated policy gateway on every interface on your machine.

That is a bad thing to ask a stranger to do. It now pins 127.0.0.1:8443 and says why.

The fix, and what the demo teaches now

The rule now keys off something available on the very first call: the compliance tag the operator put on the tool in the catalog.

forbid ( principal, action == cMCP::Action::"call_tool", resource )
when { context.compliance_domain == "pii" };

We also deleted the catch-all permit at the bottom of the bundle, so it is default-deny, which is the correct thing to teach anyone writing their first policy.

Verified in a clean virtualenv against the published 0.3.0:

HTTP/1.1 403 Forbidden
{"error":{"message":"Request denied by policy",
          "data":{"error_code":"POLICY_DENY"}}}

No upstream server running. The call was refused before a byte left the machine.

The stateful version of the rule, the one that tracks sensitivity across a session, is still the more interesting behaviour, so it stayed on the page as a “go further” section that is honest about needing a mock upstream and a prior allowed call.

The receipt, and the FAIL we left visible

The last step closes the session and verifies the signed TRACE claim it produces:

[cmcp verify] schema PASS
[cmcp verify] signature PASS
[cmcp verify] policy_bundle.hash PASS (not pinned)
[cmcp verify] tool_catalog.hash PASS (not pinned)
[cmcp verify] attestation_freshness PASS
[cmcp verify] audit_chain PASS
[cmcp verify] hardware_attestation FAIL software-only mode
[cmcp verify] RESULT: FAIL (partially_verified)

Exit code 1.

We publish that verbatim. Every cryptographic check passes. The hardware attestation check fails, because a laptop in software mode has no hardware root of trust to offer, and the tool refuses to call the result verified without one. A governance product that reported success there would be worthless, because the entire value proposition is that the receipt means something.

Run the same runtime inside a TEE and that check passes and the result becomes verified. That is the version you hand a regulator. The laptop version is for learning what the thing does.

Try it

Ten minutes, Python 3.11 or newer, macOS or Linux, MIT licensed.

https://agentrust-io.com/quickstart/

Source: https://github.com/agentrust-io/cmcp

Anything reproducible: https://github.com/agentrust-io/cmcp/issues

Quick questions, in a Discord that is small and new: https://discord.gg/grgzFEHgkj

If it breaks for you, that is the most useful thing you can tell us. The last person who found a broken quickstart got it fixed before anyone else ran it.

The industry scheduled the proof. Here is what provable inference has to prove.

Imran Siddique — Sun, 02 Aug 2026 18:20:41 +0000

Something quiet and remarkable showed up on the frontier labs’ safety roadmaps this year. Not a bigger model. Not a new benchmark. A commitment to provable inference: a technique to cryptographically sign a model’s output so it can be tied back to a specific, unmodified set of weights. In plain terms, a proof that this output came from that model, and not from a tampered copy, a quietly quantized substitute, or someone else’s fork wearing the same name.

For a newsletter called Proof not Promises, I could not let that pass. A frontier lab writing “the proof” onto a dated roadmap, with a prototype targeted inside the next year, is the most on-the-nose thing to happen in this field all year. It is also, today, a promise. So let me do the useful thing and walk through what a real proof would actually have to deliver, and where the whole ecosystem honestly stands. Because the gap between the roadmap bullet and a shipped artifact is exactly the thing worth understanding.

What a proof of inference actually has to bind

Strip it to the claim you want to make: these exact weights, given this exact input, produced this exact output, and a hostile operator could not have faked any of it. To be a proof rather than a promise, one verifiable statement has to bind four things at once:

the weights (a hash of the specific, unmodified checkpoint),
the input (the prompt and context that went in),
the decode parameters (temperature, seed, sampling, everything that makes the run reproducible),
the output (the tokens that came out).

Miss any one and you do not have a proof; you have a story. Bind all four in a way that does not require trusting the machine that ran it, and you have something new. Nobody ships that today. Here are the three ways people are trying, and where each honestly lands.

Option 1: prove the math. Real, and far too slow.

The cryptographic gold standard is a zero-knowledge proof of the forward pass: prove the computation ran with committed weights, with no trust in the hardware at all. This is the real thing, and it is genuinely advancing. But be honest about the numbers. Proving a 13-billion-parameter inference takes on the order of fifteen minutes, and the newest work (zkComposer, July 2026) buys roughly a 6.8x speedup on GPT-2-scale models. Real-time proof of a frontier-scale (100B+) model is explicitly beyond the state of the art, the proving overhead is still orders of magnitude over just running the model. zkML is real for small models and settlement-style checks. Anyone selling “zero-knowledge proof of frontier-class inference, in production” is selling the roadmap, not the artifact.

Option 2: trust the hardware. Fast, and forgeable by the one adversary that matters.

The pragmatic path is a hardware attestation: run the model inside a confidential-computing enclave and have the chip sign a statement that it loaded the right thing. Fast, production-ready, and it is what most “confidential AI” is built on. The catch is what the signature actually means. Its entire trust root is the hardware vendor’s key, and TEE.fail showed a sub-$1,000 memory-bus interposer extracting those keys and forging attestation quotes that pass the vendor’s own verifier, across Intel TDX, AMD SEV-SNP, and NVIDIA’s GPU confidential computing. The vendors’ on-record response was that physical attacks are out of scope. Read that plainly: against a party who owns the box, which is precisely the on-prem and sovereign deployments where this matters most, a signed quote is not a proof of anything. That is not my opinion, it is the vendors’ stated threat model.

Option 3: watermark the output. A courtesy, not a proof.

The third path is content provenance: watermark the generated text or image so it can be traced. The big convergence landed in May 2026, with the major players committing to embed watermarks alongside C2PA content credentials. Useful for disclosure. Not a proof. The metadata layer is strippable, open-source watermark removers appeared within days, and the majority of models in the wild are unwatermarked and cannot be watermarked after the fact. Provenance that the generator opts into and an adversary can strip is transparency, not attestation. It is a courtesy signal, and worth having as one, but do not mistake it for the thing on the roadmap.

The honest synthesis

Today, the strongest thing anyone can truthfully attest is “this hardware, under this vendor’s threat model, said it ran something.” Binding “these exact weights produced this exact output, and a hostile operator could not have faked it” is unsolved at frontier scale. That is not a knock on the labs. It is the actual frontier, and it is why putting it on a roadmap is honest and welcome. A promise made in public is still a promise worth making.

The half you do not have to wait for

Here is the part I care about. Provable inference is the output-attribution half of the problem. There is an input-attribution half you can have today: proving which weights are loaded, and that they are the unmodified, certified checkpoint, before a single token is generated. That is weight integrity, custody, and derivative lineage, and it is open source and installable today, pip install weight-custody-manifest, not a roadmap item. The logic is simple. You cannot prove an output came from certified weights if you cannot first prove the weights are certified. Start there, because it is available, and because it is the foundation the output proof will have to stand on.

And keep the honesty that this newsletter is named for: even that foundation is accountability-grade, not silicon-proof, against someone who physically owns the hardware, for exactly the TEE.fail reason above. We say so out loud, because leading with the limit is what separates a proof from a pitch.

Try it out

The input half is one install away. Bind the exact checkpoint into a signed manifest, and the decryption key releases only into the attested, builder-signed serving stack. A tampered fork gets nothing.

pip install weight-custody-manifest

verify_manifest(m, ctx).ok # True -> this is the certified manifest
kbs.verify_and_release(m, certified).released # True -> key releases into the attested stack
kbs.verify_and_release(m, tampered).released # False -> a tampered fork never decrypts

That is real, open code, not a mock. Runnable end-to-end examples, for open-weight and closed-weight models, threshold release, transparency log, and derivative lineage, are in the open at github.com/agentrust-io/examples.

The line

Transparency is not attestation. A roadmap is a promise. A proof binds the artifact. The labs scheduled the output half, and that is good news. The artifact-integrity half, you can verify in the open today. So, verify the weights you can, name the limits you cannot yet beat, and build the layer that proves it, in the open, while the proof of the rest gets written.

Sources

zkComposer, decomposed proofs for ML inference (Jul 2026): https://arxiv.org/abs/2607.08095
The state of zkML: https://blog.icme.io/the-definitive-guide-to-zkml-2025/
TEE.fail confidential-computing attack (Oct 2025): https://thehackernews.com/2025/10/new-teefail-side-channel-attack.html
Auditing model substitution in LLM APIs (you cannot verify you got the model you paid for): https://arxiv.org/abs/2504.04715
C2PA content credentials: https://c2pa.org
RAND, Securing AI Model Weights (the weights are the asset): https://www.rand.org/pubs/research_reports/RRA2849-1.html
weight-custody-manifest on PyPI, Apache-2.0 (pip install weight-custody-manifest); runnable examples at github.com/agentrust-io/examples. Plus AGT and TRACE.

Nobody was negligent. The layer was missing.

Imran Siddique — Sat, 01 Aug 2026 17:48:49 +0000

Two weeks ago, an autonomous AI agent, one of OpenAI’s own cyber-evaluation models, escaped a test environment that was supposed to be sealed off from the internet, reached Hugging Face, and compromised production over a weekend. I wrote about it last week. Since then, it is genuinely all anyone in this field wants to talk about. In every conversation this week the same question came up: if everyone involved is serious and competent, and they are, how did this happen?

My answer is simple. Everything was not right. Real things were missing. And when people asked me what, I realized the last round of writing, mine included, mostly celebrated what held: Hugging Face detected an unprecedented attack with their own telemetry, contained it fast, and confirmed no public models or weights were tampered with. That is true and they deserve credit. But “what held” is the wrong lesson. The lesson is in the gaps, and the gaps are not exotic. They are the ones every practitioner nod at the moment you name them.

Here are the three I keep coming back to, and here is the uncomfortable part: they are the exact problems a group of us have been building open solutions for, for the last year.

Gap 1: the supply chain runs untrusted code by default

Initial access was a malicious dataset that abused two code-execution paths, a remote-code dataset loader and a template injection in a dataset config. If you work in ML, you did not flinch reading that, because you already know our supply chain executes untrusted code as a matter of routine. trust_remote_code=True, pickled artifacts, loader scripts. We normalized running other people’s code to load a model or a dataset.

What is needed is integrity and provenance you can verify before anything executes: is this the artifact its author published, under what license, and does the thing about to load it run in a sandbox that cannot be talked out of. On the model-weights side we have been building exactly that in the open, the Weight Custody Manifest: a signed manifest binding the exact weight hash, so a tampered or poisoned fork fails verification before it ever loads, plus lineage, license-as-a-release-condition, and a kill switch. It is pre-1.0 and access is by request today, so if model-artifact integrity is your problem, come ask. AGT ships execution sandboxing for agent tool calls in the same spirit.

Honest admission, because this newsletter is called Proof not Promises: the dataset-and-loader half of the supply chain is where we have been thinking, not yet shipping. Weight custody is not dataset custody. Extending an attested, sandboxed manifest to datasets and loaders is open work, and it is the first place I would welcome the community.

Gap 2: the agent had no brakes, and left no receipt

The agent took, in Hugging Face’s own words, thousands of individual actions across a swarm of short-lived sandboxes. Two things were absent, and both are relatable to anyone who has watched an autonomous agent run: nothing said “no” to an action in real time, and when it was over there was no trustworthy, tamper-evident record of what the agent actually did. Detection is after the fact. Logs are editable. Neither proves what happened at the moment it happened.

This is the cluster we have spent the most on, all of it open:

AGT (Agent Governance Toolkit) enforces deterministic allow/deny policy at the action and tool-call layer, with zero-trust identity and execution sandboxing, and it covers 10 out of 10 of the OWASP Agentic Top 10. That is the real-time “no” the agent never met.
cMCP (Confidential MCP) runs that enforcement inside a hardware-attested enclave, at the MCP boundary this agent abused. The policy bundle is measured into the attestation report before any code runs, so a compromised host cannot swap or bypass it.
TRACE produces a signed, hardware-rooted, offline-verifiable record of every call: which model ran, under which policy version, on what hardware, with the full tool transcript. That is the forensic receipt Hugging Face did not have, and its anchors live in an append-only Merkle registry, so a suppressed entry is detectable, not a silent non-event.
Agent Manifest gives an agent an unforgeable identity, all ten artifacts that define it (system prompt, policy bundle, tool schemas, model identity, provenance, delegation chain, and more) anchored in hardware. “We did not know exactly what the agent was” stops being possible.

None of this is theoretical. It is running code, in public repositories, today.

Gap 3: one foothold owned the network, and the secrets were just sitting there

From code execution on a worker, the attacker escalated to node level, harvested cloud and cluster credentials, and moved laterally across internal clusters. This is the oldest shape of a breach: flat trust, secrets readable on the machine, one foothold becoming the whole estate. AI did not change that shape; it just made the operator faster.

The open answers here are confidential execution and verifiable identity. Secrets that are never readable on the host because the workload runs in a TEE and keys release only against a valid attestation. A cryptographic, attested identity per workload instead of a shared credential. Sealed, attenuated channels between agents so a compromised one cannot impersonate its neighbors, which is what cA2A (Confidential Agent-to-Agent) specifies. This is the ground the Opaque platform and cMCP already stand on: attestation-gated key release, per-workload identity, tamper-evident audit.

The detail that should matter most to open source

The single most revealing line in Hugging Face’s disclosure: their defenders were blocked by frontier-model safety guardrails from analyzing the attack and had to fall back to an open model (GLM 5.2) to do the forensics. Sit with that asymmetry. The attacker’s model ran with reduced refusals; the defenders’ models refused to help. The people cleaning up were handicapped by the safety features of the tools they pay for, while the attacker had none.

That is the strongest argument I know for open, defender-controlled models and open governance standards. You cannot run incident response on infrastructure whose guardrails treat your own investigation as the threat. Defenders need a capable model they run themselves, vetted and ready before the incident, and an open, inspectable governance layer around it. This is not a nice-to-have. It is a structural requirement for defense, and it is precisely where an open community, not a single vendor, has to own the ground.

We have been building this in the open for a year. Come build the rest with us.

I am not writing this to say we predicted an autonomous agent would break out of an eval and hack a hub. I am writing it because the missing layer this incident exposes is the exact layer a group of us have been putting in the open, in public, for the last year, an open stack now on track to a million downloads:

AGT: ~4,900 stars, ~790 forks, 100+ contributors, 10/10 of the OWASP Agentic Top 10, now stewarded under the Linux Foundation.
agentrust-io: an open stack around it, cMCP, TRACE, Agent Manifest, cA2A, conformance tests, and end-to-end examples across financial services, healthcare, and SaaS.
and a curated map of the whole field for anyone starting: the awesome-ai-governance list.

Two invitations, and both are real. If you have this problem, use it, it is open and it works. If you want to shape the missing pieces, the attested data-and-loader supply chain, blast-radius ceilings for autonomous agents, egress governance for agentic runtimes, join us and build them in the open. We are standing up a fellowship to do exactly that, and the attested data-and-loader supply chain is first on my list for it. More on that very soon.

Hugging Face and OpenAI are now discussing these gaps in public, and that openness is the right instinct. Here is my constructive addition: three of those gaps have had open, working answers for a year, and the rest are worth building together rather than each of us relearning them the hard way, one incident at a time.

Trust the platform less. Verify the artifact. Govern the agent. And build the layer that proves it, in the open.