RFC 6750 defines the property that makes a stolen header dangerous. A bearer token is one \"with the property that any party in possession of the token (a \"bearer\") can use the token in any way that any other party in possession of it can.\"
\nAn LLM provider key is that kind of credential. Anthropic's API overview, read on 3 October 2026, lists Authorization: Bearer <token> where the token is \"your API key or a short-lived access token\", with x-api-key as a legacy fallback. If an agent's environment leaks, the provider cannot tell the thief from the agent.
A signed request changes what the server checks. The agent keeps a private key. Each request carries a signature that only that key could produce over that request. Copying the headers off the wire does not give the thief a second valid request.
\nRFC 9421 is the standard way to do this over HTTP. Its abstract says it describes \"a mechanism for creating, encoding, and verifying digital signatures or message authentication codes over components of an HTTP message.\" The rest of this entry is about the parts the RFC leaves to the application, because those are where agent deployments go wrong.
\nA signature covers a list of named components. Some are headers, such as content-type. Some are derived values, written with an @, such as @method, @path and @authority. The signer builds a text block called the signature base, one line per component, and ends it with an @signature-params line that repeats the component list and the parameters. It signs those bytes.
The RFC's own Ed25519 example, from appendix B.2.6, shows the shape. Its line wrapping follows RFC 8792.
\n\"date\": Tue, 20 Apr 2021 02:07:55 GMT\n\"@method\": POST\n\"@path\": /foo\n\"@authority\": example.com\n\"content-type\": application/json\n\"content-length\": 18\n\"@signature-params\": (\"date\" \"@method\" \"@path\" \"@authority\" \\\n \"content-type\" \"content-length\");created=1618884473\\\n ;keyid=\"test-key-ed25519\"The result travels in two headers. Signature-Input repeats the component list and parameters. Signature carries the signature itself:
Signature-Input: sig-b26=(\"date\" \"@method\" \"@path\" \"@authority\" \\\n \"content-type\" \"content-length\");created=1618884473\\\n ;keyid=\"test-key-ed25519\"Section 2.3 defines the parameters a signer can attach. Four matter for agents:
\n| Parameter | RFC 9421 wording | Use for an agent |
|---|---|---|
created | \"Creation time as a UNIX timestamp value of type Integer\" | When the agent signed |
expires | \"Expiration time as a UNIX timestamp value of type Integer\" | A short life for a captured request |
nonce | \"A random unique value generated for this signature as a String value\" | Detecting a repeat |
keyid | \"The identifier for the key material as a String value\" | Which key to verify with |
Verification (section 3.2) rebuilds the signature base from the received message and the declared components, then checks the signature against the key. The list of covered components comes from the sender's Signature-Input header, so the verifier has to decide whether that list is enough. That point comes back below.
Look at the example again. It covers content-type and content-length, but nothing in it commits to the JSON that follows. For an agent that matters: the body holds the model name, the token limit and the prompt, which is where the cost is decided.
Section 7.2.8 is direct about it. The specification \"does not provide coverage for the content of an HTTP message under the signature, in either a request or a response.\" It points to the Content-Digest field from RFC 9530, which \"can be used in requests and responses to communicate digests that are calculated using a hashing algorithm applied to the actual message content.\" Once the field exists, you list content-digest as a covered component like any header.
The digest covers exact bytes. RFC 9421 section 7.2.8 and RFC 9530 use the same JSON object and give different digests:
\n{\"hello\": \"world\"} sha-256=:X48E9qOokqqrvdts8nOJRJN3OWDUoyWxBf7kbu9DBPE=:\n{\"hello\": \"world\"}\\n sha-256=:RK/0qy18MlBSVnWgjwz6lZEWjP/lF5HF9bvEF8FabDg=:RFC 9421 shows the first value. RFC 9530 shows the second next to Content-Length: 19, one byte more than the 18 in the RFC 9421 example. Computing SHA-256 over both byte strings gives exactly those two values: the second input ends in a newline. A client that re-serializes JSON after hashing, or a proxy that reflows it, produces a mismatch even though the data means the same thing. Hash the bytes you send.
A digest alone is not protection either. RFC 9530 section 6.1 warns: \"In the absence of additional security mechanisms, an on-path malicious actor can either remove a digest value entirely or substitute it with a new digest value computed over manipulated representation data or content.\" The signature over content-digest is the additional mechanism. Remove the digest from the covered list and the body is unprotected again.
Section 7.2.2 describes the failure plainly. \"The most extreme form of this would be a signature over no message components. If such a signature were intercepted, it could be replayed at will by an attacker, attached to any HTTP message.\" Even with good coverage, \"a given signature could be applied to two similar HTTP messages.\"
\nThe RFC's remedies are layered. Cover enough of the message to tell it from others. Add nonce \"to allow the verifier to detect replay of the signature itself if a nonce value is repeated\". Add created and expires, \"limiting the utility of a captured signature value.\"
Two consequences for an implementer:
\nexpires, with a margin for clock differences, so a captured request cannot pass in the last instant of its window.A short expires makes the store small. A signature that lives 30 seconds needs 30 seconds of nonce memory, not a day's.
Section 1.4 puts the burden on whoever deploys it. \"An application or profile of this specification MUST specify, at a minimum\" the set of components and parameters \"that are expected and required to be included in the covered components list\", plus how to find the key and which algorithms are acceptable.
\nThe reason is that Signature-Input is written by the sender. A valid signature over (\"@method\") proves the sender holds the key and said something about the method. It proves nothing about the path or the body. A verifier that checks the signature and does not compare the declared components against its own required list accepts a signature that binds almost nothing.
A written policy for an agent gateway then reads like a checklist: required components (@method, @path, @authority, content-digest), required parameters (created, expires, nonce, keyid), a maximum lifetime, an expected key for this agent, and a refusal for anything else. Refuse by default and say which rule failed, so the refusal can be recorded.
Parsing matters too. Structured Fields allow parameters on inner-list members. A header such as (\"@method\";a=\"@path\") covers only @method, even though a text scan sees both names. A verifier has to parse the list, not search it.
RFC 9421 leaves the profile open. Web Bot Auth is one profile aimed at automated HTTP clients. Cloudflare's documentation, read on 3 October 2026, describes it as a way to \"verify bot identity using cryptographic HTTP message signatures\". It says to attach three headers, Signature, Signature-Input and Signature-Agent, to a bot's requests, that the tag parameter should equal web-bot-auth, and that \"Cloudflare's implementation of Web Bot Auth does not support every component and parameter defined in IETF RFC 9421.\"
The profile is moving. The IETF datatracker lists draft-ietf-webbotauth-httpsig-protocol-00, an active working-group draft dated 1 September 2026. It requires created, expires, keyid (as a JWK SHA-256 thumbprint) and tag=\"web-bot-auth\", and at least one of @authority or @target-uri. It recommends expiry \"no more than 24 hours\". It defines Signature-Agent as a Dictionary Structured Header whose members are strings containing https URIs, notes that earlier versions used a bare string, and says signers \"MUST send the dictionary form\". It also says implementations \"MUST NOT use shared HMAC\".
That last rule is a useful test for any agent scheme. If a verifier and a client share a secret, the verifier can forge requests, and a stolen verifier database is a set of working credentials. An asymmetric key avoids that.
\nTreat the draft's numbers as a snapshot. It is a -00 document and the earlier individual drafts it replaced have already expired.
Mandare's gateway (the \"door\") can require an RFC 9421 signature from each agent. The concept docs say agents \"sign every request under their key (RFC 9421 HTTP Message Signatures, with a Content-Digest over the exact body bytes)\", described under Passport in the concepts page. The implementation is the request-signature source file in the passport package, using the web-bot-auth npm package at version 0.1.3, whose npm metadata points to Cloudflare's web-bot-auth repository on GitHub. This applies to the CLI at v0.1.0, which npm view @mandarelabs/cli version reported on 3 October 2026.
What the code does, as it reads:
\n@method, @path, @authority, content-digest and signature-agent. A signature that covers fewer is refused with COMPONENTS_NOT_COVERED, and so is a Signature-Input whose inner-list members carry parameters.WRONG_KEY.BODY_DIGEST_MISMATCH; a repeated nonce with REPLAYED_NONCE.The unit tests in packages/passport/test/request-signature.test.ts cover each of those refusals. Once identity is proven, the gateway's later refusals are ledger entries, shown with spend caps in a runaway loop that dies at €20, and the ledger itself is described in why it holds proofs, not data.
Limits, stated next to what they limit:
\n401 with code PASSPORT_MISSING, and expects the ledger to hold zero entries. Refusals after identity is proven, such as a killed agent's call, are recorded with the agent's DID.Signature-Agent header carries the agent's did:key as a quoted string, and keyid is the SHA-256 hex of the raw public key. The draft requires https URIs in a dictionary and a JWK thumbprint as keyid. We make no claim that a Mandare-signed request passes a Web Bot Auth verifier.mandare kill <agent-did> is documented in the CLI reference.Every activity-recording system faces the same question sooner or later: who watches the record? If your agents' complete history — every API call, every payment, every approval — sits on a vendor's servers, that vendor is now the most valuable target in your stack. It can be breached. It can be subpoenaed. It can quietly become a data business. Enterprises know this, which is why \"send us your full agent telemetry\" is a hard sell to exactly the buyers who need accountability most.
\n\nMandare is local-first: the ledger — the append-only, hash-chained record of everything your agents did — lives on your machine. We never see its contents. What leaves your machine is a content-free cryptographic fingerprint, sent to a witness you choose — a second machine of your own or a third party: a hash that commits to the record's state without revealing a single byte of what's in it.
\n\n77014fc7fd8b70f0c785abb2e37179225f7de8b22f99187495770cad6a881a66\n a fingerprint — enough to check integrity, nothing to read, leak, or subpoena\n
\nThat fingerprint is not decoration. Because each entry is hash-linked to the previous one and signed by the infrastructure that wrote it — the door the agent passed through, never the agent itself — any later edit to an entry breaks the chain visibly, and mandare verify names the entry. Dropping the newest entries is subtler: the shorter file still verifies on its own. That's what the witness is for. Run on infrastructure you don't control, with the verifier holding the door key out-of-band, it makes truncation and rollback detectable too. The record's integrity becomes publicly checkable while its contents stay private.
Nothing to leak. We can't lose, sell, or be forced to hand over what we never hold. Your agents' activity is not our asset; its integrity is.
\nNothing custodial. Mandare never holds the money either — no float, no banking license, no counterparty risk hiding in the fine print. Limits are enforced at the doors; funds never touch us.
\nEvidence that convinces skeptics. An auditor or a finance team doesn't have to trust your agent's self-report — agents demonstrably misreport their own actions — or trust us. They verify the chain themselves. Verification is free, for anyone, forever; the verifier is open source (Apache-2.0). You can see exactly what that verification looks like in a runaway loop dying at €20, where the refusal itself becomes a checkable ledger entry.
\n\nThe cryptography here is deliberately boring: HTTP Message Signatures (RFC 9421) for signed requests, a JWK Set key directory for publishing door keys (modelled on the Web Bot Auth directory drafts; we make no claim that a Web Bot Auth verifier accepts a Mandare signature or directory), SD-JWT VC for credentials, did:key for identifiers. Mandare's job is to compose the standards the web is already adopting — and to fit into that world rather than fight it.
\n\nIn an industry nervous about AI oversight, an oversight layer that cannot surveil you is rare. That's not a compromise we accepted. It's the design. The full picture — identity, mandates, and this ledger — lives on the Mandare homepage.
", "image": "https://mandarelabs.com/journal/og/proofs-not-data.png", "date_published": "2026-07-23T09:00:00+00:00", "date_modified": "2026-10-04T09:00:00+00:00", "tags": [ "Design" ] }, { "id": "https://mandarelabs.com/journal/runaway-loop-dies-at-20", "url": "https://mandarelabs.com/journal/runaway-loop-dies-at-20", "title": "A runaway agent loop dies at €20", "summary": "71 API calls in 0.1 seconds. Call #72 refused by a mandate signed once — and the refusal becomes tamper-evident evidence. Real transcript, no mockups.", "content_html": "The most common way an AI agent hurts its owner isn't malice. It's a loop. A retry that always fails, a plan that keeps \"making progress\" against an API that keeps billing, a sub-task that spawns the same sub-task. Left alone overnight, it bills all night — and in most teams, nobody can even say which agent spent what.
\n\nThe uncomfortable part: the agent can't be argued out of it. A loop looks like work from the inside. Asking the model to \"be careful with spend\" is a suggestion, not a control — and per-action approval prompts don't help either, because people approve 93% of them (Anthropic's figure for Claude Code) and attention fades. If the stop is going to happen, it has to happen outside the agent.
\n\nIn Mandare, the owner signs a mandate once: this agent may spend €5 per call, €20 per day, €100 in total. The agent never sees a permission prompt again — it works freely inside that boundary. But every call it makes must pass through a door (the gateway) that checks the mandate before anything is spent. The agent doesn't enforce its own limits, so it can't talk itself past them.
\n\nHere's what happens when we deliberately release a runaway loop against that door:
\n\n# mandate signed ONCE: €5/call · €20/day · €100 total\n# releasing a runaway loop — it will NOT stop itself…\n\ncall # 1 200 OK ~€0.28 spent so far\ncall # 10 200 OK ~€2.78\ncall # 30 200 OK ~€8.33\ncall # 50 200 OK ~€13.89\ncall # 70 200 OK ~€19.45\ncall # 72 403 DENIED — THE LOOP DIES HERE\n code: PER_DAY_EXCEEDED\n reason: reserved 0.00 + settled 19.72 + estimate 0.28 > cap 20.00\n the refusal itself is ledger entry 92938e3617eb03c8…\n\n# the runaway made 71 calls in 0.1s before the mandate killed itSeventy-one calls went through in a tenth of a second — far faster than any human could react, faster than any dashboard alert could fire. The seventy-second call was refused at the door. Total damage: €19.72, against a €20 cap. (This is the no-docker pnpm demo; the docker quickstart runs the stack's real defaults and stops at call #24, €19.17 settled.)
Stopping the loop is half the story. The other half: every one of those calls — including the refusal — was written to an append-only, hash-chained ledger by the door, never by the agent. Intent is logged before the action runs; results are logged as they settle. Then anyone can verify the record:
\n\n$ mandare verify --db ledger.db --spend\nentries: 143\nchain: VALID — every entry hash-linked and door-signed\nspend: settled 19.723587 EUR · 71 call(s) · 1 refused\n #142 RESULT settle 0.277797 EUR\n #143 DENIED refused 0.277803 EUR ← refused by policy\ncounters: CONSISTENT — equal to a fresh replay of the ledgerThat last line matters more than it looks: the running totals aren't a second source of truth that could drift — they're checked against a full replay of the ledger itself. And critically, that ledger lives on your machine, not ours — all that ever leaves it is a content-free fingerprint for a witness you choose, which is a design choice worth its own entry: proofs, not data. When a finance team asks \"what did this agent actually spend, and why did it stop?\", the answer isn't a screenshot or an agent's self-report. It's a verifiable file.
\nOne honest caveat about this run: pnpm demo has no witness. Any edited entry fails verification, but dropping the newest entries — the refusal included — leaves a shorter ledger that still verifies. That's what a witness on separate infrastructure (or a saved --prev-head) catches; the docker quickstart runs one, and pnpm demo:witness shows it catching exactly that.
Because the boundary is enforced by infrastructure the agent must pass through, it holds in every failure mode that matters: the agent loops — capped. The agent is prompt-injected into ambition — capped. The agent's credential is stolen and driven by an attacker — still capped, because the mandate binds the credential, not the agent's intentions. The human signed once; the mandate did the saying-no.
\n\nThis demo is one of five that CI runs on every push — a stolen credential turning to dead paper, one mandate replacing forty approval prompts, a card declining at the network (so far against a Stripe mock that signs webhooks like Stripe), and a witness catching a truncated ledger are the other four. All five are in the open-source repo. You can also see the whole system on the Mandare homepage.
", "image": "https://mandarelabs.com/journal/og/runaway-loop-dies-at-20.png", "date_published": "2026-07-23T08:00:00+00:00", "date_modified": "2026-10-04T08:00:00+00:00", "tags": [ "Demos" ] } ] }