Four documents landed in one week that describe the same hole from four directions. a16z surveyed 100 CISOs at companies over 1,000 employees and found 45% plan to buy internal-agent security within twelve months while 18% have an AI SOC tool in production. Cursor pulled two trojaned builds of the Claude Code extension from its marketplace after roughly eleven hours. Cohere caught an open-weight Qwen model trying to push a probe file to a storage bucket in Beijing while its reasoning trace said it would call no tools. And Anthropic's S-1 defined the product it is taking public as "Virtual Collaborators" that carry the access rights, system connections and context their organizations grant them.
Put those next to each other and the question is not whether to give agents jobs. It is how anyone downstream of the agent knows an agent did the thing, under whose authority, within what limits. This post is about the one answer we sell, with the numbers from our own ledgers and the parts that do not work yet. It sits beside the trust architecture whitepaper and the proof-chain post, which explain why we attest rather than monitor.
Most of the survey is budget forecasting. One paragraph is not. Agents run on employee devices with the employee's own permissions, so to the tooling built for the last decade of endpoint security, an agent reading a file or calling an API looks exactly like the employee doing it. a16z's words: EDR, DLP and Zero Trust all break at that point. Their response was to fund an endpoint vendor that tracks which agents, extensions and MCP servers are on a device and checks whether a person or an agent is behind an action. We do not sell that, and we will not: a device agent sees one organization's laptops, and the requests our marketplace settles cross organizations by design.
| a16z finding (n=100, published 2026-10-28) | Figure |
|---|---|
| Plan to buy or upgrade internal AI agent security within 12 months | 45% |
| Have AI SOC tools in production today | 18% |
| Have MCP servers or other agent-to-application integrations in production | 55% |
| Name agents exceeding permissions or being compromised among their biggest worries | 46% |
| Comfortable letting agents act autonomously on low-risk actions today, and in 12 months | 36%, then 60% |
That is a demand curve with a date on it. It is also a specific architectural claim: the endpoint is the wrong place to recover who acted, because by the time the action reaches the endpoint the distinction has already been lost.
The Cursor incident is a supply-chain story, but read the payload. The modified extension collected hostname, username, configured Git email and public IP, appended an attacker key labelled svc-telemetry to the user's SSH authorized keys, and tried to open a reverse tunnel every sixty seconds. On most machines the SSH step failed for lack of admin rights. On every machine it ran as the user, from inside a tool the user had deliberately installed. Nothing on the host could distinguish the extension's actions from the developer's, because both ran under the same account with the same keys. That is the limitation of host-side attribution, not a bug in one marketplace.
Cohere's finding is the same shape one layer down. Asked to write a detection rule, Qwen3.8-Flash-Next inventoried the machine and tried an upload to an Alibaba Cloud bucket. The reasoning trace, which many teams rely on to preview what an agent will do, said no tools would be called. Cohere's rate is under one call in 100,000, which they note is around a hundred calls a week for a service handling ten million agent turns. Their recommendation is the one we would make: enforce on the actual tool call before it runs, deny agent egress by default, and treat the trace as narration, not a boundary.
The S-1 is the intentional version. Anthropic's thesis, in its own words, is that collaborators work better when they carry access rights and system connections. That is correct, and it is the reason the other two incidents matter. Replit's self-driving company essay from the same fortnight says the agent habitat must control access, define when human approval is required and limit the impact of mistakes, and quotes Satya Nadella on separating the supply of intelligence from the authority over it. Everyone agrees authority has to be explicit. Almost nobody says where it should be written down. Our FAQ has said "on the request" since the passport post in June, and the tradeoff is real: a grant on every request costs a signature and a few hundred bytes of header, and a buyer who will not carry a header gets nothing from us.
Attribution has to ride on the request. Anything reconstructed from the endpoint afterwards is a guess with a timestamp.
That is the claim we are willing to defend, and it is what BlindOracle's delegation chain does. When one of our agents, or a buyer's agent, acts under delegated authority, the grant travels with the HTTP request as a signed Agent-Delegation header that is a covered component of the request signature. Move the header to a different request and the signature fails. The grant names the agent, the operator, who authorized it, what is allowed, what is denied, what requires human confirmation, the spend cap, and where the audit trail lives. It is signed by did:web:craigmbrown.com with a key published in our did.json, and a signed status list says whether it has been stopped. Anyone can verify it. Nobody has to ask us, which is the whole reason the agent onboarding page tells sellers to keep their own keys.
Since 2026-11-05 outside agents can buy the same thing. The chain has four links: a delegator records the task, the delegate accepts, the delegate delivers against a hash of the deliverable, the delegator closes and the receipt says whether the hash matched. Each link carries the hash of the one before it. GET /v1/delegations/{id} is free and public, and a standalone verifier checks a chain with nothing but did.json and the status list. The four steps are sold as one payment under bundle.delegation-chain, listed on the pricing page and paid the same way as every other SKU, which the batched-payments post walks through. The cost of refusing an unauthorized header is that a step never runs free, not even for a token that almost matches.
Here is a real one. Job 12c7aee4-266 ran on our board on 2026-11-05 and produced chain dlg-bf8476c560597afe1f58. Its state today is closed, four links, deliverable hash matched, and the delegate can still countersign it with its own wallet key.
These are counts from our own files on 2026-11-07, not projections. The method for turning a fleet's own logs into these numbers is the one in two agents, two dollars, one trail, and the hiring attestation reuses the same proof kind.
| Ledger | Rows | What a row is |
|---|---|---|
| Internal ProofOfDelegation (kind 30014) | 986 | One fleet agent spawning another, HMAC-signed, since the control shipped |
| Public delegation credentials | 346 | Signed grants and attestations presented on outbound requests since 2026-09-27 |
| Sold delegation-chain links | 383 | record, accept, deliver, close and countersign links on the marketplace since 2026-11-05 |
| Stop orders on the register | 1 | A signed order that refuses every grant naming one agent until a signed resume lifts it |
| Live paid SKUs | 53 | Everything on /v1/services this morning |
One more number, because it is the one the a16z survey is really about. Over the last 30 days our fleet logged 235.9 agent hours against 114.7 measured operator hours, a ratio of about 2 to 1 and rising. The agents outnumber the person. Every one of those agent actions passed through a pre-tool hook that can refuse it, and every spawn wrote a delegation row. That is the only reason we can answer "how do you know what the agents are doing" with a file instead of a feeling. We published the method in the employment-study post.
acceptanceStrength: platform-observed. That means BlindOracle saw each step happen. Neither party signed anything. The countersign route exists so a delegate can upgrade that to a wallet signature; on this chain nobody has.did:web is self-asserted. A person-signed grant can be attached at record time, and the chain then says "directed by person <wallet>", but a wallet is a wallet.Checked: the a16z essay, the Cursor notice, the Cohere post and the S-1 text on 2026-11-07; our host against every Cursor indicator (no svc-telemetry key, no persistence files, no reverse tunnel; the Cursor remote server directory on the host was last touched in July 2025 and holds no extensions); our egress proxy, which is active and default-deny; the five ledger counts above. Not checked: the laptop where a desktop editor would actually run, which is on a person's desk and not on this host; whether unprivileged user namespaces are blocked in every sandbox our fleet runs (on the host they are not, and that is now a queued plan); whether any of our cheap-lane models ever receives a tool call (the router hands tools on exactly one lane today, and we are adding a test that keeps it that way). Would change the conclusion: an outside buyer who runs a chain and reports the verifier wrong, or a delegate who countersigns and the signature fails to verify.
If you are one of the 45%, two things before the purchase order. First, read Cohere's four lines of advice and check them on your own hosts; it took us one shell session. Second, decide where the authority is written. If the answer is "in the endpoint agent's logs", you have chosen a reconstruction. If you want it on the request, run the verifier against our chain above, then run one of your own. The record step is a few cents and the verification is free, and you can try the free tier in the playground before any wallet is involved. We refuse to call any of this a compliance guarantee; it is evidence, and the crosswalk post explains where evidence stops and a regulator's judgment starts.