AI agents increasingly act across APIs, browsers, enterprise systems, and payment workflows. That creates a difficult accountability problem: how can another system verify what an agent did, which policy allowed it, what data it used, and whether the record was altered later?
A portable signed record for AI agents solves this by packaging an agent action, its context, and its evidence into a machine-readable object protected by a digital signature. The record can move between vendors and remain independently verifiable without requiring every participant to trust the same database or platform.
What Is a Portable Signed Record for AI Agents?
A portable signed record is a tamper-evident, transferable data object that describes an AI agent event and proves who—or what—signed it. Typical events include:
- A recommendation generated for a customer
- A tool call made to an external API
- A document retrieved or transformed
- A human approval or rejection
- A transaction initiated under a spending policy
- A model evaluation, safety check, or policy decision
“Portable” means the record is not locked to one agent framework, cloud provider, logging system, or database. “Signed” means a verifier can detect modification and authenticate the signing key or delegated identity.
A useful record normally includes the event payload, timestamps, identifiers, cryptographic hashes, policy references, signature metadata, and optional evidence links. It should be possible to export the record as JSON, store it in an object store or ledger, and verify it later using published public keys.
Why AI Agents Need Signed Records
Traditional application logs are usually controlled by the service that generated them. They can be useful operationally, but they do not automatically provide portable proof. An agent operating across multiple organisations needs stronger guarantees.
Accountability across systems
An agent may plan in one system, call tools in another, and produce an outcome in a third. A signed record creates a common evidence layer linking those events.
Protection against tampering
A cryptographic signature protects the integrity of the signed bytes. If a field such as the destination account, tool response, timestamp, or approval status changes, signature verification fails.
Auditable delegation
Agents often act under authority delegated by a user, company, or another agent. Records can express that chain: who authorised the action, which policy applied, and whether the agent exceeded its scope.
Vendor and framework independence
Portable records reduce lock-in. A company can migrate from one orchestration framework to another while preserving historical evidence in a standard format.
Dispute resolution
When an automated decision is challenged, a signed event record can help establish what the agent received, what it produced, and which controls were active at the time.
Core Data Model
A practical schema should separate the event itself from its cryptographic proof. The following fields form a useful baseline:
record_id: Globally unique identifier for the eventrecord_type: Event category, such astool_call,approval, ordecisionissuer: Entity or agent responsible for issuing the recordsubject: User, account, case, or resource affected by the eventagent_id: Stable identifier for the agent instance or agent classparent_id: Previous event or parent record in the causal chaintimestamp: Creation time, preferably in UTC with a clear precisionpayload: Structured event-specific contentpolicy_ref: Versioned policy, rule, or permission referenceinput_hash: Digest of material inputs, where disclosure is restrictedoutput_hash: Digest of the resulting output or artifactevidence_refs: Links or content identifiers for supporting evidencekey_id: Identifier for the signing keysignature: Digital signature over a canonical representationsignature_algorithm: Algorithm and encoding used
A minimal JSON representation might look like this:
{
"record_id": "urn:agent:event:01J...",