What Signed Receipts Prove—and What They Do Not

🎥 The YouTube version is also available:

How to Verify AI Agent Actions: Pipelock Receipts and the AI Execution Boundary

Books: Runtime Al Governance Practical Guide: Dynamic Al Governance Design through Knowledge Flow, Trust Engine, and Decision Trace

Pipelock’s Receipt is a mechanism that leaves a signed record at the execution boundary mediating an AI agent’s external communications:

When a particular agent or workload attempted what type of communication, to which destination, under which policy evaluation, and whether it was allowed or denied.

This is stronger than a standard application log. It makes it difficult to edit the record afterward and claim that a communication was not allowed or that a block never occurred. It also allows the decision recorded by the boundary device to be presented to a third party capable of verifying the signature.

For example, suppose an agent attempts to access an external API through an MCP tool. Pipelock can evaluate the destination, the content being sent, the presence of secrets, reachability to internal networks, and indications of dangerous instructions or tool poisoning against policy. If it denies the request, it can leave that decision as a Receipt.

In that sense, Pipelock is an Execution Boundary that protects the moment immediately before an AI agent acts on the outside world. It is also a powerful component for leaving the decisions made there as a Decision Trace.

The important point, however, is that a Receipt proves only this:

That the boundary device made a particular decision in accordance with the rules that were in effect at that time.

A Receipt alone does not demonstrate that the organization as a whole is properly governed.

1. It does not prove that the rules themselves are correct

Pipelock executes the policies it has been configured with. If an allow-list contains overly broad destinations, if secret-detection rules are weak, or if a rule allowing external transmission has been configured incorrectly, Pipelock may issue a Receipt showing that the request was allowed under that incorrect rule.

A signed Receipt shows that the system acted according to the rules. It does not show that the rules were appropriate.

This requires separation of duties among policy authors, approvers, and change operators, along with approval, expiration, and review processes for rule changes. Especially in production environments, the organization must manage—outside Pipelock—who authorized which destinations, data types, and operations for which business purpose.

2. It cannot record communications that do not pass through the boundary

Even if an agent is correctly configured to use Pipelock, communications may bypass its observation and control scope through a different network path, different credentials, an unmanaged MCP server, a direct SDK call, or an external tool introduced by a developer.

This is similar to securing a front gate while leaving a back door open.

Making an execution boundary effective therefore requires more than deploying a proxy. It requires a network design that blocks egress by default and permits only approved paths; secret management that prevents credentials from being placed directly in agent environments; registration, signing, and inventory management for MCP servers; and privilege separation for containers and execution environments.

3. A safe communication does not mean the agent’s decision was correct

Pipelock can judge whether a transmission is dangerous or whether it may be sent to a particular destination. But an agent may still misunderstand the business context, rely on outdated data, misinterpret the purpose of its delegation, or overlook an important exception. If the communication itself conforms to policy, it may be allowed despite those mistakes.

For example, a procurement assessment agent may send quotation information to an authorized supplier API in the correct format. But if sending that quotation required approval from a responsible person, transmission safety and business correctness are separate issues.

This is where a business-level Decision Trace becomes necessary:

• What was the purpose of the operation?
• Which data, rules, and evidence were used?
• Which authority and delegation agreement justified it?
• Why was the outcome Act rather than Ask or Stop?
• Who approved, overrode, or returned the decision, and when?

Only with these records can a communication record be connected to the actual business decision.

4. A Receipt does not guarantee an “honest operator”

If an operator can freely control the Receipt signing key, change policies, and manage log retention alone, the audit trail has clear limits. Problems such as inserting malicious rules, retaining only favorable Receipts, replacing keys, or preparing a path that bypasses the boundary cannot be solved by a Receipt alone.

At a minimum, reducing this risk requires the following design:

• Version-control policy changes in Git or an equivalent system, with approval history.
• Protect Receipt signing keys in an HSM or KMS, with separated key-use permissions.
• Forward Receipts to tamper-resistant external ledgers or WORM storage.
• Bind policy versions, agent versions, MCP server versions, and execution-environment configuration hashes to each Receipt.
• Route high-risk operations through a Human Gate, with approval records and Receipts cross-referenced.
• Regularly audit whether actual egress paths match the communications recorded in Receipts.

In other words, Receipts do not create trust. They are important but bounded evidence for making trust verifiable.

Positioning Within the Runtime OS

Within the Runtime OS, Pipelock primarily serves the Execution Boundary layer.

The purpose of introducing Pipelock is not to delegate the entire task of “making agents safe” to a single product.

Rather, it is to ensure that an agent’s actions pass through an inspectable boundary at least at the point of external execution, and that the resulting decisions are retained in a verifiable form. Only when those Receipts are connected to delegation agreements, authority, human-in-the-loop controls, business rules, and a Decision Trace Ledger does an organization gain an AI operating foundation that can be explained and stopped.

Chinoba

Chinoba

Intelligence as Relationship

Research Platform

founded by

Masao Watanabe

AI Systems Architecture
Decision Trace
Human–AI Coordination
Algorithmic Governance