Overview
Unlike the/runs endpoints which are hierarchical (Run → Actions), the ledger provides a flat, chronological stream of all actions with advanced filtering and search capabilities.
Key Use Cases
- Compliance Audits: “Show me all high-risk actions in Q4 2024”
- Debugging: “Find all failed
database_queryactions” - Cost Analysis: “What are my most expensive actions?”
- Security: “Show all actions by
prod-agent-3that were blocked” - Organizational Memory: “What did our agents do last week?”
Endpoints
GET /api/v1/ledger
Query the activity ledger with filtering, sorting, and pagination.Query Parameters
Response
Example: Find Failed Actions
Example: Search Actions
Example: Date Range Query
GET /api/v1/ledger/stats
Get aggregate statistics for the activity ledger.Query Parameters
Response
Example: Monthly Stats
GET /api/v1/ledger/export
Export ledger data for compliance audits and offline analysis.Query Parameters
Response
File download in requested format.Example: Export as JSONL
Example: Export Failed Actions as CSV
GET /api/v1/ledger/verify
Re-derive an organization’s row hash chain from stored data and report whether it’s intact.Query Parameters
Non-superusers may only verify their own active organization’s chain; requesting a different
organization_id returns 403.
Response
valid is false, first_bad_seq is the earliest seq whose stored row_hash no longer matches what’s recomputed from its current fields and prev_hash — evidence that row (or an earlier one) was altered or deleted after it was chained.
Example
Hash Chain & Signing
Every ledger row is chained to the previous row written for its organization, and optionally Ed25519-signed:seq— gap-free, per-organization sequence number. Assigned under a Postgres advisory lock (pg_advisory_xact_lock, keyed by organization) so concurrent ingest batches to the same org can’t race each other into duplicate or gapped values.prev_hash— the previous row’srow_hash(nullfor the first row in the chain).row_hash—sha256of the row’s immutable fields (everything set at ingest time, excludingcompliance_metadata) plusprev_hash.signature/key_id— Ed25519 signature ofrow_hashand the signing key used. Both arenulluntil a signing key is configured (COMPLIANCE_SIGNING_KEY_ED25519; see the Compliance Guide). Rows written before a key existed stay permanently unsigned (“pre-signing”) — a later key rollout does not retroactively sign history.compliance_metadata.log_hash/tamper_seal— mirrorrow_hash/signature, for tooling that only readscompliance_metadata.
prev_hash stops matching, and GET /ledger/verify (or the standalone script below) reports the first broken seq.
Verifying from outside the platform
scripts/verify_ledger_chain.py re-derives the same chain directly against a database URL, for auditors who don’t have (or don’t want to rely on) API access to the running platform:
Response Schema
LedgerEntry
Actor / Counterparty
Every ledger row is self-describing:actor and counterparty record who did what without requiring a join through /runs. This is the same identity shape used across Agent Sentinel’s governance tables (agent id, principal, harness, key id, mandate reference), so it stays compatible with A2A agent cards and AP2/TAP mandate references.
actor is derived server-side from the verified API key/JWT plus the SDK’s X-Sentinel-* identity headers — it cannot be spoofed by the request body. counterparty is optional and comes from a counterparty field on the SDK’s ingest entry, for actions performed against or on behalf of another party (e.g. a buyer agent in an AP2 transaction).
ComplianceMetadata (Enterprise Tier)
Common Patterns
1. Debugging Failed Actions
2. Cost Analysis by Agent
3. Compliance Audit Export
4. Real-Time Monitoring
Authentication
All ledger endpoints require authentication via:-
JWT Bearer Token
-
API Key (recommended for programmatic access)
Access Control
- Users can only see actions from their own runs
- Superusers can see all actions across all users
- Organization admins can see actions from their organization’s runs
Rate Limits
- Query Endpoints: 1000 requests/hour
- Export Endpoint: 100 requests/hour
- Stats Endpoint: 600 requests/hour
Differences from /runs Endpoints
When to use
/runs:
- Inspecting a specific run’s execution flow
- Debugging a single agent workflow
- Viewing run-level metadata
/ledger:
- Compliance audits across all activity
- Finding patterns across multiple runs
- Cost analysis by action type
- Security monitoring
Best Practices
1. Use Pagination for Large Results
2. Use Search for Flexible Queries
3. Filter by Date Range for Performance
4. Use Stats Endpoint for Aggregates
Troubleshooting
Empty Results
Problem: Query returns 0 results Solutions:- Check filters - they may be too restrictive
- Verify date range includes expected data
- Ensure authentication is correct (not seeing another user’s data)
- Check that agents have actually executed actions
Slow Queries
Problem: Queries take >5 seconds Solutions:- Reduce page size (100 instead of 1000)
- Add date range filters to limit data scanned
- Avoid search queries on large datasets
- Use stats endpoint for aggregates instead of fetching all data
Export Limits
Problem: “Export limit exceeded” error Solutions:- Reduce date range or add more filters
- Export in batches using pagination
- Contact support for bulk export access
Related Documentation
- Runs API - Hierarchical run/action queries
- Ingest API - How SDK sends action data
- Authentication - API keys and JWT tokens
- Compliance Guide - Enterprise compliance features
