Blocklog records what autonomous agents do, proves what happened, and provides the evidence and controls needed to operate them with confidence.
AI agents are evolving from systems that generate responses into systems that execute actions. They call APIs, access databases, invoke tools, make decisions, and trigger consequential workflows.
When something goes wrong, organizations need to answer:
- Identity: Which agent actually acted?
- Authority: What was it allowed to do?
- Execution: What happened, and in what order?
- Provenance: What context and evidence surrounded the decision?
- Integrity: Can the record be independently verified?
- Governance: Were the required policies and human approvals applied?
Traditional logs and observability tools help explain system behavior. Blocklog adds a cryptographically verifiable evidence layer and execution-governance primitives for autonomous systems.
Observe → Prove → Control → Govern
Capture execution events and connect them into a structured history of agent activity.
- Execution events and tool calls
- Traces, sessions, and workflows
- Policy evaluations and authorization decisions
- Relevant inputs, outputs, and context references
- Timestamped, hash-linked event histories
Bind execution records to cryptographic integrity structures so their relationships can be checked independently.
- Canonical event encoding
- SHA-256 payload hashing
- Hash chains and Merkle trees
- Merkle inclusion proofs
- Ed25519 signatures
- Signed execution receipts and transparency evidence
- Standalone verification workflows
The objective is to make historical evidence verifiable without requiring the relying party to blindly trust the service that produced it.
Evaluate agent actions against policies and authorization requirements before execution.
- Policy evaluation
- Scoped execution authorization
- Execution tokens
- Human-in-the-loop approval workflows
- Recorded authorization decisions
- Evidence linking authorization to subsequent activity
Enforcement boundary: Blocklog can evaluate authorization and issue authorization artifacts. The external processor or integration must enforce the authorization before performing the protected action.
Connect execution evidence with the workflows needed to investigate incidents and review consequential decisions.
- Decision provenance
- Execution reconstruction and forensic investigation
- Incident evidence
- Structured evidence packages
- Verification reports
- Security, risk, and governance workflows
Conventional observability answers questions such as:
- Did a request fail?
- Which service called another service?
- Where did latency occur?
- What did the application log?
Consequential autonomous actions introduce additional questions:
- Which agent identity was associated with the action?
- Which policy and authorization decision applied?
- What inputs and external data were available?
- Which tools and systems did the agent interact with?
- Was human approval required, and was it recorded?
- Can an investigator verify that the evidence has not been altered?
These questions span application behavior, security controls, cryptographic integrity, and governance. They cannot always be answered reliably by collecting more conventional logs.
Blocklog connects execution, authority, provenance, and evidence into a verifiable record of consequential agent activity.
Blocklog uses cryptographic primitives to establish integrity relationships between captured records.
A simplified evidence pipeline looks like this:
Agent Execution
|
v
Capture Event
|
v
Canonicalize Payload
|
v
Compute SHA-256 Hash
|
v
Link Event History
|
v
Build Merkle Tree
|
v
Commit to Merkle Root
|
v
Sign Evidence / Receipt
|
v
Independent Verification
Depending on the evidence format, a verifier can check:
| Verification property | What it establishes |
|---|---|
| Payload integrity | The supplied payload matches its expected cryptographic hash. |
| Chain continuity | The supplied records satisfy the expected hash-link relationships. |
| Merkle inclusion | A record is included under the supplied Merkle root. |
| Signature validity | A signature verifies against the corresponding public key. |
| Checkpoint consistency | Supplied transparency evidence satisfies the verifier's consistency rules. |
These checks establish cryptographic relationships, not the truth of every underlying claim.
For example, a valid signature does not independently establish that an agent's reported identity is genuine. A valid hash does not prove that every relevant event was captured. Stronger assurance also depends on key management, trusted identity binding, capture completeness, authorization enforcement, and the handling of signing keys and checkpoints.
Blocklog's objective is to make these trust assumptions explicit and the resulting evidence independently checkable.
Cryptographic evidence is valuable after an action. High-consequence systems also need controls before an action takes place.
Blocklog's execution-governance model connects:
Agent
|
v
Action Request
|
v
Policy Evaluation
|
+---- Deny ----> Record Decision
|
+---- Approval Required
| |
| v
| Human Review
| |
| v
| Record Approval
|
v
Issue Authorization
|
v
External Processor Enforces Authorization
|
v
Capture Execution Evidence
|
v
Verify Resulting Record
The goal is to link the requested action, applicable policy, authorization decision, any required human approval, and the resulting execution evidence.
Actual prevention of unauthorized actions depends on the enforcement integration. A policy decision recorded by Blocklog alone does not prevent an external system from executing an action.
An execution record becomes more useful when investigators can connect events and their surrounding context.
Blocklog is designed to link relevant evidence across:
- Agent executions
- Model and decision records
- Tool calls and external API interactions
- Policy evaluations and authorization records
- Database operations and workflow events
- Input and context references
- Execution receipts and cryptographic proofs
This supports forensic reconstruction of what the system recorded, which events were connected, and what evidence was available for later verification.
Provenance is not a claim of deterministic reconstruction of model internals. It records relationships to captured context and execution evidence; it does not guarantee that every hidden model computation can be reproduced.
Blocklog is designed to collect execution records and verification material into structured packages for investigation, review, and audit workflows.
Depending on the supported record and evidence format, a package can include:
- Execution records and trace events
- Event history and hash-chain data
- Merkle roots and inclusion proofs
- Signatures and verification material
- Receipt metadata
- Verification results and report metadata
These packages aim to make evidence portable beyond the application that originally recorded it.
For Indian legal workflows, Blocklog also targets evidence packages oriented toward Section 63 of the Bharatiya Sakshya Adhiniyam, 2023. Such packaging is not, by itself, a guarantee of legal admissibility or compliance; requirements depend on the applicable law, facts, and supporting procedures.
Blocklog provides an execution-evidence layer that can sit alongside existing autonomous systems.
┌──────────────────────────────────────────┐
│ Agent / SDK / API Clients │
└────────────────────┬─────────────────────┘
|
v
┌──────────────────────────────────────────┐
│ API Layer │
│ Authentication · Tenant Context │
│ Validation · Rate Limiting │
└────────────────────┬─────────────────────┘
|
v
┌──────────────────────────────────────────┐
│ Service Layer │
│ Ingestion · Integrity · Tracing │
│ Policies · Verification · Governance │
└─────────────┬────────────────┬───────────┘
| |
v v
┌────────────────────┐ ┌──────────────────┐
│ PostgreSQL │ │ Redis/Celery │
│ Events and records │ │ Background work │
│ Traces and batches │ │ Async processing │
└────────────────────┘ └──────────────────┘
|
v
┌──────────────────────────────────────────┐
│ Cryptographic Evidence │
│ SHA-256 · Hash Chains · Merkle Trees │
│ Ed25519 · Receipts · Verification │
└──────────────────────────────────────────┘
The architecture is intended to support programmatic ingestion, evidence generation, independent verification, and execution-governance integrations.
Blocklog is being built for developers who want to integrate evidence capture into systems they already operate.
A conceptual Python integration looks like:
blocklog.log(
event_type="tool.call",
source="payment-agent",
payload={
"tool": "payments.execute",
"amount": 5000,
},
)An integration can then connect the captured event to the applicable execution, authorization, and verification workflows.
Consult the relevant SDK documentation for the actual API, configuration, authentication requirements, and supported event formats.
Payment agents, financial workflows, fraud operations, underwriting, and systems that need verifiable execution evidence.
Internal agents, autonomous workflows, tool-using assistants, and AI-powered operations that interact with business systems.
Applications that need stronger audit trails, authorization controls, human oversight, and structured evidence for review.
Systems where multiple agents, tools, and external services contribute to a consequential execution.
Evidence over assertions
Make important execution records verifiable instead of relying exclusively on application-generated descriptions.
Independent verification
Design evidence formats and verification tooling so relying parties can validate supported cryptographic properties independently.
Explicit trust boundaries
Distinguish cryptographic integrity from identity assurance, capture completeness, authorization enforcement, and the truth of reported events.
Governance at the action boundary
Connect policy evaluation and human approval to consequential actions rather than treating governance solely as post-execution reporting.
Interoperability
Build SDKs, APIs, and portable evidence formats that work with existing agent architectures.
Security by design
Treat tenant isolation, authentication, key handling, data minimization, and authorization as core infrastructure concerns.
Blocklog is under active development.
The project is working toward a practical trust layer for autonomous agents: one that connects captured execution evidence, cryptographic verification, authorization, human oversight, and investigation workflows.
Features, integration maturity, and operational guarantees vary by component. Review each repository's documentation, tests, and release status before relying on it in production.
Contributions, technical feedback, and design-partner discussions are welcome.
Make consequential autonomous execution verifiable.
Blocklog is building trust infrastructure for autonomous agents—connecting what an agent did, what it was authorized to do, and what can be independently verified afterward.
Observe → Prove → Control → Govern