TrustKernels validates, orders, and receipts every action your AI agents take. Define policies that constrain what agents can do, then get a complete audit trail of everything that happened.
When you deploy AI agents that can take real-world actions—writing to databases, making API calls, sending payments—you need a way to control and audit what they do.
TrustKernels sits between your agents and their effects. Before any action executes, the kernel validates it against your policies. After execution, it generates a receipt and logs the event to an audit trail.
The result: you know exactly what your agents are allowed to do, what they actually did, and you have receipts to prove it.
The complete lifecycle of an agent action through TrustKernels.
When an agent wants to perform an action, it creates a Proposal. The proposal contains the agent's ID, an intent description, and a payload with the specific parameters for the action.
Proposals don't execute immediately—they enter a "pending" state waiting for validation.
{
"proposal_id": "PROP-2025-001",
"agent_id": "support-agent",
"intent": "process_refund",
"payload": {
"ticket_id": "TKT-98421",
"customer_id": "C-7291",
"refund_amount": 149.99,
"reason": "product_defective"
},
"status": "pending"
}The kernel checks the proposal against all policies attached to the agent. It verifies:
{
"allowed": true,
"reasons": [],
"computed_effects": [
{
"kind": "DB_WRITE",
"ordkey": "tickets/TKT-98421/status",
"preview": { "status": "refund_approved" }
},
{
"kind": "PAYMENT_SEND",
"ordkey": "refunds/C-7291/2025-01-15",
"preview": { "amount": 149.99 }
},
{
"kind": "HTTP_CALL",
"ordkey": "email/C-7291/refund-confirmation",
"preview": { "template": "refund_complete" }
}
]
}Validated proposals can be approved for execution or rejected. This step can be manual (via the console) or automated based on your workflow.
If a proposal fails validation, it remains in pending state and cannot be approved until the underlying issue is resolved.
Proceeds to execution. Effects are applied and receipted.
Proposal is closed. No effects are applied.
Upon approval, the kernel executes each effect in order. Each effect gets an ordering sequence number (ordseq) and generates a receipt hash.
The receipt provides proof that the effects were executed, in what order, and with what results. Every execution is logged to the audit trail.
{
"receipt_id": "RCPT-abc123",
"status": "applied",
"effects": [
{
"kind": "DB_WRITE",
"ordkey": "tickets/TKT-98421/status",
"ordseq": 1,
"receipt_hash": "sha256:a1b2c3..."
},
{
"kind": "PAYMENT_SEND",
"ordkey": "refunds/C-7291/2025-01-15",
"ordseq": 2,
"receipt_hash": "sha256:d4e5f6..."
},
{
"kind": "HTTP_CALL",
"ordkey": "email/C-7291/refund-confirmation",
"ordseq": 3,
"receipt_hash": "sha256:g7h8i9..."
}
]
}The building blocks of the TrustKernels system.
Registered identities that can submit proposals. Each agent has a unique ID, a status (active/disabled), and a list of attached policy IDs that govern what it can do.
JSON documents that define what effects an agent can produce, what namespaces it can read/write, and resource limits. Policies are attached to agents.
Requests from agents to perform actions. Contains the agent ID, intent, and payload. Proposals transition through states: pending, validated, executed, or rejected.
Isolated execution contexts. Each handle has a program hash, epoch, state root, and tracks pending effects. Handles provide isolation between different agent workloads.
The actual actions that agents produce: database writes, HTTP calls, payment sends, AI inference calls. Effects are validated against policies and ordered for execution.
Proof of execution. Contains the receipt ID, status (applied/failed), and a list of effects with their ordering sequence numbers and receipt hashes.
Policies define what agents can do using a structured rule format.
Define what kinds of effects the agent can produce. Each effect rule specifies a kind (DB_WRITE, HTTP_CALL, PAYMENT_SEND, AI_INFER), a namespace, and optionally a key or key_prefix.
Controls what data the agent can access. Reads and writes are scoped to specific namespaces and key prefixes. The kernel validates that proposed operations stay within these bounds.
Optional constraints on resource usage: max_effects limits how many effects a single proposal can produce, max_payload_byteslimits the size of proposal payloads.
{
"policy_id": "support-refunds",
"name": "Customer Support Refunds",
"rules": {
"effects": [
{
"kind": "DB_WRITE",
"namespace": "db:tickets",
"key_prefix": "tickets/"
},
{
"kind": "PAYMENT_SEND",
"namespace": "rail:stripe",
"key_prefix": "refunds/"
},
{
"kind": "HTTP_CALL",
"namespace": "svc:email",
"key_prefix": "email/"
}
],
"rwset": {
"reads": [
{
"namespace": "mem:customers",
"key_prefix": "customer/"
},
{
"namespace": "mem:orders",
"key_prefix": "order/"
}
],
"writes": [
{
"namespace": "mem:tickets",
"key_prefix": "ticket/"
}
]
},
"limits": {
"max_effects": 10,
"max_payload_bytes": 65536
}
}
}The kernel supports four types of effects that agents can produce.
Database operations
Write data to a database. Used for updating ticket statuses, logging customer interactions, or recording transaction history. Scoped by namespace and key prefix.
External API calls
Make HTTP requests to external services. Send emails, post Slack messages, update CRM records, or trigger webhooks. Scoped by service and endpoint prefix.
Financial transactions
Process refunds, issue credits, or send payments. Integrates with Stripe, bank transfers, or other payment rails with strict amount limits and audit trails.
AI model inference
Call AI models for sentiment analysis, intent classification, or generating responses. Control which models agents can access and track inference costs.
Every action in the system is logged to the audit trail. You can see:
When the event occurred
AGENT_SAVED, PROPOSAL_SUBMITTED, PROPOSAL_VALIDATED, PROPOSAL_REJECTED, EFFECTS_EXECUTED
The agent, proposal, or handle involved
Full payload of the event for debugging and compliance
Create agents, define policies, submit proposals, and see the full validation and execution flow in action.