How bilateral signatures transform AI agent proof with cryptographic trust

AI agents are increasingly trusted to generate critical reports, financial forecasts, and technical analyses. But how can you prove that an agent actually authored its output? Traditional notarization only confirms that a hash existed at a given time—not who created it. A new cryptographic approach called bilateral provenance solves this by requiring agents to sign their work before notarization, creating dual signatures that independently verify both authorship and timestamp integrity.

The flaw in single-signature notarization

Current AI provenance systems rely on a single notary signature to validate that a document hash existed at a specific moment. While this proves temporal integrity, it fails to establish authorship. For example, if an agent generates a financial report and submits its hash to a notary, anyone could fabricate that hash and claim it originated from the agent. The notary only confirms that a hash was submitted—not that the agent produced the underlying content.

This gap led to the development of Bilateral Signature version 0x04, which embeds the agent's cryptographic signature into the notarized record. This creates two independent proofs: one from the agent verifying authorship, and another from the notary confirming temporal and payment integrity. Together, they eliminate the possibility of repudiation and ensure both parties can be held accountable.

How bilateral signatures work

The mechanics rely on a simple yet powerful binding mechanism. Before submitting to a notary, an AI agent signs its work hash using the Ed25519 standard. This signature, the agent’s public key, and the original work hash are combined into a binding hash using SHA-256:

binding_hash = sha256(work_hash + sig_A + agent_pubkey)

Here’s what each component represents:

• work_hash: A 32-byte SHA-256 digest of the agent’s output (e.g., a financial report or technical document).
• sig_A: A 64-byte Ed25519 signature over the raw NEP-413 buffer containing the work hash.
• agent_pubkey: The agent’s 32-byte Ed25519 public key.

The notary then signs a 175-byte payload that includes this binding hash. The resulting Provenance Data Record (PDR) remains 239 bytes in size—the same as previous versions—but now contains two cryptographic assurances. Forging such a record would require compromising both the notary’s and the agent’s private keys, doubling the security requirement.

Minimal changes, maximum impact

Despite its transformative potential, bilateral provenance introduces almost no structural changes to existing systems. The PDR format remains identical in size and layout; only the version byte shifts from 0x03 (standard) to 0x04 (bilateral). This backward compatibility ensures all existing mainnet records remain valid without migration or forks.

The notary automatically selects the appropriate version based on the presence of agent_sig and agent_pubkey in the request. If these fields are provided, the system defaults to bilateral mode. No explicit version parameter is needed, simplifying integration for developers.

The agent’s role in signing first

The process begins with the agent creating its own cryptographic proof. Here’s a step-by-step breakdown of how an agent signs its output before submission:

import hashlib
import struct
import base64
from nacl.signing import SigningKey

# Initialize the agent's Ed25519 key
agent_key = SigningKey(bytes(32))  # In production, use a real key
agent_pubkey_hex = agent_key.verify_key.encode().hex()

# Agent generates output (e.g., a financial report)
report = b"Q3 revenue projection: $2.4M based on agent analysis..."
work_hash = hashlib.sha256(report).digest()

# Prepare NEP-413 buffer: Tag + Length + Raw Hash
nep413_buffer = struct.pack("<II", 2147484061, len(work_hash)) + work_hash

# Sign the buffer using Ed25519 (no SHA-256 pre-hash)
agent_sig = agent_key.sign(nep413_buffer).signature
agent_sig_b64 = base64.b64encode(agent_sig).decode()

Key details to note:

• The agent signs the raw NEP-413 buffer, not the pre-computed hash. This aligns with NEAR’s transaction signing standards.
• The signature covers the tag, length prefix, and raw hash bytes directly.
• The resulting base64-encoded signature and public key are included in the notary request.

Notarization with dual signatures

Once the agent has signed its work, the next step is submission to the notary. The request includes the work hash, agent signature, and public key:

{
  "work_hash": "a1b2c3d4...sha256_of_output...",
  "agent_sig": "BASE64_AGENT_ED25519_SIGNATURE",
  "agent_pubkey": "HEX_AGENT_ED25519_PUBLIC_KEY"
}

The notary performs a series of validations:

1. Verifies the agent_sig against the agent_pubkey before processing any payment.
2. Confirms the EIP-3009 payment on Base (~2 seconds settlement).
3. Computes the binding hash by combining the work hash, agent signature, and public key.
4. Constructs the 239-byte PDR with version 0x04 and embeds the binding hash.
5. Signs the payload with its own Ed25519 key and returns the base64-encoded record.

The returned PDR starts with BQ in base64, which decodes to 0x04 0x01—indicating bilateral provenance. Standard PDRs begin with Aw (0x03 0x01), making version identification trivial.

Two independent paths to verification

The real value of bilateral provenance lies in its dual verification model. Each path relies on different cryptographic keys and serves a distinct purpose.

Path 1: Notary validation (temporal and payment integrity)

You can verify the PDR’s authenticity by checking the notary’s signature and blockchain anchoring:

curl -s "

A successful response confirms:

• The PDR is valid and of version 4.
• The binding hash matches the agent’s work.
• The timestamp is attested and anchored on NEAR.
• The payment was verified via EIP-3009.

For offline verification, a lightweight Python parser requires zero dependencies:

curl -sO 
python3 pdr_parser.py --pdr "BQFCAUJ..." --pubkey "490f51f23b993eacaff54fc977d9a7689ab7d4ae91504dc6cbdeadb2dbf1f462"

This proves the notary signed the record, the payment was processed, and the timestamp is immutable.

Path 2: Agent validation (authorship and content integrity)

To confirm the agent authored the document, you verify its Ed25519 signature against the work hash:

import struct
import base64
from nacl.signing import VerifyKey

agent_sig_b64 = "BASE64_AGENT_SIG"  # Retrieved from notarization response
agent_pubkey_hex = "HEX_AGENT_PUBLIC_KEY"
work_hash_hex = "a1b2c3d4...your_work_hash..."

# Convert hex strings to bytes
work_hash = bytes.fromhex(work_hash_hex)
vk = VerifyKey(bytes.fromhex(agent_pubkey_hex))

# Reconstruct NEP-413 buffer
nep413_buffer = struct.pack("<II", 2147484061, len(work_hash)) + work_hash

# Verify the signature
vk.verify(nep413_buffer, base64.b64decode(agent_sig_b64))

A successful verification proves the agent’s Ed25519 key signed the specific work hash. This eliminates any possibility of denial and ensures full accountability for AI-generated content.

A new standard for AI accountability

Bilateral provenance represents a significant leap forward in establishing trust for AI agents. By requiring dual signatures—one from the agent and one from an independent notary—this system creates a tamper-proof chain of custody for AI outputs. It doesn’t just prove that a document existed at a certain time; it proves who created it and when, all without sacrificing efficiency or compatibility.

As AI systems become more autonomous and critical to decision-making, such cryptographic assurances will be essential. The infrastructure is already in place: NEAR’s blockchain anchoring, Ed25519 signatures, and NEP-413 standards provide a robust foundation. All that’s left is adoption—ensuring that agents, notaries, and consumers recognize the value of bilateral provenance in building a more transparent and accountable AI ecosystem.