Verifiable Agent Execution: Turning Agent Activity into Signed Evidence
AI agents are no longer just answering questions. They send messages to other agents, react to events, call LLMs, invoke plugins, update databases, and trigger external systems. FabrCore already gives teams observability into that activity. Verifiable execution adds the next layer: signed, tamper-evident timelines that prove what happened, where it happened, which agent code was running, and whether the evidence has been changed.
Why We Needed This
Monitoring answers an operational question: what is happening right now? Verifiable execution answers a trust question: can I prove later that this is what happened?
That difference matters once agents start making consequential changes. If a support agent refunded an order, a billing agent changed an invoice, or a workflow agent delegated work to another cluster, customers need more than a dashboard screenshot. They need a durable chain of evidence.
A good analogy is a flight recorder. Normal telemetry tells air traffic control where the aircraft is. The flight recorder gives investigators a protected timeline when the details matter later. FabrCore verifiable execution is the flight recorder for agent systems.
What Problem It Solves
Distributed agent systems create a new audit problem. A single user request can become a graph of messages, event handlers, LLM calls, tool calls, plugin calls, HTTP requests, and database effects. Traditional logs can show pieces of that graph, but logs are usually not enough to prove integrity. They can be incomplete, edited, reordered, deleted, or separated from the runtime version that produced them.
FabrCore records the execution graph as signed evidence. Each record is canonicalized, hashed, signed, and chained to the previous record in the same operation. Change an event payload hash, delete a tool call, fake a handler success, or reorder records, and verification fails.
The customer benefit is simple: when an agent does something important, the customer can verify the chain of custody instead of relying only on trust in a log table.
What Gets Captured
Verifiable execution follows the same causal graph FabrCore already uses for tracing. TraceId is the operation id. SpanId and ParentSpanId connect messages, events, streams, and side effects.
| Record kind | Examples |
|---|---|
| Messages | Client-to-agent, agent-to-agent, and outbound responses |
| Events | Event published, delivered, handled, failed, and nested outbound events |
| Model work | LLM calls, model configuration hash, prompt hash, token metadata |
| Tools and plugins | Tool calls, plugin calls, arguments hash, result hash, failures |
| External effects | HTTP calls, database effects, storage effects, manual attestations |
| Runtime provenance | Host version, deployment id, container or commit digest, agent alias, assembly version, config hash |
Think of it like signed package tracking. The event says a package moved from one facility to another. The signature proves which facility recorded it and whether anyone altered the record later.
A Concrete Example
Imagine a customer asks an agent to update a contract renewal. The first agent validates the request, sends a message to a pricing agent, receives a recommendation, calls an LLM to draft language, invokes a plugin that writes to SQL, publishes an event, and returns a response.
With normal monitoring, you can inspect that path. With verifiable execution, you can export the operation bundle and verify that the request and response belong to the same operation, the pricing agent really produced the recommendation, the tool and database effect were part of the same causal chain, and no record was silently edited, removed, inserted, or reordered.
Four Setup Levels
We designed this so customers can start small and grow into stronger trust requirements without changing their agent code.
| Level | Mode | Use when |
|---|---|---|
| Default | Off | You want existing monitoring behavior with no additional evidence storage or signing. |
| Easy | Local signed execution | You want tamper-evident timelines in dev, staging, or smaller production systems. |
| Production | Certificate, KMS, or HSM signed execution | You need durable signing keys, key rotation, and SQL or custom evidence storage. |
| Enterprise and cross-cluster | SPIFFE trust by default | You need workload identity and trust bundles across clusters, teams, clouds, or audit domains, with certificate/KMS/HSM signers still available as provider alternatives. |
SPIFFE is not the feature by itself. It is FabrCore's default enterprise workload-identity trust path for cross-cluster verification. Certificate, KMS, and HSM signers can still be provided through the signer model. The product feature is verifiable execution: signed proof around agent behavior.
SPIFFE Ecosystem
The SPIFFE overview describes an open standard for securely identifying software workloads in dynamic environments using short-lived identity documents called SVIDs. SPIFFE is already part of the broader cloud-native trust conversation around systems such as SPIRE, Dapr, Istio, Consul, and cert-manager.
FabrCore is moving in that same direction for agent systems: agents still use FabrCore handles and aliases at the application layer, while the host can use SPIFFE identity to sign and verify execution evidence across clusters.
What Customers Get
Customers get an evidence system for AI operations. That helps with regulated workflows, enterprise review, incident response, cross-cluster collaboration, and internal accountability.
For example, a customer can ask, "Which version of the contract agent approved this change?" or "Did this plugin write the database row before or after the event was published?" or "Can another FabrCore cluster verify that this response came from the expected cluster?" FabrCore can answer those questions with signed records, not just conventional logs.
It also gives engineering teams a practical boundary. External effects that go through FabrCore wrappers or manual evidence APIs can be attested. Direct database updates outside those APIs are marked as unverified. That is honest and useful: the system tells you where the evidence trail is strong and where code bypassed it.
What It Does Not Claim
Verifiable execution proves integrity and provenance of the execution evidence. It does not prove the LLM was correct. It does not independently prove a remote database commit unless that effect is attested by the wrapper, provider, or external system. It does not replace authorization, ACLs, secrets management, or human review.
That clarity is part of the value. FabrCore gives teams a signed record of agent behavior and makes the trust boundary visible.
Where It Fits in FabrCore
Verifiable execution sits beside monitoring and telemetry. Monitoring is for live visibility. OpenTelemetry is for traces, metrics, and diagnostics. Verifiable execution is for durable, exportable proof.
Because it follows the same operation and span model, the feature connects naturally to agent messages, streamed events, OnEvent handlers, LLM calls, plugins, tools, and external effects.
See the Verifiable Execution documentation for setup modes, provider interfaces, trust options, and implementation guidance.