AI agents increasingly act across browsers, APIs, enterprise systems, wallets, and physical devices. When an agent books a service, changes a record, approves a workflow, or delegates a task, other systems need to verify what happened, who authorized it, and whether the evidence was altered. Portable signed records for agents address this problem by packaging machine-readable event data with cryptographic signatures that can travel between systems.
This article explains the architecture, cryptography, data models, trust decisions, implementation patterns, and India-specific considerations for building portable signed records into production-grade agent systems.
What Are Portable Signed Records for Agents?
A portable signed record is a digitally signed, structured statement that can be stored and verified independently of the system that created it. In an agentic workflow, the record may describe:
- The agent, user, organisation, or service responsible for an action
- The task requested and the authority under which it was performed
- Inputs, outputs, tool calls, and policy decisions
- Timestamps, expiration limits, and sequence information
- The result, status, or human approval associated with the action
- References to larger files, logs, or external evidence
“Portable” means the record is not locked inside a vendor-specific database. It can be exported as JSON, transmitted through an API, embedded in a message, stored in object storage, or presented to a verifier in another environment. “Signed” means a verifier can check integrity and provenance using a public key or another trusted verification method.
A signed record does not automatically prove that an agent behaved correctly. It proves that a particular key signed particular content. Reliable systems therefore combine signatures with identity binding, authorization, timestamps, revocation, secure key management, and policy evaluation.
Why Agent Systems Need Portable Evidence
Traditional application logs are useful for debugging, but they are often difficult to verify outside the application that produced them. They may be mutable, inaccessible to counterparties, tied to internal identifiers, or incomplete about the authority behind an action.
Agents create additional challenges because they:
- Operate across multiple tools and organisations
- Make decisions using changing context and model outputs
- Delegate work to other agents or services
- Act asynchronously and sometimes concurrently
- Handle sensitive personal, financial, or business information
- Need to explain actions to users, auditors, regulators, and other software
Portable signed records provide a common evidence layer. A receiving system can validate a record without querying every internal database, while the originating system can disclose only the fields needed for a specific purpose.
Common use cases include:
- Delegated purchasing: An agent proves that a purchase was within a user-approved budget and scope.
- Customer support: A case record shows which policy version and tool responses informed a resolution.
- Healthcare administration: A workflow records consent, data access, and handoffs while minimising disclosure.
- Financial operations: An agent presents signed approvals, risk checks, and transaction instructions.
- Enterprise automation: Multiple agents exchange verifiable task status and completion evidence.
- Robotics and IoT: Devices sign telemetry, commands, and maintenance events for later verification.
Core Architecture of a Signed Agent Record
A practical design separates the record’s semantic content from its transport and storage. The record should be understandable even when moved from one platform to another.
A representative JSON structure might look like this:
{
"record_type": "agent.action.v1",
"record_id": "urn:uuid:3d2f...",
"issuer": "did:web:agent.example.in",
"subject": "urn:task:order-8472",
"action": "invoice.approve",
"authority": {
"delegation_id": "urn:delegation:901",
"scope": ["invoice.read", "invoice.approve"],
"constraints": {
"max_amount_inr": 50000,
"expires_at": "2026-09-30T23:59:59Z"
}
},
"inputs_hash": "sha256:...",
"policy": {
"policy_id": "procurement-v4",
"decision": "allow"
},
"outcome": {
"status": "approved",
"amount_inr": 18400
},
"created_at": "2026-09-16T10:30:00Z",
"nonce": "random-unique-value",
"signature": {
"algorithm": "Ed25519",
"key_id": "did:web:agent.example.in#key-1",
"value": "base64url..."
}
}The exact schema can vary, but production implementations should define required fields, canonicalisation rules, versioning, validation errors, and compatibility expectations. Avoid signing a loosely formatted string whose meaning can change because of whitespace, field ordering, or ambiguous types.
Cryptographic Design Choices
Digital signatures
Ed25519 is often a strong default for application-level signed records because it offers compact keys and signatures, fast verification, and broad library support. ECDSA with P-256 may be preferable where existing compliance, hardware, or platform requirements demand it. RSA is widely supported but usually produces larger signatures and keys.
The algorithm is only one part of the design. Use an explicit algorithm identifier, reject deprecated algorithms, and maintain a migration path for key rotation. For long-lived evidence, consider how future algorithm changes will affect verification.
Canonicalisation
The signer and verifier must compute the same bytes. JSON is not inherently canonical: object ordering, numeric representations, Unicode normalisation, and escaping can differ. Use a defined canonical JSON scheme or sign a deterministic serialisation such as CBOR with a specified canonical encoding.
A safe signing process is:
1. Remove the signature field from the record.
2. Validate types and required fields against the schema.
3. Canonicalise the remaining structure.
4. Hash or sign the canonical bytes.
5. Attach the signature, algorithm, and key identifier.
Never sign a display rendering that can be changed by a user interface.
Hashes and large evidence
Agent traces can contain large prompts, documents, tool responses, or files. Put only a cryptographic digest and stable reference in the portable record when full disclosure is unnecessary. Use a modern hash such as SHA-256 or SHA-3, specify the encoded representation, and ensure the referenced content can be retrieved under appropriate access controls.
A hash proves that retrieved content matches the signed digest; it does not prove that the content itself is truthful or was collected fairly.
Identity, Keys, and Trust
A signature is meaningful only when the verifier can answer: “Which entity controls this key, and why should I trust it?” Agent architectures commonly bind keys to:
- A service identity managed by an organisation
- A user account or enterprise workforce identity
- A hardware device or secure enclave
- A decentralised identifier, where appropriate
- A short-lived execution instance issued by a trusted orchestrator
Key identifiers should resolve to public keys through a trustworthy mechanism. Depending on the environment, this may be a certificate authority, a protected key directory, a DID method, a cloud key management service, or an organisation-controlled registry.
Use separate keys for different risk domains. A key used to sign low-risk telemetry should not also authorise high-value payments. Keep private keys in HSMs, cloud KMS platforms, platform secure enclaves, or equivalent protected stores. Do not place long-lived signing secrets in prompts, source code, container images, or agent memory.
Key lifecycle controls should cover:
- Creation and ownership approval
- Activation and environment separation
- Rotation and overlap during migration
- Revocation and compromise response
- Backup and recovery procedures
- Audit logs for signing operations
- Expiry and archival verification
Delegation and Agent-to-Agent Workflows
Agents rarely act only for themselves. A user may authorise a supervisor agent, which delegates a narrow task to a specialist agent, which invokes a tool. Portable records should preserve this chain without requiring every verifier to inspect private internal logs.
A delegation record can specify the principal, delegate, permitted operations, resource scope, spending or rate limits, validity period, and conditions such as mandatory human approval. Each subsequent action record should reference the delegation or include a verifiable link to it.
For example:
User approval → Supervisor agent delegation → Specialist agent action → Tool resultEach link should be checked for:
- Valid signature and trusted issuer
- Time validity and non-revocation
- Scope containment: the child permission cannot exceed the parent permission
- Resource and amount limits
- Required approval or policy conditions
- Correct audience and intended service
This prevents a common failure mode in agent systems: treating possession of a valid token or signature as unlimited authority.
Replay Protection, Ordering, and Freshness
A valid signed record can still be abused if an attacker replays it. Include a unique record identifier, issuer, audience, creation time, expiration time, and nonce where appropriate. Consumers should maintain replay caches or durable state for high-risk operations.
For workflows that require ordering, use a parent record, sequence number, hash chain, or signed checkpoint. A hash chain can make later tampering evident, but it does not by itself guarantee that every event was recorded. Independent anchoring, append-only storage, or trusted timestamping may be needed for stronger audit requirements.
Clock handling also matters. Do not rely on a single unsynchronised machine clock for financial or safety decisions. Use bounded clock skew, server-side receipt times, monotonic sequence information, and clear rules for records received late or out of order.
Privacy-Preserving Portability
Portable evidence can become a privacy risk if records contain raw prompts, personal data, health details, financial identifiers, or confidential business information. Design for selective disclosure from the beginning.
Recommended practices include:
- Sign data minimised for the verification purpose
- Use references and hashes instead of copying large sensitive payloads
- Separate identity claims from action claims
- Encrypt records in transit and at rest
- Apply field-level access controls
- Use pseudonymous identifiers where lawful and practical
- Define retention and deletion policies
- Log access to evidence repositories
- Redact model prompts and tool outputs unless genuinely required
For Indian deployments, map the data flow against the Digital Personal Data Protection Act, 2023 and applicable rules, sectoral obligations, contractual requirements, and cross-border transfer policies. A signature preserves integrity; it does not create a lawful basis for processing personal data.
Verification Workflow
A verifier should process an incoming record in a strict order:
1. Parse safely and enforce size limits.
2. Validate the schema and record version.
3. Check required fields, types, and allowed values.
4. Resolve the issuer and signing key through a trusted directory.
5. Verify the signature over canonical bytes.
6. Check key status, algorithm policy, and certificate or identity validity.
7. Validate timestamps, expiration, audience, nonce, and replay status.
8. Resolve referenced delegation and parent records.
9. Evaluate authorisation and policy constraints.
10. Check hashes for any attached evidence.
11. Apply local business rules before accepting the action.
12. Store the verification result and relevant reason codes.
Verification failures should be explicit. Distinguish invalid signature, unknown key, expired authority, replayed record, malformed schema, unavailable evidence, and policy denial. “Verification failed” alone is not actionable for operators or users.
Implementation Blueprint for Indian AI Startups
An Indian AI startup can introduce portable signed records incrementally:
Phase 1: Define high-value events
Start with irreversible or disputed actions: payments, data exports, account changes, approvals, and agent delegation. Define what a verifier must know and what should remain private.
Phase 2: Create a versioned schema
Use JSON Schema, Protocol Buffers, or CBOR-based models. Document field semantics, canonicalisation, maximum sizes, and backward compatibility. Include a schema identifier in every record.
Phase 3: Protect signing keys
Use a managed KMS or HSM-backed signing service. Restrict signing permissions by workload identity, environment, and action class. Record key usage separately from the agent’s application logs.
Phase 4: Build an independent verifier
Implement verification as a library or service that does not trust the producer’s UI. Add negative tests for altered fields, wrong audiences, expired delegations, replayed IDs, and mismatched evidence hashes.
Phase 5: Add privacy controls
Classify fields, encrypt sensitive evidence, establish retention periods, and document data access. Test whether a counterparty can verify the required claim without receiving unnecessary personal data.
Phase 6: Operate and monitor
Measure signature failures, unknown issuers, key-rotation errors, replay attempts, verification latency, and evidence retrieval failures. Plan incident response for compromised keys and incorrect agent behaviour.
Common Mistakes to Avoid
- Signing records without a defined canonicalisation method
- Treating a valid signature as proof that an action was authorised
- Reusing one key for every agent, tenant, and environment
- Including sensitive prompts and tool responses by default
- Omitting audience, expiration, or replay protection
- Depending on a single vendor’s private log format
- Failing to version schemas and algorithms
- Making verification require a live connection to the issuing system
- Ignoring key compromise and historical verification
- Recording model confidence as if it were factual evidence
Portable Signed Records vs. Traditional Logs
Traditional logs optimise for internal observability. Portable signed records optimise for verifiable exchange between trust boundaries. A mature agent platform needs both.
Logs answer operational questions such as latency, exceptions, token usage, and infrastructure health. Signed records answer external or compliance-oriented questions such as which authority was used, whether content changed, and whether a specific agent issued an action. Link the two using correlation identifiers, but avoid exposing internal logs merely because an external record references them.
FAQ
Are portable signed records the same as blockchain records?
No. They are cryptographically signed data objects and can be stored in ordinary databases, object stores, APIs, or append-only systems. Blockchain anchoring is optional and may be useful for selected integrity or timestamping requirements.
Can a signed record prove that an AI answer is correct?
No. It can prove who signed the answer, what content or policy version was referenced, and whether the record was altered. Factual correctness requires separate validation, provenance, testing, and human or domain review.
Which signing algorithm should an AI startup use?
Ed25519 is often suitable for new application protocols, while ECDSA P-256 may fit existing enterprise or compliance ecosystems. Choose based on library maturity, key custody, interoperability, and migration requirements—not speed alone.
Should every model token or internal reasoning step be signed?
Usually not. Sign meaningful externally relevant events, tool calls, approvals, policy decisions, and outputs. Signing every internal step increases cost, privacy exposure, and complexity without necessarily improving trust.
How do records work when agents operate offline?
Use locally protected keys, sequence numbers, expiration windows, and later synchronisation. The receiving system should distinguish an offline-created record from one verified against current revocation and policy state.
Apply for AI Grants India
Building trustworthy agent infrastructure with portable signed records? Apply to AI Grants India for support, funding pathways, and opportunities to develop secure, globally interoperable AI products from India.