DEV Community: Imran Siddique

Approved is not the same as still admissible

Imran Siddique — Tue, 29 Sep 2026 18:38:19 +0000

Say a finance lead approves an AI agent to pay supplier invoices for the next 90 days. On day three, one of those suppliers gets flagged for fraud. The agent keeps running, and the approval record still says approved. Signed, in date, valid. Nothing in that record is wrong. It is out of date, and it has no way of knowing.

That is the problem I want to walk through this week, using our Agent Manifest.

An Agent Manifest is one signed record of everything that defines an agent when it is deployed: its prompt, its policies, its tools, its model, its data, its memory, its decision log, who it can hand work to, where it came from, and the humans who approved it. Anyone can check it later without trusting whoever runs the agent.

Human approval is one of those pieces. Our design decision on approvals checks four things: the person who approved is on the allowed list, the approval window has not run out, the approval is tied to this exact deployment, and the signature is real. The check runs offline. No call to an approval service, no dashboard to trust. Four yes-or-no answers from the record itself.

Where it stops working

All four can still be yes after the approval stopped making sense.

The record says a person approved something at a point in time. It does not say what they were relying on when they said yes, whether they can still stop the agent, or whether anybody objected. So in the invoice example the manifest verifies cleanly and the reason behind the approval is gone.

The expiry date does not fix this. An approval does not expire when the facts change on day three, and it does expire when nothing has changed on day ninety. Time is a stand-in for “still current”, and a weak one.

What we already shipped

Two small things, both on purpose.

First, PR 355, merged on 31 August, changed the spec to say plainly that an approval’s duration sets a window. It is not a promise that the approval is still current. No new field. It just stops people reading the field as something it never promised.

Second, PR 453, which shipped in agent-manifest 0.13.0 on 25 September. When all four checks pass, the verifier still says approved, and it now also says it cannot decide whether the approval still applies, because it has no evidence about the present. A result can be valid and undecided at the same time, and the README tells callers not to treat that as permission to go ahead. I like this one. The verifier now tells you what it does not know instead of staying quiet.

Who worked this out

This started as issue 348, opened by Ioana Valea on 27 August. The proposal was to record what the approver relied on, so a later check could notice when that changed.

Then @solloek369-arch raised the objection that changed the design. Everything in a manifest is fixed when it is issued; if a piece changes, you issue a new manifest. So comparing what the approver relied on against that same manifest will always match. It can never catch a change. What you compare against had to be decided first.

That split what an approver relies on into three kinds of thing: parts of the agent itself, facts about the outside world, and the approver’s own standing. Each needs a different check, and one status for all three would hide exactly the difference you care about.

Neither of them works for us. The person behind that objection described themselves as a snail on an F1 grid in this kind of work, and it is the reason the design changed. That is what an open problem is for.

Still open

Two things, and I would rather say so than wait for a tidy answer.

Deciding whether an approval still applies is open. The verifier can now say “I can’t tell”. Turning that into a real answer needs evidence about the present that the verifier does not have yet.

The words for “not established” are not settled, and that is bigger than this issue. trace-spec issue 279 is collecting the same question from six threads. A checker that cannot tell “this is false”, “this is unproven” and “nobody asked” apart will sooner or later be read as saying the first when it meant the third.

Try it on your own system

Take any approval your system records and ask three questions. What was the approver relying on, and would you find out if it changed? Who can stop this right now, and has anyone actually tried? Did anybody object, and where is that written down?

Most approval systems answer none of the three. None of them need cryptography to fix. They need you to treat an approval as a claim about today, not a receipt from last month.

If you have run a human approval step in production long enough to watch one go stale, that is what issue 348 needs next.

Functional Observation by default

Imran Siddique — Mon, 28 Sep 2026 09:00:00 +0000

The App Defense Alliance AI Agent Specification defines three kinds of lab evidence and says an untagged requirement defaults to black-box testing. None of its 37 requirements is tagged, so two that need a configuration file or system logs read as black-box passes. Filed as issue 514.

The App Defense Alliance AI Profile gained a good agent control on 22 September. Section 2.4.2, Verifiable Tool Identity and Provenance, merged through pull request 437. The agent may invoke only allowlisted tools with pinned identities, verifies server identity and catalog integrity when a session opens, rejects a tool definition that changes after pinning, and fails closed on anything unknown or revoked. Those are enforcement requirements on the agent, before the call, and I have no quarrel with any of them.

The same document has a sound idea about assessment too. Its Evidence Taxonomy, added in August for issue 411, sorts lab evidence into three kinds. Functional Observation is the assessor driving the production agent through its user and tool interfaces, with "No source-code or backend access." Attestation is a named artifact the developer supplies on request, and the taxonomy's example is log-file samples. Document Review covers policies that cannot be exercised.

Then one sentence sets the default: "where a requirement can be satisfied purely by exercising the running application, it is Functional Observation by default."

The default does the tagging

On develop the three type names occur only inside the taxonomy section. A word-boundary grep of the raw file finds Functional Observation three times, Attestation three times and Document Review twice, and none of them in any of the 37 requirement Evidence blocks. So all 37 read as Functional Observation , including two that cannot be met that way.

Section 2.4.2's Evidence block says: "Agent application, including its tool allowlist/registry configuration. Access to the user interface and the tool interface." Its first test step is to review that allowlist. Neither interface exposes it. Section 5.2.1 lists "System log files", which is the taxonomy's own example of Attestation.

The 2.4.2 step also ends "(AL0/AL1 static evidence)". The document says this version "only contains testing guidance and acceptance criteria of Assurance Level 2", and leaves AL0 and AL1 to future revisions. One file over, the AI Tool Testing Guide defines both levels as evidence "based on source code inspection", the access Functional Observation rules out.

In practice, a lab report saying 2.4.2 passed does not say whether the assessor saw the allowlist, took the developer's word for it, or read a configuration file sent over the day before. Under the default, each of those is a black-box pass.

TRACE has this problem written down about itself. The trace-spec limitations file has a section headed Platform state is not appraised, and its consequence is that "a report from a machine with SMT enabled and the alias check never completed verifies exactly as cleanly as one from a machine with neither condition." An untagged Evidence block does the same to a certification one layer up. The pass is valid. What it was bought with is not in it.

It was already proposed

The idea is not mine. Issue 411 recommended tagging each requirement. Pull request 427, which added the taxonomy and closed 411, says: "Held for WG input (not in this PR): whether to tag every requirement's Evidence block with a type (recommended)." Nothing tracked that item until issue 514. The AI Tool Testing Guide in the same profile already carries an evidence line on 38 of its 38 Evidence blocks, per assurance level rather than per type, so the working group has the habit on one side and not the other.

Timing matters because pull request 494, opened 22 September, splits the Agent Specification into a Specification and a Test Guide. On that branch the Test Guide holds 36 Evidence blocks and the Specification holds 16 Audit sections and none. Both files carry the taxonomy paragraph, identical to the byte, and both still say "Every AL2 test case in this specification". The branch was cut before 437 merged, so 2.4.2 is not in it yet; aeoess flagged that in review on 23 September.

What I filed

Issue 514 asks for a type line on each Evidence block, Functional Observation unless stated, with the named artifact for every Attestation or Document Review entry, starting with 2.4.2 and 5.2.1, and for the AL0/AL1 parenthetical to go. On 494 I asked the group to name one owner for the taxonomy before merge, since issue 400 already asks for a single source of truth on the Tool side.

The counts are word-boundary greps of the raw files on develop at 97c9f94 and on the 494 head at 1be3d9e. This is a reading of the text, not an assessment I have run.

If 494 merges first, the tags go into its Test Guide: 36 blocks now, 37 once 2.4.2 is carried over.

Checked against

Two caps, two enforcement points

Imran Siddique — Fri, 25 Sep 2026 09:00:00 +0000

The MCP TypeScript SDK's 1.30.1 patch added a 4 MiB body limit and a 100 message batch limit. On the Express path the SDK documents, the batch limit holds and the body limit is never consulted. A 100 kilobyte parser default refuses first, and the transport never hears about it.

Set maxRequestBodySize to 20 MB on an MCP server built with the TypeScript SDK's own Express factory, send it 110 kilobytes of JSON-RPC, and it answers 413. The body of that 413 is an HTML page.

Release 1.30.1 went to npm on 23 September, two months after 1.30.0. The package diff is small: three modules changed, one added, and the version string. The added module, requestBody, sets two numbers. A POST body over 4 MiB gets 413. A JSON-RPC batch longer than 100 messages gets 400 with code -32600.

Both work. They are checked in different places.

Where each one sits

The web standard transport takes a POST one of two ways. If the caller passes a pre parsed body, it uses that. Otherwise it reads the stream itself, refusing a declared Content-Length over the bound before reading anything and stopping the moment the bound is crossed. The byte cap lives inside that second branch. The batch cap sits after both branches close, so it runs on the array however it arrived.

The pull request says so. A pre parsed body "remains the way to opt out of the SDK's read entirely", and the batch bound applies on both paths. Nothing is hidden. It is also the path the documented deployment takes.

What the documented server does

createMcpExpressApp in the 1.x package mounts express.json() with no options. The Node transport's doc comment shows the handler passing req.body in as the pre parsed body. Express 5.2.1 resolves body-parser 2.3.0, whose limit defaults to 102,400 bytes.

I ran that server on 1.30.1 with the transport option set to 20 MB:

90 KB body: 200.
110 KB body: 413, text/html, from Express. The route handler ran zero times.
5 MiB body: the same HTML 413.
101 message batch: 400, code -32600, from the transport.
The same transport reading the body itself: 110 KB passes, 5 MiB gets a JSON-RPC 413 naming 4194304 bytes.

The 20 MB setting is accepted, validated (0, -1, NaN and the string "4mb" each throw a RangeError at construction) and then never read. The ceiling that fires is 100 kilobytes, owned by a component the option cannot reach. On the 1.x factory nothing can reach it: its options type has two fields, host and allowedHosts.

What the operator sees

A client gets two different 413s for one condition. One is a JSON-RPC error object. The other is an Express error page, so a client that parses errors as JSON-RPC gets HTML instead.

Monitoring splits the same way. The transport's onerror hook fired once for the 101 message batch and zero times for the 110 KB body, because the transport never ran. The only trace of that refusal is Express printing a stack to stderr through its default error handler. The parser prevented the request. The layer most teams instrument never recorded it.

The fix exists, on the other line

Issue 1354 asked for this, and pull request 1625 added a jsonLimit option in March. That landed on main, which ships as the v2 split packages. @modelcontextprotocol/express 2.0.1, published the same day as 1.30.1, has the option, and still defaults to the parser's 100 kilobytes when it is unset.

The 1.x package is the one most people install. npm counted 40.3 million downloads of @modelcontextprotocol/sdk in the week to 21 September, against 239,746 for the v2 Express package. Downloads are not deployments. The gap is still two orders of magnitude.

On 1.x, skip the factory. Build the Express app with the exported hostHeaderValidation middleware, mount express.json({ limit }) at the number you meant, and add an error handler that answers in JSON-RPC and logs where the rest of your refusals go. On v2, set jsonLimit to match maxRequestBodySize so the two numbers agree.

What did not survive checking

"The factory offers no way to change the limit." True of 1.x only. v2 has had jsonLimit since March.

"The release reordered a Host check that is not there." Partly. 1.30.1 moved the parser below Host validation, with a shipped comment saying a disallowed Host gets 403 unread. With no allowedHosts and any host other than the three loopback names, that validation is not installed. Issue 2843 already reports it on main, and a second contributor confirmed it across the Express, Hono and Fastify factories on 24 September. It is their finding, so it stays there.

The release note describes two limits. On the deployment the SDK documents, one of them is 100 kilobytes and belongs to Express.

Checked against

The evidence standard that needs a gate to count

Imran Siddique — Thu, 24 Sep 2026 09:00:00 +0000

Proof-of-Control positions itself as the evidence half of agent assurance, not runtime enforcement. Its own threshold requires an in-path gateway that withholds actions, and its threat model has no row for that gateway. Filed as issue 78.

"Enforcement decides what an agent may do; verification shows what it actually did."

That line is from the Proof-of-Control crosswalk against CSA AARM, and it is a good division of labour. The README repeats it as a boundary: under what Proof-of-Control is not, one of four entries is "Not runtime enforcement." I use the same split in my own work. A gate prevents. A signed record proves. A log has never stopped anything.

The standard, currently Working Draft v0.1.4 and open for public comment until 30 October, does not hold to it.

Where the line moves

C7.1 is called Generation at the Action Boundary. Three of its requirements describe a component that holds actions back:

7.1.1: "the agent has no network or credential path to its tools that bypasses the gateway."
7.1.3: "the gateway does not forward the action to the tool until the before record is durably written."
7.1.4 (c): "an attested enforcement point that admits only requests carrying matching evidence."

All three are Level 3. The standard's Requirement Levels table says meeting every Level 1 to 3 requirement in the claimed domains is the minimum for a Proof-of-Control claim. So nothing gets the label without an in-path, fail-closed gateway. That is enforcement, at the service, before the operation runs. Its only policy is that evidence exists, but it withholds the action all the same.

I think those requirements are right. Evidencing a policy evaluation without controlling the effect channel is how a system ends up with perfect records of decisions it never enforced, and 7.1.5 caps that case below the threshold for exactly that reason. The problem is what happened around them.

The component with no row

Appendix C is the normative threat model: 32 coverage rows. In the column describing what Proof-of-Control defends against, 12 rows use "gate" or "gates". Word-boundary matches on the raw file for gateway, intercept, interception, mediation, custody and bypass: zero for all six.

The gateway sees every action at Level 3, holds the signing keys that 7.3.2 puts out of the operator's reach, and at Level 4 refuses actions under 7.6.3 when evidence cannot be written. The CISO review found the failure case, F1, "No fail-closed requirement", and it was applied as 7.6.1 and 7.6.3. The compromise case never got a row.

The nearest row, audit tampering, is about a host rewriting the record. A compromised gateway rewrites nothing. It signs true records for the actions it lets through and writes nothing for the ones it does not, and every signature verifies.

The check that does not reach it

Here is the part that is not in the issue, and it is the part I would test first.

At Level 4, 10.3.2 requires evidence to cover every in-scope action, "demonstrated by reconciling gateway action counts against evidence-record counts over an audit window, with zero unexplained difference." Both numbers come from the gateway. An action that goes around it adds to neither count, so the reconciliation balances.

That is judgment, not a measurement. I have read the text; I have not run a conformant deployment against it. But the arithmetic does not depend on the implementation.

What I filed

Issue 78 asks for three things: two Appendix C rows, gateway compromise and gateway bypass, with honest coverage grades; the gateway operator added to the C10.2 trust-assumption disclosure; and a restated boundary. My suggested wording is that Proof-of-Control does not define the policy an agent is held to, and does require an enforcement point whose only policy is that evidence exists. Issue 79 is smaller: the one-pager still tells newcomers Tiers 3 and 4 require trusting "no one", a claim C8 has already withdrawn. Comments in the window get a published disposition.

For anyone evaluating a system that claims Proof-of-Control, ask who operates the gateway, then reconcile the tool side's own request logs against the evidence store rather than the gateway's counts. A tool call that appears in the first and not the second is the row Appendix C is missing.

Checked against

Every control plane writes the log that describes its own behaviour

Imran Siddique — Mon, 21 Sep 2026 16:41:59 +0000

An agent calls a tool. The policy engine says allow. The call goes through.

None of that proves the policy engine was not compromised. Software-only governance of MCP tool calls cannot guarantee three things, and they are worth naming separately because they fail in different ways.

The Cedar policy on disk may not be the policy that ran. A rogue admin can swap the bundle after approval, and the hash check that would catch it runs inside the same operating system that admin controls. The allow decision may have been flipped in memory, because a supply-chain CVE in the evaluator executes in the same address space as everything else. And the audit log may not reflect what happened, because any party holding the software signing key can reconstruct a valid-looking chain afterwards.

Those are not exotic. They are the ordinary consequences of running the thing that decides in the same place as the thing it decides about.

Where cMCP puts the decision

cMCP is a gateway in front of your MCP servers, and its one structural commitment is that the policy engine runs inside a hardware Trusted Execution Environment, where the agent being governed cannot reach it. Every tool call is intercepted and evaluated against a Cedar policy bundle before it goes anywhere.

The mechanism that makes that more than an assertion: before the gateway serves a single tool call, it measures its installed code, its policy bundle and its config, and binds that digest into the hardware-signed attestation report. You are not being asked to believe the gateway loaded the approved bundle. On SEV-SNP and TDX the digest sits in the report’s report_data, on Azure confidential VMs it rides in a vTPM quote that the SNP report vouches for, and on the TPM tier it is extended into a certified NV index. Either way a verifier learns which code and which policy were in force from the same evidence that establishes the enclave, and when the bundle reloads mid-session the gateway re-attests rather than leaving the old report standing.

The payloads go inside too. In a hardware deployment the tool-call payload is processed inside the enclave, so the policy decision and any redaction happen where the host cannot reach them. What the host and the connectivity provider can still read depends on the egress policy, and the upstream tool server is its own component outside the TEE. The attestation covers the gateway boundary, not what happens on the far side of it.

Deny is not the only verdict, which matters more than it sounds. A policy can redact a response rather than block the call, and the catalog carries a per-tool schema_validation_mode that selects which. A hard block on a tool an agent genuinely needs does not end in compliance, it ends in somebody routing around the gateway.

The deliverable is a signed TRACE claim, per session or per call, and a verifier checks it without trusting the operator who produced it. Run the gateway in a TEE and the claim is hardware-attested; run it in software mode and it is signed only, and the claim states which of the two it is rather than leaving a reader to assume the stronger one.

Software mode is also how you should meet it. pip install cmcp-runtime needs no hardware and gives you the whole shape of the thing before you decide whether to provision for attestation.

Version 0.5.0 shipped on 6 September. One change in it is a plain correctness win: the policy bundle hash now uses RFC 8785 canonical JSON, which is what docs/spec/cedar-policy.md section 1 always specified. Until then the implementation and its own specification disagreed on how to hash the object the entire enforcement chain anchors to.

The record it writes about itself

Here is a thing cMCP records that most gateways do not. When a session has read sensitive data and then calls a tool that leaves that sensitivity domain, the boundary crossing goes into the claim as an event. That is the difference between knowing an agent read patient records, and knowing it read patient records and then called an external API.

The check is a set membership test, and the gateway answers it from a set it holds itself. Which is where a control plane writing its own record gets interesting, because nothing outside it is checking that the set is the right one.

In 0.4.1 the set was written out by hand in session/call_log.py as {“pii”, “phi”, “pci”, “restricted”}. The vocabulary the rest of the runtime uses lives one file away in session/state.py, ranking public 0, pii 1, confidential 2, and hipaa_phi, mnpi and trade_secret all at 3.

Read those together. They intersect on pii and nothing else. phi, pci and restricted are not names the runtime uses anywhere, and all three top-tier domains were absent. So the check fired on one domain, the lowest tier above public, and a session that read HIPAA PHI then called an external tool recorded no crossing. The claim was signed, the attestation was valid, the verifier was satisfied, and the event was not in it.

0.5.0 derives the set from one COMPLIANCE_DOMAINS vocabulary, keeping the legacy spellings so no deployment loses events.

The codebase had already written this failure mode down. A docstring in state.py warns that a name dropping out of the effective vocabulary will rank 0 through a fail-open get(tag, 0) default, and names it the same class of hole that catalog-load validation was added to close. That comment sits one file away from a hand-written set holding three names the vocabulary did not have. The defence was attached to a mechanism rather than to a rule, so nothing noticed the same shape next door.

What to verify

The general form is a question you can put to any governance component, ours first: when this thing records a fact about its own behaviour, where does the vocabulary for that fact come from, and what happens when the value it sees is not in it?

Find every place your control plane holds a literal set of category names, find where those categories are actually defined, and if the two are not derived from one source, compute the intersection by hand and look at what falls outside.

Then ask what the failure does. A membership test returning False on an unrecognised value fails open, quietly, and produces a record that is correct in every field it contains. That is worse than a crash, because a signed and complete-looking claim invites more trust than an error does.

Last, check whether anything goes red when the vocabularies diverge. Not whether today’s values line up. Whether a test fails when somebody adds a seventh domain to one file and not the other.

What does your evidence say when the thing it describes uses a word your recorder has never heard?

Five Docker Sandboxes CVEs this year, all in the doors

Imran Siddique — Fri, 18 Sep 2026 09:00:00 +0000

Docker published two more CVEs against its agent sandbox on 15 September. Read alongside the three it published in June and August, all five sit in the two controls its README sells, and three of them fail the same way.

Five CVEs have been published against Docker Sandboxes this year, all by Docker as its own CNA. Two landed on 15 September, CVE-2026-77179 at CVSS 4.0 9.4 and CVE-2026-79994 at 8.7. Three came earlier: CVE-2026-12039 and CVE-2026-12539 in June, CVE-2026-18171 in August.

Docker Sandboxes runs each coding agent in its own microVM, which is the right design, and none of the five is in the hypervisor. Every one is in a component that exists to let something through it: the embedded DNS server, the ICMP egress authorizer, the virtio-fs host server (twice), and the guest to host Unix socket relay. Isolation in an agent sandbox is the wall minus every door you cut into it, and the doors are where this product has been breaking.

The README names the doors

The README lists four things under "What you get". Two of them are "File access controls between host and sandbox" and "Network access control". Sort the five records by those two lines and nothing is left over. DNS and ICMP are network access. The two virtio-fs bugs and the socket relay are file access, the relay because it reaches host sockets by filesystem path.

The first item on the same list is "YOLO mode by default: agents work without asking permission." That is a reasonable default for a product whose pitch is that the agent can run unattended, and it means those two controls are standing in for the human who would otherwise approve each action. That is my reading of the document, not something Docker says.

Three of the five made a decision once

This is the part worth taking to any sandbox, not only this one.

CVE-2026-12539: ICMP egress is blocked "with an authorizer applied only at network-creation time", and not re-applied to networks rebuilt from disk after the Docker daemon restarts.
CVE-2026-79994: the socket relay "validates that a socket path is inside an authorized workspace, but later reconnects using the pathname." A guest swaps an intermediate directory for a symlink in between.
CVE-2026-77179: the virtio-fs server "improperly follows symlinks when reopening an unlinked file from a stored path."

None of these is a missing control. The relay's check ran and was correct when it ran. The ICMP authorizer ran and was correct when it ran. Each failed because its answer was treated as durable past the moment something could change underneath it: a path that can be relinked, a network that can be rebuilt. An enforcement decision has a lifetime , and in all three the lifetime was shorter than the code assumed.

I have the same shape written down about my own work. The trace-spec LIMITATIONS file says "Signature validity is permanent; trust is not", and requires a verifier to consult revocation status at verification time, with verify_record() failing closed when the revocation store cannot answer. Different substrate, same rule. The two honest fixes are the same in both places: bind the decision to the object you act on (an open file descriptor, not a name), or re-make it at the moment of use and fail closed when you cannot.

What to ask on Monday

For each door a sandbox advertises, ask one question: when is this decision re-made? At creation only, at every connection, at every open, after a restart? If the vendor cannot answer, treat the control as holding until the first event that can invalidate it, and find out what those events are.

Two narrower things a team running this product can check today.

Platform scope. CVE-2026-77179 carries a platforms field set to MacOS and opens "On macOS". CVE-2026-79994 has no platforms field, and neither macOS nor Darwin appears anywhere in it. The README installs on macOS, Windows, Ubuntu and Rocky Linux 8. The record does not say the socket bug reaches Linux or Windows; it also does not say it is Mac only. If you run it off a Mac, read that record as applying to you.

Version. v0.42.0, released 7 September, fixes both new CVEs; the current stable is v0.43.0. The same 0.42.0 notes also say "Fixed a vulnerability where a sandboxed process could get the daemon to open a host D-Bus transport and execute an arbitrary command on the host." An NVD keyword search for Docker Sandboxes returns five records and none of them mentions D-Bus. That may simply not be assigned yet. It is a question for Docker, not a finding.

What did not survive checking

"Neither is a VM escape." Both 15 September bugs let a malicious guest act on the host, and 77179 reaches arbitrary host files "potentially achieving host code execution". They are guest to host escapes. What holds is narrower: neither is in the hypervisor.

"Both helpers checked." Only the socket relay record describes a check. The virtio-fs record describes acting on a stored path, which is the same lifetime failure without a stated validation step.

"The 9.4 record points at no code, unlike the 8.7." True, and the wrong frame. None of the three earlier records points at code either. 79994 is the exception, citing a pull request in docker/sailor and one in docker/sandboxes, and neither repository resolves for an outside account, so the code is not public in any of the five.

Checked against

Agent Mesh: what it assumes about your agents

Imran Siddique — Thu, 17 Sep 2026 20:35:49 +0000

Most agent platforms have added identity this year. Almost all of it is a name in a config file. The agent calls itself billing-agent, the log records billing-agent, and the dashboard shows billing-agent. Nobody along that path can refuse the name, because nothing about it can be checked.

Agent Mesh, the trust module in the Agent Governance Toolkit, starts somewhere more awkward. It will not let you create an agent at all unless you name a human who is answerable for it.

Everything below was run against agentmesh 5.0.0, the current agent-governance-toolkit-core release on PyPI, on my own machine, and the source references are pinned to commit 675a556 so the line numbers stay put. The module ships inside agent-governance-toolkit-core, so install that rather than the bare name: the agentmesh project on PyPI is an unrelated package last touched in 2024.

You cannot mint an anonymous agent

The factory method is AgentIdentity.create(), and sponsor is positional and required:

AgentIdentity.create(name="billing-agent", sponsor="ops@example.com", capabilities=["read:ledger"])

Pass something that is not an email address and it raises IdentityError before any key material is generated. There is no flag to skip it and no default. That single constraint is the design decision the rest of the module hangs off: every agent in the mesh traces to a person, and the registry indexes it, so get_by_sponsor() returns every agent a given human brought into existence.

If you have ever tried to answer “who owns this service account” in a mature estate, you know that question is usually unanswerable by construction. Here it is answerable by construction instead.

What you get back is an Ed25519 keypair and a DID derived from it:

did:mesh:a4082046d180d169df25e65edd7232b4

Thirty-two hex characters, one keypair, one sponsor.

The name is only worth what the signature is worth

An identity that cannot be challenged is decoration. Agent Mesh’s handshake is three phases: the caller issues a challenge carrying a 32-byte nonce with a 30 second expiry, the peer signs a payload of challenge_id:nonce:response_nonce:did, and the caller verifies the signature against the public key in the DID.

Signing and verification behave the way you would want, and it takes four lines to convince yourself:

verify correct : True

verify tampered : False

verify wrong key : False

Tamper with one byte of the payload and verification fails. Present a signature from a different agent in the same organisation and it fails. That is the part that makes the name refusable, and refusable is the whole point.

Credentials are separate from identity and short lived. The default TTL is 900 seconds, and capabilities are scoped strings with prefix wildcards, so a credential granting read:* answers True to read:ledger and False to write:ledger. Fifteen minutes is short enough that a leaked bearer token is a nuisance rather than an incident, and long enough that rotation is not in the request path.

The piece I did not expect

Buried in the handshake is an optional parameter called require_freshness. Turn it on and the challenge carries a second nonce, described in the source as an RFC 9334 freshness nonce for Evidence liveness proof. RFC 9334 is the RATS architecture, the attestation document, and this is the same construct attestation uses to prove a claim was produced now rather than replayed from a recording.

It is not decorative. The freshness nonce is concatenated into the signed payload, it is checked on the other side, and a mismatch returns an explicit Freshness nonce mismatch (RFC 9334). It also bypasses the handshake result cache, so a caller that asks for freshness gets a live exchange rather than a memoised verdict from up to fifteen minutes ago.

That matters more than it looks. It means an agent handshake and a hardware attestation can be made to answer the same question, at the same moment, under the same nonce. The identity layer and the attestation layer stop being two separate stories about the same agent.

Where a team should point its scepticism

Two things do not hold up, and both are about the gap between what is declared and what is enforced.

The sponsor is asserted, not verified. Every identity carries sponsor_verified, and it is False on creation. Their own identity specification, section 7.3, says implementations SHOULD verify sponsors, by email confirmation, SSO or a directory, before granting trust above the standard tier. Nothing in the shipped module sets it to True, and no trust decision reads it. So the accountability chain that makes the module interesting is currently a well-formed string that nobody checked.

Revocation is in-process and quiet about failure. The architecture table lists revocation propagation at five seconds or less as a key parameter, next to values that are genuinely enforced. In the code, REVOCATION_PROPAGATION_TARGET = 5 appears exactly once, at its own definition, and is never read. Revocation fires callbacks registered in the same process, inside a try that logs failures at debug level. I registered a callback that raises, revoked a credential, and revoke() returned True. The local credential was correctly invalidated. Whatever was supposed to hear about it was not told, and nothing said so.

Neither makes the module unusable. Both change what you can claim while running it.

What to do on Monday

Run it in the shape it is honest about. Use it for identity, signature verification and short-lived scoped credentials, where it does exactly what it says. Set require_freshness=True on any handshake that gates a real action, because the cached path is the default and a fifteen minute old verdict is not a liveness proof. Treat sponsor_verified as your integration point rather than a feature you have been given, and wire it to whatever your directory already knows. And do not build a containment story on revocation propagation until you have added a callback that fails loudly, because today one that fails silently looks identical to one that worked.

The check I would run first is the smallest one. Create an identity, sign a payload, flip a byte, and confirm verification fails. If that passes, the identity layer is real. Then revoke a credential with a deliberately broken listener and see what your own system does with a True that meant less than it looked.

What would change my mind on the sponsor question is a trust score that refuses to rise while sponsor_verified is False. That is one conditional, it is already specified, and it would turn the most interesting assumption in the module into an enforced one.

Verified, with nothing hashed

Imran Siddique — Thu, 17 Sep 2026 09:00:00 +0000

I ran the MCP Inspector's skill verifier against a server I wrote. A skill that advertises no digests gets the same word, the same JSON and the same exit code as one whose every file hashed clean.

Three runs against a stdio server I wrote, one skill served three ways, same command each time.

A manifest with a wrong digest: mismatch, exit 7. The same manifest with the right digest: verified, one file, exit 0. The checker works.

Then the third case. The skill declares "resources": "dynamic", which SEP-2640 defines as generated content with no digests to publish. Stdout:

"conformance":[{"code":"dynamic-resources","severity":"warning",
"message":"resources is \"dynamic\": the file set is generated, so no digest
is advertised and integrity cannot be verified."}],
"frontmatter":[],"files":[],"ok":true,"outcome":"verified"

Stderr reads Verified 1 skill and 0 files: no conformance errors. Exit 0.

Integrity cannot be verified, and the outcome is verified. One JSON line, both statements.

The flag is --verify on the Inspector's CLI. Point it at a server and it runs SEP-2640's conformance, digest and frontmatter checks over the whole catalog and turns the answer into an exit code, which is the useful part: a server author can gate CI on it. Exit 7 is a violation, 8 is a catalog it could not finish reading.

To that CI job, the dynamic case and the fully checked case are one event. Same exit code, same ok, same outcome. What carries the difference is a file count in a line on stderr and a warning row a consumer has to go looking for by severity. A pipeline reads the exit code.

The tool's own README settles what the word is supposed to mean. Its outcome table defines verified and exit 0 as "Everything was checked and everything passed." In the dynamic report, files is the empty array.

It is worth being exact about what the run does. The Inspector did call resources/read, and my server logged serving the 129 bytes. Those bytes are parsed for the frontmatter cross check and then dropped without being hashed, because the manifest declined to say what the hash should be. So something happened. Nothing was verified.

This project has already ruled on this shape once, in its own code. EXIT_CODES.SKILL_INCOMPLETE exists because a read that stopped at the size bound leaves entries unfetched, and "reporting success for a manifest whose unread entries were never fetched is a false pass." That is a third outcome and a third exit code, invented so a job that tolerates oversized catalogs can allow 8 and still fail on 7. A catalog advertising no digests at all reaches the same false pass down a different road, and it is still filed under verified.

The spec has a word for the state, and it is not that one. SEP-2640 says the "dynamic" marker exists so a host "can tell a deliberately unverifiable skill from a malformed entry", and calls a SKILL.md fetched under it "unverifiable" in the same sentence where an array-backed one is "digest-verified".

Worth saying where the ceiling is even when the digest does check out. A match proves the listing and the body agree with each other. SEP-2640 states the limit in its own text: digests are unsigned and supplied by the same server that supplies the content, a match proves the two are consistent rather than that either is trustworthy, and hosts MUST NOT treat it as a security boundary. I word boundary grepped the whole 673,250 byte CLI bundle: signature twice, both in comments about TypeScript types. signed, provenance, attestation, publisher: zero each. Nothing in this path carries authorship.

What did not survive checking

The brief I started from said this landed in 2.7.0, published on 16 September. It did not. I installed 2.6.0, from 9 September, and its --verify help text, its dynamic-resources message and its summary headline are the same strings. The behaviour is eight days old. What 2.7.0 actually changed on this path was the client capability declaration, the configurable catalog budget and a path-less URI fix.

I also drafted the fix as "add a third outcome value" before reading the review thread on PR 2293. There are already three. Round 15 replaced a two-state verdict with verified, failed and incomplete for exactly this class of reason. The ask is a fourth, and the reason it is a small ask is that the precedent is theirs.

Until something changes, the difference is readable today, and it is one field. If you gate CI on --verify, exit 0 does not tell you that anything was hashed. This does:

... --method skills/list --verify | jq -e 'select(.files | length == 0)'

A hit means a skill in that catalog was approved by a verifier that checked no bytes of it.

Checked against

Every Dependency Is a Promise Your System Has to Keep

Imran Siddique — Thu, 17 Sep 2026 05:14:19 +0000

Scaling starts with examining how many things must go right for a customer to succeed.

Illustration generated with AI.

A checkout request arrives. Before the customer sees confirmation, the system checks inventory, authorizes payment, fetches recommendations, updates loyalty points, and sends an email.

Each integration has a reasonable explanation. Together, they raise an architectural question: why should buying something depend on all of them working at the same time?

That question belongs near the beginning of a scaling discussion. It determines how much work we need to scale in the first place.

I think architecture reviews should give more attention to the conditions we attach to a successful customer outcome. Every synchronous dependency introduces another reason that outcome might be delayed or fail.

Adding capacity can help a system do more work. We should also examine how much of that work belongs on the critical path.

A useful unit of architectural complexity is the number of things that must go right together.

The critical path is a business decision

Consider the checkout example as a hypothetical design.

Inventory and payment affect whether the business can accept an order. Recommendations usually do not. An email can arrive after the order is recorded. Loyalty points may tolerate a short delay, depending on the product’s rules.

If these operations all block confirmation, the architecture has given them equal power to interrupt a purchase. That is a business decision, even if nobody explicitly made it.

Moving email off the critical path changes that decision. Customers can complete an order while the notification service is unavailable.

But the obligation to send the email still exists. It needs durable recording, retries, duplicate handling, and a way to detect messages that never arrive. Asynchronous processing introduces its own machinery.

The trade is worthwhile when separating those failure modes matters enough to justify that machinery. A queue earns its place through the independence it provides.

This is why counting services or boxes on a diagram tells us so little. A system with fewer components can still force unrelated operations to succeed together. A system with more components can isolate failures well, or simply distribute the same dependencies across a network.

The more useful measure is what happens to the customer when one component stops working.

Subtraction has a correctness floor

There is also a limit to subtraction.

Removing duplicate work can improve efficiency. Removing the check that prevents a duplicate charge changes the meaning of correctness. Both might reduce latency. Only one preserves the promise made to the customer.

Before simplifying a workflow, I would write down its non-negotiable properties in business language:

No duplicate charges. Retrying an order must not create a second charge.
Durable confirmation. A confirmed order must survive an application restart.
Customer isolation. One customer must never receive another customer’s data.

Those statements establish a floor beneath the optimization work. The team can change implementation, sequencing, and infrastructure while preserving the properties that make the service trustworthy.

Review the journey, then the components

This gives architecture reviews a more concrete starting point.

Take one important customer journey. Identify everything it waits for. For each dependency, explain why its result is necessary before success can be reported. Then examine what happens when it is slow, unavailable, or returns an ambiguous result.

Some dependencies will deserve stronger protection. Some can move later. Some may exist because an old feature or assumption was never retired.

The resulting work may be less visible than a platform migration. It can still produce a substantial architectural improvement: fewer opportunities for unrelated failures to interrupt the same customer action.

Make simplification visible

Leadership incentives matter here. New infrastructure has a launch date and an owner. Removing an unnecessary dependency is easier to overlook. If we want teams to simplify, we need to recognize outcomes such as fewer coordinated releases, fewer failure modes reaching customers, and less operational work per completed transaction.

The same reasoning applies when adding AI to a workflow. If a model becomes another blocking dependency, its latency and availability become part of the customer’s experience. Its place in the architecture should follow from the value of its contribution and the behavior required when that contribution is unavailable.

Before approving the next component, I would ask the team to show which customer promise requires it, what happens when it fails, and which existing responsibility it replaces. Those answers make the cost of the decision visible.

This is the thinking behind Scale by Subtraction, which I explore in my book, Architecting at Scale.

One repository answered the same question twice on 11 September

Imran Siddique — Wed, 16 Sep 2026 09:00:00 +0000

Four hours apart, awslabs/mcp merged a parser-based read-only policy for one database server and twenty more regex keywords for another. I installed the published package and found the keyword answer still has a gap the parser answer cannot have.

On 11 September, four hours apart, the awslabs/mcp repository merged two fixes for the same class of problem, and they do not agree with each other.

At 15:31 UTC, commit f6aec97 landed a parser-based read-only policy for the Postgres server (#4575). It deletes that server's regex mutable-SQL detector and replaces it with a guard built on pglast, which is PostgreSQL's own parser compiled in. The module says why in one line: identifiers, quoting, comments and Unicode escapes can no longer disguise an operation, because the guard and the database read the same bytes the same way. The check for the statement behind CVE-2026-87911 is now a field on a parse-tree node, not a pattern.

At 19:22 UTC, commit a55a1a8 answered the same problem for the MySQL server (#4615) by adding roughly twenty more keywords to a regex.

Both are on main. Both are real work. Only one of them changes what kind of thing the control is.

Why the difference is measurable

The MySQL gate already took a CVE for this, CVE-2026-85788. AWS described it exactly: the check matches SQL text with patterns that expect literal whitespace between keywords, MySQL treats a comment as whitespace, so a comment wedged between two words walked straight through. The fix strips comments before the scan. It works. I checked it.

The class is not closed, because a comment is not the only thing MySQL treats as whitespace. A second space is too.

I installed the current published package, version 1.1.2, uploaded 8 September, and called the shipped read-only gate directly. It is two functions, and nothing else stands between a tool call and the database. One space between the two words of a multi-word keyword is rejected. Two spaces, a tab or a newline between the same two words returns an empty list from the keyword scan and an empty list from the injection heuristic, which together are the server's whole rejection path. I have sent the specific statements to the AWS vulnerability reporting page, which is where the repository's own contributing guide says security findings go instead of a public issue, so they are not in this note.

The cause is one expression. The pattern is built by escaping the whole phrase, which bakes a single literal space into the middle of it. Most entries survive that because their first word is blocked on its own. CREATE FUNCTION is covered because CREATE is. A couple have no such cover.

The repository already contains the fix

Two of the four keyword detectors in the same monorepo, for SQL Server and Oracle, build the identical pattern by splitting the phrase on spaces and joining the words with a whitespace class. I ran Oracle's detector against every multi-word keyword it has, under one space, two spaces and a newline. Blocked every time.

So the regex approach can be made whitespace-correct, and somebody in this repository already did it, in a file next door. The small fix is a two-line copy.

Worth saying: the Aurora DSQL detector uses the same escape-the-whole-phrase construction as MySQL, and gets away with it only because a second set of anchored regexes catches the same statements a different way. It is the same latent bug, one server over, currently masked. All of this is still a small fix to a text filter.

What the parser commit says about itself

The Postgres guard is careful about its own status. It calls itself defense-in-depth, not a security boundary, and names the authoritative control as the least-privilege database role. AWS says the same in both advisories. That is the correct position, and it is worth sitting with, because it means the read-only switch in a tool server was never the enforcement point. The grant is. A log of what the agent asked for proves what happened; only the role decides what can happen.

Which leaves a question the repository has now put to itself twice. The Redshift server switched to a parser in June. Postgres switched on 11 September. A parse tree cannot be fooled by whitespace, comments, case or Unicode escapes, because it is not reading text. A keyword list can be fooled by all four, and each one costs an advisory and a release to find out about. Four of these servers are still on the keyword list. Two of them have stopped, and the newer one's own comment explains why.

Checked against

The alias check I wired up was bypassed in September 2025

Imran Siddique — Tue, 15 Sep 2026 09:00:00 +0000

DDRop landed on 14 September and walks past the platform appraisal policy I shipped three weeks ago. Reading it sent me to a paper from last year that had already walked past the same check, by the same four people, for under $50.

Two things happened on 14 September. Google merged my documentation fix to go-sev-guest, closing the issue I filed in August about which PlatformInfo fields are ceilings and which are floors. And DDRop was published.

DDRop is a DDR5 RDIMM interposer from KU Leuven, ETH Zurich, Durham and Google, going to CCS in November. It injects parity errors on the command and address lines so the register clock driver rejects the command, then disconnects the ALERT line so the CPU is never told to re-issue it. Writes are silently discarded. The paper's first contribution line puts the build at under $200. Table 1 puts the commercial equivalent, Membuster on DDR4, at about $170,000.

Intel TDX, Intel Scalable SGX and AMD SEV-SNP are all affected, because, in the authors' words, "to maintain memory performance, scalable cloud TEEs omit cryptographic freshness guarantees". The processor can tell that memory is encrypted. It cannot tell that it is current.

Three weeks ago I shipped appraise_platform_info into agent-manifest so a verifier could require alias_check_complete, the bit where AMD firmware reports that its boot-time DRAM alias check finished and found nothing. I wrote in LIMITATIONS.md that this "lets a verifier insist the silicon says it did its own check".

The part I got wrong, and it is not DDRop

DDRop has overtaken the check. That framing also lets me off.

The check was already bypassed when I shipped it. Battering RAM, disclosed on 30 September 2025, is a $47.62 DDR4 interposer that sits in the memory path "behaving transparently during startup and passing all trust checks", then flips to malicious at runtime. Its own summary says it "can circumvent Intel's and AMD's boot-time alias checks" and that it "breaks SEV's attestation feature on fully patched systems". AMD advised on it as SB-3024. Four of its authors are DDRop authors.

So on 20 August I required a bit whose published bypass was ten months old, and I described it as the one platform assertion bearing on physical access. Across agent-manifest, trace-spec, cmcp and ca2a, and across all twelve notes on this site, the string battering appears zero times. I had read about BadRAM and cited SB-3015. I had not read the paper that followed it.

What DDRop adds

DDRop is not the same attack. Aliasing by grounding address lines does not work on DDR5, where commands are multi-cycle and grounding two lines corrupts eight logical bits. Write suppression is the way in instead, at native bus speed with no downclocking.

Then section 6.3 does something the alias check was never in the conversation for. Using injected secure page table entries, an attacker gets plaintext write access to its own TD's control structure, overwrites its own MRTD at offset 0x240 with the victim workload's expected measurement, and clears a validity flag at 0x3F2 to force a recompute. The authors confirm "the quote returned by TDG.MR.REPORT now contains the maliciously injected launch measurement". Every check my offline TDX verifier performs still passes, because the report is genuine and it is the measurement that is a lie. The paper also notes that cryptographic integrity mode would stop its other two case studies and not this one, since the forged structure is written under the correct key, and that its own test BIOS could not confirm that.

What the vendors actually said

The two responses are not the same and they are being reported as though they were.

AMD SB-3048 says the technique "falls outside the scope of the published threat model for SEV-SNP" and that AMD "does not plan to assign a CVE or release mitigations in response to this report". Intel's announcement also puts it outside the standard threat model, says nothing about CVEs either way, and then says Intel is evaluating hardening and detection, "including the development of Platform Owner Endorsements which enable remote parties to establish who is in physical possession of the hardware sensitive workloads are running on".

The out-of-scope position is not news from this week either. Both vendors took it a year ago, for Battering RAM.

Where I land

The policy stays. It does what it says, and requiring the bit is still better than not requiring it, because it catches the lie BadRAM told, an SPD chip reporting a module larger than it is. What changes is the sentence around it, and LIMITATIONS.md now owes a line naming Battering RAM, which is the honest version of "does its own check".

The mitigation vectors I declined to appraise in August are the next question rather than a closed one. I said I would be guessing without hardware; I have SEV-SNP silicon and go-sev-guest v0.15.0 ships reference minimums to validate a mask against.

And I have been writing for months that no confidential computing silicon is custody grade against an adversary who owns the machine, treating custody as the thing outside the report by definition. A vendor has now said in a security advisory that it intends to put custody in the report. I do not know whether Platform Owner Endorsements will work, and a verifier cannot appraise a field that does not exist yet. But I stated that boundary as permanent, twice, and it is the second time in a month that something I filed under unattestable turned out to be somebody's roadmap.

Checked against

Deep-dive: how the public TRACE Registry is built to be distrusted

Imran Siddique — Mon, 14 Sep 2026 16:12:24 +0000

On September 9, the Cloud Security Alliance hosted a briefing on the emerging chain of custody for AI agents: verified identity, attenuated delegation, hardware-signed proof of what an agent actually ran, and a governance framework that appraises agents against that evidence. Alongside it, something concrete shipped. The TRACE trust registry went public, as an open repository plus a verifier on PyPI. There is no hosted service and no query endpoint, deliberately. TRACE is an agentrust-io open specification that OPAQUE implements, not an OPAQUE product. Repository and verifier: github.com/agentrust-io/trace-registry.

What the registry is for, in one breath: AI agents increasingly act on behalf of people and companies, and the parties on the other side of those actions need more than a vendor’s word for what actually ran. A TRACE record is a signed evidence envelope describing what ran, under whose authority, and with what supporting attestations. Where hardware attestation is present, a verifier can validate that evidence rather than rely on the operator’s description. The registry is the public, append-only place those records are anchored, so a counterparty, an auditor or a regulator can later check what was claimed and when, without asking anyone’s permission. Think of it as the public notary column for agent attestations: the records stay wherever their owners keep them, and the registry pins their existence and their history.

Opening the code was the point. In Imran’s words: “you cannot ask anyone to trust a record you control. You publish it and let strangers check the math, including the ones who would enjoy catching you.”

This post is the engineering deep-dive: how the registry is built so that you do not have to trust the people who run it. Including us.

The design problem

A registry’s job is to be believed by strangers. But any registry publishes its own history. Signatures prove records are authentic, not that everyone sees the same set, which is the split-view problem. And “trust our database” fails exactly when it matters: disputes, audits, adversaries.

The requirements that fall out: append-only history with cheap proofs at any scale, verification that works offline, nothing sensitive leaving anyone’s infrastructure by default, and an integrity anchor that lives outside the operator.

How it is built: an append-only log, checkpointed

The registry’s checkpointed portion is an append-only Merkle Mountain Range, with the existing per-batch RFC 6962 inclusion proofs unchanged underneath. MMRs suit evidence logs. Appending never rewrites what came before, so a proof you saved last month still verifies today. Inclusion and consistency proofs stay small at any log size, and the structure suits local-first logs that sync later.

On a cadence driven by activity rather than a heartbeat, the log emits a checkpoint of a few hundred content-free bytes: the log size, the accumulator root derived from the MMR peaks, the previous checkpoint’s size and commitment, the issuer key id, and a consistency proof back to the previous checkpoint. The registry signs it as deterministic JSON with Ed25519, matching the shipped capsule-emit shape. A COSE_Sign1 wire encoding is a coordinated follow-up across the implementations, not what ships today. No payloads, and no metadata about record contents. The chained reference to the previous checkpoint lets a verifier check, across consecutive checkpoints, that the log is a strict extension of its past, which is a consistency guarantee on top of integrity.

Three things about this design are worth naming.

Interop by construction. The registry and our own logs follow the same checkpoint discipline: a log size, a commitment over the accumulator, a chained reference to the previous checkpoint and an issuer key, under different field names and two wire formats. The registry signs deterministic JSON carrying a single peaks-derived root; the capsule ledger signs COSE_Sign1 carrying a peak list. What holds today is the same discipline, a published name mapping and two wires, with convergence on one wire as the coordinated follow-up. The disciplines match because they are the same construction. The registry’s checkpoint layer is the CLL append-only MMR with its signed, consistency-checkable checkpoints, contributed to the registry in the open by Action State Group and reviewed and merged by its maintainers (trace-registry #54), pinned against the same MMRIVER draft test vector as the capsule ledger. The registry’s verifier checks the witness’s receipts end to end; the witness checks the registry’s checkpoint signature before countersigning. The registry’s log carries TRACE records, the capsule ledger carries Agent Action Capsule records, and the checkpoint layer never sees either. That is why evidence from two different record formats ends up comparable instead of parallel.

Disclose later. Nothing is pushed to a transparency service upfront. You keep evidence local, checkpoint it cheaply and continuously, and if a dispute or an audit ever needs a specific record, you disclose it then, already provably unrewritten since the checkpoint that covered it. Accountability without a firehose of data leaving your infrastructure.

It is live. Checkpoint 1 is published and checkable: log_id trace-registry/v1, mmr_size 1, root 3af8ddf2c1f429bb4fc670437e48640887f60de809b18f8ccea55fefb0c6639a. The registry holds two entries today, one of them checkpointed, and checkpoint 1 sits at registry/2026/09/01.ndjson in the repository next to the verifier.

Cross-witnessing: the part no operator can do alone

Checkpoints are submitted to an independent witness, witness.agentactioncapsule.org, free and public, operated by Action State Group: a different company, with different incentives, keeping its own log. The witness countersigns the checkpoints it is sent and publishes them in its own log.

What that stamp says, exactly: it proves inclusion of the checkpoint under the witness’s key. Whether a receipt also carries a witness-observed time or a signed grade is a property of that receipt, so the registry’s verifier reports witness_time_established and grade_cryptographically_bound rather than asserting either. Read those two fields rather than this sentence. For the September 7 capture both are false, because that receipt signs the log root rather than a clock and reports its grade outside the signature, and those values are permanent for that receipt. The witness began signing a registration time and a grade on September 12, but it registers a checkpoint by a content-addressed hash, so submitting checkpoint 1 again returns the receipt it already has. The next checkpoint, when the log advances for a real reason, will carry both fields. Its signed grade will be countersigned-observed: this registry is enrolled as a foreign accumulator, which the witness observes and countersigns without verifying the registry’s own consistency proofs. The witness attests the bytes it saw. Continuity is a property a verifier computes across stamps, not one the witness certifies.

On September 7 the registry submitted checkpoint 1’s existing JSON bytes through the enrolled route and fetched the stamp back by log id and by digest. All three responses carried the same receipt, leaf 936 of a 937-leaf witness tree, and the registry’s standalone verifier checked the registry signature, the checkpoint-to-receipt binding and the witness signature under a pinned key, offline. The captured evidence, the verifier and the negative tests that fail when either signature check is removed are in the registry repository.

Action State Group is a witness here, not the witness. A log can anchor into several witnesses in parallel or run its own, and bring-your-own-witness stays first class. Witnessing a digest attests inclusion under the witness’s key and never endorses content, which is the same rule the witness applies to everyone. Plurality is an engineering property, not a courtesy. Because both logs are Merkle Mountain Ranges, a witness holds no entry data at all: a few hundred bytes per checkpoint, whatever the size of the log behind it. A witness enrolled to verify a log’s own accumulator can additionally check each checkpoint against its predecessor with a logarithmic consistency proof; this registry is enrolled the other way, by design: observed and countersigned, not verified. Either way the cost of being a witness stays small, which is why neither of us treats the witness seat as something to own. It is also the security argument: sustained equivocation means fooling every witness a verifier consults at once, so the number of independent witnesses is the parameter that matters, and the cost of being one is what sets that number.

From the moment a checkpoint is countersigned, the covered history is pinned. Rewriting a record means producing a commitment that contradicts a checkpoint already sitting in someone else’s log, and showing different histories to different people means fooling independent operators at once.

That cuts against the usual vendor script. With the witness in place, you do not have to trust OPAQUE, and you do not have to trust Action State either. Neither of us is asking to be believed.

If you want to check: the whole audit, offline

Who you must trust: no one’s word, only public keys and open-source math. Every step runs offline with published tooling, and all three checks are one install, pip install “trace-verify[witness]”: trace-verify for inclusion, trace-verify chain for the checkpoint chain, and trace-verify receipt for the witness receipt. None needs a clone of the registry. The capsule side runs the same three checks with its own tooling, against its own log and the same witness: inclusion, chain consistency, countersigned receipt. Same construction, two toolchains.

What this proves, and what it does not

Witnessing proves the integrity and consistency of the published history: what was recorded has not been rewritten, and the history the witness observed is pinned outside the registry operator. That does not by itself mean every reader was shown the same view; detecting a split view still requires comparing against the witness, another observer or another witness. It does not prove the log is a complete account of reality either, and more witnesses do not help: a party that never records something has nothing to witness. Closing that gap takes the other side of the exchange: the counterparty’s own record of it, and a way to ask for it where an answer, a refusal, and an absence are three different, attributable things rather than the same silence. That is the next piece of work.

Two more limits, named outright. The registry’s June 2026 entry predates checkpointing and is deliberately never folded into the log retroactively, so the chain proves consistency of what it covers, not coverage of the registry. And the producer key behind the first anchored record verifies that record and will never sign another, because the demo that produced it generates keys per run. Trust infrastructure that overstates its guarantees is worse than none. The grade is signed under a private-use COSE label agreed bilaterally between the registry and the witness, not a registered one. A third implementer must not read it as standard, and it moves if a registered label is ever assigned.

Check our work

The trace registry: github.com/agentrust-io/trace-registry, with the verifier and checkpoint 1 at registry/2026/09/01.ndjson.
TRACE, an open specification series at LF Projects: trace.agentrust-io.com.
The checkpoint mechanism: The Checkpointed Local Log, an IETF Internet-Draft in progress.
The reference stack: capsule-emit, whose seal() produces signed, chained records; checkpointed-local-log, the MMR log and its checkpoints; and capsule-anchor, the witness service, one Apache-2.0 deployment you can run yourself.
The verifiers and conformance vectors: verify.agentactioncapsule.org, with vectors in the agent-action-capsule and checkpointed-local-log repositories.

You do not have to use either of our services. Run the code and check the math.

Open artifacts to build on

The pieces are open standards on purpose, because what matters is what gets built on them, on both sides of the evidence. On the producing side, anyone already logging receipts, whether an agent platform, a marketplace or another registry, can get these properties without handing anyone their data. Where you wrote log(), write seal(): the record composes, chains and gets witnessed, and yesterday’s log file becomes evidence. A few hundred content-free bytes is the entire disclosure. On the consuming side, checkpoints, receipts and proofs are stable, specified artifacts rather than vendor APIs, so auditors’ checklists, GRC tooling and assurance frameworks can verify any conforming log with one implementation instead of one integration per vendor. Interoperable evidence is what makes an assurance ecosystem possible, and it is the layer we are both betting on.

The specifications live where open work belongs, at the IETF (SCITT and COSE) and the Linux Foundation (TRACE), and the work continues there. More logs and more witnesses are welcome. Becoming a witness takes an honest clock and a public key: capsule-anchor is Apache-2.0, and enrolling a log’s declared wire form is one configuration entry.

“Agent actions are becoming the records that matter, and records only count when a disinterested party can vouch for their history. The witness attests inclusion, never content, on identical terms for this registry, for our own logs, and for anyone who shows up with a checkpoint.” Steven Mih, Action State Group