How it works

From raw audit logs to reconciled evidence

A collector inside your network reads what agents report and what your systems of record recorded, and minimizes it before anything leaves. The control plane rebuilds every run, links each claim to independent evidence, and turns it into mandates, scorecards and exceptions.

Book a Demo See the pilot

Evidence chain

Invoice €4,312.50 · AP agent

Posted invoice to ERP

Agent reported

timeout

→

ERP change log says

invoice posted NL01-5200004276 +2.4s

ContradictedLinked by business key · 50%

Posted invoice to ERP · retry

Agent reported

success

→

ERP change log says

invoice posted NL01-5200004277 +2.3s

ConfirmedLinked by business key · 75%

Same supplier invoice posted twice — both paid

Duplicate posting · high severity · routed to AP owner for review

Illustrative · demo environment, simulated data

Architecture

Two planes, one contract

Collection happens where your data lives. Analysis happens in an EU-hosted control plane. Exactly one data shape — the canonical event — may cross between them, and both sides validate it against the same schema.

Your network · read-only

Agent runtimes

OpenTelemetry GenAI spans
Vendor platform exports
Coding agent telemetry

Systems of record

ERP change documents
CRM and HRIS audit trails
Mailbox and workbook logs
Approvals and payments

Seven steps from raw record to decision

Steps one to three run in the collector, inside your network. Steps four to seven run in the control plane.

Step 01 · Collect

Collector

Read-only adapters, inside your network

Small, versioned adapters read the native exports and audit logs your systems already produce, using read-only credentials that never leave your network. Nothing is installed in your agents.

Agent runtimes: OpenTelemetry GenAI spans from in-house orchestrators; session, activity and billing exports from vendor agent platforms
Systems of record: ERP change documents and payment runs, CRM and HRIS audit trails, mailbox and workbook audit logs, approval tasks
Directory: people, service principals and technical accounts, for identity resolution

Source record → canonical eventExamples

invoke_agent spanrun.started · run.completed
chat spanmodel.call — model, tokens, price reference
execute_tool spantool.call — tool, operation, result
Vendor session exportrun.* · tool.call · credits on completion
Billing export linecost.allocated — platform fee per month
ERP change documentapp.audit — erp.invoice_posted, erp.vendor_updated…
Approval taskapproval.requested · approval.decided
Payment runoutcome.updated — paid, blocked or reversed

Step 02 · Normalize

Collector

One canonical event contract

Every record becomes one of nine event types with the same fields for agent, run, actor, tool, object, action, cost and outcome. Identities are resolved against your directory and kept apart: the person who asked, the credential that acted, and the type of principal.

Deterministic event IDs, so re-sending an export never duplicates evidence
Timestamps converted to UTC; amounts parsed from local formats — “12.450,00” becomes 12450.00
Unresolved identities kept as raw and flagged, never guessed

Nine event typesContract v1.0

run.startedrun.completedmodel.calltool.callapp.auditapproval.requestedapproval.decidedoutcome.updatedcost.allocated

Identity, resolved three waysPer event

initiating_user_id
Who asked?
person:p_kbauer
effective_identity
Whose credentials acted?
agent:ap-intake-de
identity_type
What kind of principal?
agent_service_principal · delegated_user · user · system

Step 03 · Minimize

Collector

Hash or drop, before anything leaves

Sensitive values are replaced with keyed hashes or dropped before an event is queued for sending. Every event passes four gates on the way out, and every transformation is listed on the event itself.

Adapter-level minimization
Attribute allow-list — anything not on it is dropped and recorded
JSON Schema validation with additionalProperties: false
Outbound DLP scan — an email address or IBAN pattern anywhere blocks the event

What happens to sensitive fieldsBefore export

Supplier invoice numberinvoice_key: inv_3f9c2a71…hashed
IBAN on a vendor recordnew_value_hash: iban_9a1f07c3…hashed
Internet message IDmessage_ref: msg_5c0e18b2…hashed
Recipient email addressrecipient_domain onlymasked
Email subjects and bodies—dropped
Spreadsheet cell values—dropped
Approval comments, ERP item texts—dropped
Raw tool arguments and results—dropped

Hashes are keyed (HMAC-SHA256) with a salt that stays in your network. The same IBAN always produces the same hash — so reuse across vendors is detectable — but the value can't be recovered.

Step 04 · Reconcile

Control plane

Rebuild every run. Link every claim to evidence.

Events are grouped into runs, sub-agent runs attach to their parents, and late evidence — approvals hours later, payments days later — is attached when it arrives. Each write an agent claims is matched to what the system of record recorded, with an explicit link method and confidence.

Confirmed: The system of record shows the change.
Unconfirmed: The agent reported success; no matching record exists.
Contradicted: The agent reported a failure or timeout, but the change happened.
Unattributed: An agent's identity changed data with no run behind it.

Link method and confidenceEvery link

Direct reference95%

The tool result returned the record's ID — a document number, row or task ID.

Business key85%

A hashed key such as vendor + supplier invoice number, within a time window.

Time window70%

Identity and timing only. The weakest method.

Adjustments

−25 ptsThe record's identity disagrees with the runtime's
−10 ptsThe agent acted on delegated human credentials
Max 50%Several records match equally well

Step 05 · Evaluate

Control plane

Versioned mandates, applied to all history

Mandates are versioned rules per agent: allowed tools, approval thresholds, sensitive fields, spend caps per run and per month, and identity rules. The active version is checked against every run in the evidence store — so a rule change shows its impact on history before anyone enforces it.

Mandate · AP Intake Agentv1 → v2 · illustrative

Allowed tools
tool_allowlist
9 tools
Approval above threshold
approval_threshold
> €10,000
Sensitive field changes need approval
sensitive_field
bank_account
Spend cap per run
spend_cap_run
€2.50
Monthly spend cap
spend_cap_month
€450 €650
Acts under its own identity
identity_mode
required

Re-checked every historical run against v2 · 1 exception closed, 0 new

Suggest only

Act with approval

Act within limits

Autonomous

Step 06 · Measure

Control plane

Metrics with published definitions

Scorecards compare agents, versions, teams and task types on the same definitions. Every number drills down to the runs and records behind it. Allocated costs are labeled as allocated, and modeled savings as modeled.

Metric definitionsVersioned · traceable

Cost per completed workflow
Σ workflow cost of all runs ÷ completed workflows
Workflow cost = metered + allocated + delegated sub-agent runs. Failed and escalated runs still count.
Straight-through rate
runs completed with no approval and no takeover ÷ all runs
Takeover rate
runs escalated to a person, or failed ÷ all runs
Evidence coverage
runs with every claimed write confirmed ÷ runs with claimed writes
Mandate compliance
passed checks ÷ (passed + failed checks)
Warnings, such as a delegated identity, are reported separately.

Step 07 · Review

Control plane

Exceptions with owners and an audit trail

Findings land in a review queue with severity, the full evidence chain and a playbook. Decisions are keyed to a stable exception ID, so they survive reprocessing, and every decision is written to an audit log with who made it and when.

Confirm, dismiss or escalate to the agent's owner
Decisions kept when evidence is reprocessed or a mandate changes
Mandate versions and review decisions are both audited

Exception typesExamples

Mandate breachDuplicate postingBank account reuseUnattributed writeUnconfirmed writeContradicted writeRun cost capMonthly capDelegated identityUncertain link

Audit logIllustrative

21 Oct 09:14k.bauerConfirmed issueDuplicate posting · DE01-5100012345
21 Oct 09:20k.bauerEscalated to ownerBank account reuse · V100234
21 Oct 09:31m.weberDismissedUncertain link · documented exception

The contract

What a canonical event looks like

This is the only shape of data that leaves your network. Here, an agent claims it posted a supplier invoice. Nothing in the event reveals the invoice number, and nothing carries free text from your systems.

1
Three identities, kept apart
Who asked, whose credentials acted, and what kind of principal that was. A delegated human token is never mistaken for an agent.
2
The claim
The agent says it posted DE01-5100012345. The control plane looks for that change document in the ERP's own log.
3
A business key, not the invoice number
invoice_key is a keyed hash of vendor and supplier invoice number. It joins ERP, approvals and payments without exporting either.
4
Every transformation declared
Tool arguments and results never leave your network. What was hashed or dropped is listed on the event itself.
5
Provenance to the raw record
Collector, adapter version and a SHA-256 digest of the source record, so any number can be traced back and verified.

tool.call · erp.post_invoiceAbridged · illustrative

1{
2  "schema_version": "1.0",
3  "event_id": "evt_47716034f59c4c513bbfd6299c6d37fb",
4  "tenant_id": "nordwind",
5  "source_system": "agent_runtime.orchestrator",
6  "event_type": "tool.call",
7  "occurred_at": "2026-10-06T08:14:03.120Z",
8  "agent": { "agent_id": "ap-intake-de", "agent_version": "2.4.0" },
9  "run": { "run_id": "run_0be9b581c4a3…", "step_id": "b7fdabaa6c80…" },
1  "actor": {
11    "initiating_user_id": "person:p_kbauer",
12    "effective_identity": "agent:ap-intake-de",
13    "identity_type": "agent_service_principal"
14  },
2  "tool": { "tool_id": "erp.post_invoice", "operation_class": "write" },
16  "object": { "system": "erp", "type": "invoice_doc", "ref": "DE01-5100012345" },
17  "action": { "result": "success", "external_ref": "DE01-5100012345" },
3  "attributes": {
19    "invoice_key": "inv_3f9c2a71d04e8b65",
20    "vendor_ref": "V100234",
21    "amount_eur": 12450.00
22  },
4  "redactions": [
24    { "field": "supplier_invoice_number", "action": "hashed" },
25    { "field": "gen_ai.tool.call.arguments", "action": "dropped" },
26    { "field": "gen_ai.tool.call.result", "action": "dropped" }
27  ],
5  "provenance": {
29    "collector_id": "col-nordwind-fra-01",
30    "adapter": "orchestrator_spans", "adapter_version": "0.1.0",
31    "raw_digest": "sha256:1830200e7e21…"
32  }
33}

Demo environment · simulated data · values shortened with …

Rollout

Read-only first. Enforcement where you choose.

Detection comes before control. Enforcement is added later, at specific tool boundaries, once the evidence shows where a control pays for itself.

Pilot
Stage 1
Observe
Read-only access to one agent runtime and two or three systems of record. Every run reconstructed, cost per outcome baselined, exceptions surfaced with evidence.
Breaches are found after the fact — and reported as such.
Pilot
Stage 2
Draft mandates
Write mandates with each agent's owner and re-check them against history. Tune thresholds and caps on real data without blocking any work.
Every rule's impact is visible before it's enforced.
Later
Stage 3
Enforce at chosen boundaries
Add enforcement only where a control earns it — for example, holding invoice postings above the approval threshold, or bank-detail changes without an approved request.
Scoped per tool boundary with you; not part of the read-only pilot.

FAQ

Technical questions

More on data handling, hosting and subprocessors is on the security page.

Do we have to change our agents or route traffic through a proxy?

No. ThetaLayer reads what your agent runtimes and systems of record already record — spans, exports and audit logs — with read-only access. Agents keep using their native connectors, vendor platforms and APIs. Nothing sits in the request path.

What exactly leaves our network?

Only canonical events: schema-validated, minimized records of what happened, with sensitive values hashed or dropped and every transformation listed on the event. Raw records, credentials, the hash key and your identity map stay inside your network. Your security team can preview raw and exported records side by side before anything is sent.

What if an agent platform doesn't return run IDs or document numbers?

Linking falls back to hashed business keys, such as vendor plus supplier invoice number, or to identity and time windows. Confidence drops accordingly — 85% or 70% rather than 95% — and the gap is shown per source and per run instead of being hidden.

How do you handle agents that act with a person's credentials?

Each event records who initiated the work, whose credentials acted and what kind of identity that was. When an agent uses delegated human credentials, the system of record can't tell agent from person, so ThetaLayer flags the delegated identity and lowers link confidence by 10 points. A human token is never treated as an agent identity.

Is this real-time?

Not at first, by design. ThetaLayer starts read-only: it reconstructs runs from evidence as it arrives and re-evaluates history when late evidence, such as approvals and payments, comes in. That means breaches are found after the fact. Enforcement at specific tool boundaries comes later, where you choose it.

How are costs calculated when vendors bill in credits, fees or seats?

Metered costs — tokens times price, or platform credits times credit price — are attributed to each run. Platform fees are allocated across runs (for example, by run count) and labeled as allocated. Sub-agent runs roll up into their parent, and failed or escalated runs still count toward cost per completed workflow.

Book a Demo

Watch a real run get reconstructed.

In 30 minutes we'll walk one workflow end to end — the raw evidence, the links and their confidence, the mandate checks and the cost per outcome — and scope a six-week, read-only pilot around your agents.

Book a Demo See the pilot