Industries · AI & autonomous agents

Every agent action, signed.

For teams running fleets of agents across databases, code, mail and payment rails: R-Series turns each intent, delegation, tool call and approval into a hybrid-signed receipt that names its parent, chains into a Merkle root and verifies offline. Spend and autonomy stay behind a human gate, and the approval is a receipt too.

Follow one delegation Wrap a tool call

SignatureEd25519 + ML-DSA-65

MCP shimIn development

Spend & autonomyOff until a human GO

StatusIn development

00 The question after every agent incident

Which agent did it, on whose authority, and what changed?

Agent logs answer from the vendor's database. Receipts answer from mathematics.

An agent fleet is a chain of authority. A person states a goal; an orchestrator splits it into tasks; sub-agents call tools through MCP servers and connectors; those tools write to databases, open pull requests, send mail and move money. When something goes wrong, the investigation needs every link of that chain, and today it is assembled from activity logs held by each vendor, which the vendor can change and nobody outside can verify.

R-Series sits underneath the fleet. It does not replace your models, frameworks or tools. At the boundary where an agent touches a system, each action becomes a receipt: canonical bytes, a SHA-256 digest, the intent and the policy that applied, a commitment to what came back, and the parent it descends from. Receipts link into a chain and the chain rolls up into a Merkle root.

Every receipt carries two signatures, Ed25519 and ML-DSA-65, and a verifier requires both. Anyone holding the issuer's public keys can check a run offline, in a browser or in CI, without asking DCS. Public anchoring of roots is in development; a receipt must verify with the anchor absent.

Autonomy is only safe when every action can be proven later.

01 One loop, every action

Intent, action, receipt, chain, root.

The same five steps apply whether the action is a model call, a database read, a repository write or a refund. Only the profile fields change.

Intent→Policy check→Human gate (spend · autonomy)→Action via adapter→Receipt · Ed25519 + ML-DSA-65→Chain by parent→Merkle root→Offline verify

01 · INTENT

The goal is recorded first

An intent receipt records who asked for what, before any agent acts. Everything after it names a parent that leads back here.

In production

02 · ACTION

The boundary emits the receipt

The MCP shim receipts each tools/call; Connector OS receipts each hop through an adapter. Your agent code and your tools do not change.

In development

03 · SIGN

Two signatures, both required

Ed25519 for verification everyone can do today; ML-DSA-65 so the record stays trustworthy as classical signatures age. A missing leg is a failure, not a warning.

In development

04 · CHAIN

Parents by content address

Each receipt points to its parent by content ID and carries a per-key sequence, so an inserted, removed or reordered action shows up.

In development

05 · ROOT

One root for a whole run

Chains roll up into Merkle trees under the RFC 6962 rules used by Certificate Transparency, with inclusion and consistency proofs. Public anchoring of roots is in development; a receipt must verify with the anchor absent.

In development

06 · VERIFY

No call home

Algorithms are published; the public verifier kit is a demo until our strict-verification release. A reviewer checks bytes, digest, both signature legs and the inclusion path without any DCS service in the path.

In development

02 One delegation, end to end

Who delegated what, signed at every hop.

Delegation01 / 06

01 · INTENT

A named human states the goal.

The run begins with an intent receipt: who asked, what for, under which policy. It is the root of the authority tree, so every later action can be walked back to it.

Receipts hold hashes of inputs, not the content itself
The intent is signed like any other receipt

02 · DELEGATE

Authority is split, scoped and signed.

The orchestrator hands each sub-agent a narrower task: read the data lake, write a repository branch, prepare a payment, operate a field device. Each hand-off is a receipt that names its parent, so the scope a sub-agent held is on the record.

Approvals and delegated authority as signed receipts: in production in our own product
Dedicated delegation-grant objects: designed, not built yet

03 · ACT

Every tool call through an adapter becomes evidence.

Sub-agents work as they already do. The MCP shim sits between an agent and its MCP servers; Connector OS sits between agents and business systems. Each call returns its normal result plus a hybrid-signed receipt carrying the tool, its version, the server, an idempotency key and commitments to request and response.

MCP shim: in development
Connector OS: in development

04 · HUMAN GATE

Spend waits for a person.

The finance agent's payment is held at the gate. A named human approves or rejects; issuing, consuming and revoking that approval are governance receipts, and the payment receipt carries a reference to the approval it relied on. The same applies to raising autonomy and to the kill switch.

Money movement stays dark until a human GO
Policy before money moves; shadow mode first

05 · LINK LOSS

The link drops. The chain doesn't.

A field agent loses its uplink and keeps working. Recorder segments are sealed and chained locally with the next sequence number; receipts are minted on the ground on reconnect, the buffered chain is reconciled, and a gap or a reorder would break the sequence and show.

Pattern from our space and autonomous systems work: in development

06 · ROLL UP

One root, and a path back to a person.

All receipts roll into a Merkle root. A reviewer picks any action, say the payment, and walks its parents: payment, finance agent, orchestrator, the human who asked, with the approval on the side. Each link is a signature they verify themselves.

Inclusion proofs per receipt (RFC 6962)
Public anchoring: in development

03 Governance and the human gate

Agents propose. People open the gate.

The riskiest things an agent can do are spend money, act in production and widen its own autonomy. In R-Series these stay off until a named human approves, and the approval is itself a receipt, so "who allowed this?" has a signed answer.

Every policy decision, approval, rejection, escalation and kill-switch use is designed as a governance receipt. The pattern is in production in our own product today.

Agent action	Default	What the record shows	State
Read data, call a model, draft	Allowed by policy	Action receipt with tool, version, request and response commitments	In development
Write to a repository or record	Allowed within the delegated scope	Action receipt naming the parent hand-off and the side-effect class	In development
Move money (refund, payout, transfer)	Held at the human gate	Approval receipt, then a payment receipt that references it	In development
Raise an agent's autonomy	Held at the human gate	Governance receipt with the approver and the new scope	In production
Kill switch engaged or lifted	Any authorised human	Governance receipt for each engage and each lift	In production
Production signing keys	Created only after certification, at the epoch-0 ceremony	Key events receipted with epochs (who could sign, and when it stopped)	Planned

04 Where receipts are produced

At the boundary, not inside your agents.

Most teams meet R-Series in one of three places. None of them asks you to change your model, your agent framework or your tools.

MCP

The MCP shim

Sits between an agent and its MCP servers and emits a hybrid receipt for every tools/call. No change to the tools themselves.

In development

CONNECTOR OS

Adapters to business systems

Connectors to CRMs, ERPs, data lakes, mail and payment rails, with an Operations Agent Layer that observes, diagnoses, plans and acts, behind policy and human approval. Connector OS holds no cryptography of its own; the engine signs.

In development

ENGINE

Direct, over HTTP

Call the signing engine from any language through the S1 HTTP edge, with hybrid key exchange at the edge.

/v1/verify_chain

In development

Small links. Field gateways and constrained devices can carry the same receipt in a compact deterministic encoding. It is a wire encoding, not a second format.

05 Multi-agent hand-offs

What a receipt says about the actor, the authority and the effect.

Question after an incident	Where the answer lives	State
Which agent acted?	Requesting agent and service identity; one identity per lane, registered under a root	In development
On whose authority?	Parent link back to the hand-off and the intent; approving human on gated actions	In development
Which tool, which build?	Connector, connector version, tool name and version, MCP server	In development
What actually happened downstream?	Request and response commitments, provider request ID, reconciliation state	In development
Was the agent's key valid then?	Registry root and key epoch inside every v2 receipt; revocation reported apart from integrity	In development
Which organisation and assurance level?	Optional identity block: issuing organisation, assurance level, salted principal, binding proof	In development
Was anything removed or reordered?	Per-key sequence; a gap fails integrity when the full stream is supplied, and is flagged as unverifiable on a partial set	In development

Honest boundary. Hand-offs are recorded today as parent links and governance receipts. Dedicated delegation objects (a grant, a tool authorisation, effect evidence) are designed and wait on a schema freeze; we label them as design, not product.

06 Decisions under link loss

When nobody can reach the agent, it still keeps the record.

Edge agents, robots and remote platforms keep deciding when the network is gone. R-Series treats the link state as evidence: connected, degraded, lost, reconnect. Out of contact, recorder segments are sealed locally with the next sequence number; receipts are minted on the ground on reconnect, and the chain is reconciled and cosigned or anchored.

Gaps are first-class: absence of evidence is never treated as evidence of absence. A coverage statement records what was observed, what was not, and the gap intervals. This pattern comes from our space and autonomous systems work and is in development.

CONNECTED

Stream

Receipts reach the ledger within moments.

DEGRADED

Seal first

Every recorder segment is sealed locally; delivery is not a precondition.

LOST

Keep the chain

Hash commitments and sealing only on board, never a stateful signer.

RECONNECT

Reconcile

Check the sequence is gap-free, record the reconciliation, cosign.

In development The link-loss pattern is simulated today; offline decision receipts are not issued yet.

07 Record-keeping duties

Evidence that supports AI-regulation logging duties.

The EU AI Act asks high-risk systems to allow automatic logging of events over their lifetime (Article 12) and effective human oversight (Article 14); under its 2026 amendment these duties apply from 2 Dec 2027 (Annex III systems) and 2 Aug 2028 (Annex I systems). Receipts are designed to support those duties with evidence an auditor checks offline. They do not make a system compliant, and no mapping has been assessed by an outside body.

Duty (summarised)	Evidence a receipt chain supplies	State
Automatic logging of events	A receipt per action, emitted at the boundary rather than written by the agent itself	In development
Logs that cannot be quietly edited	Parent links, per-key sequence and Merkle inclusion; an insertion or deletion breaks the proof	In development
Traceability of the system's operation	Tool, version, MCP server, request and response commitments on each action	In development
Human oversight	Approval, rejection, escalation and kill-switch receipts, referenced by the action they allowed	In production
Records kept for years	Hybrid signatures now; archive signatures (SLH-DSA), renewal receipts and an external witness later	In development
Show a property without handing over records	Zero-knowledge proofs over a receipt set, e.g. "every write had a human approval"	Planned

How to read this. The intended audit mapping also covers SOC 2, ISO 27001, ISO 42001, GDPR and sector IT controls. It is a design intention. A receipt is evidence of what happened; it supports your controls and does not replace legal review.

08 What we will not claim

Labels before adjectives.

An agent-trust product that overstates itself defeats its own purpose. These are the lines we hold on this page and in every briefing.

CERTIFICATION

None claimed yet

No layer has passed certification yet and the independent external audit is still ahead. Nothing here is a compliance stamp.

Planned

ANCHORING

Anchoring in development

Public anchoring of roots is in development. A receipt must verify with the anchor absent.

In development

MONEY

Dark until a human GO

Real money movement through agents stays switched off until a human opens it.

In development

09 Working with an agent team

From one wrapped tool call to a governed fleet.

STAGE 1

Wrap one tool

Put the MCP shim in front of one agent's MCP server and get a receipt per call.

No change to the tools

STAGE 2

Verify it yourselves

Check sample receipts offline with the demo verifier kit, in CI or in the browser.

STAGE 3

Shadow the fleet

Receipts emitted alongside real workflows through adapters, observe-only, governance in shadow mode.

Spend and autonomy stay off

STAGE 4

Open the gates

A named human opens spend or autonomy per scope; each opening is a governance receipt.

10 Questions

From teams running agents.

Do we have to change our models or agent framework?

No. Receipts are produced at the boundary, through the MCP shim, Connector OS or the engine over HTTP. How an agent reasons and which model it uses stay the same.

Does it slow the agent down?

Signing a canonical receipt takes milliseconds. Anchoring happens in batches, away from the request path.

Can we see which sub-agent did what in a multi-agent run?

Yes. Every receipt names its parent, so a run forms a chain from the intent through each hand-off to each tool call. Dedicated delegation-grant objects are designed but not built yet; we say so rather than imply them.

What stops an agent from spending money on its own?

Spend and autonomy stay off until a named human approves, and the approval is a governance receipt that the payment receipt references. Real money movement through agents is dark until a human GO.

What if an agent's key is compromised?

Keys are registered with epochs. The key-lifecycle layer (in development) records which key was valid when, so a verifier can reject receipts signed after a revocation and still judge earlier ones.

Does this make us EU AI Act compliant?

No. Receipts supply evidence that supports record-keeping and human-oversight duties. Compliance is a legal assessment of your whole system, which a receipt does not replace.

Where is our data stored?

Receipts carry hashes and commitments, not content. Your data stays in your systems; receipts and anchors are stored where your policy requires.

Is it production-ready?

Receipts are in production in our own product (Website Maker). The newer engine is release candidate 4, running on staging, and its further layers are in development; certification and an independent external audit are planned.

Let your agents act. Keep the proof.

Hybrid-signed receipts at every hop, a human on the gates that matter, and a chain anyone can verify without asking us.

Request a briefing See verification

In development — talk to us about a design partnership.

Want the details for your sector? Book a briefing — we share the full design and a live demo in a private session.