When someone asks what the AI did, have the answer.
Auditors, regulators, and incident responders all ask the same thing: who accessed what, through which model, under which rule, and what happened next. Control writes that record for every AI interaction to an append-only log inside your environment, with retention you set.
One record per request, with the full chain of custody.
Each record ties the people and agents involved to the decision, the policy that made it, the sources that were used, and the outcome. The record is content-free: prompt text, documents, and tool argument values are never written to it, only identifiers and hashes.
{
"event_id": "evt_01JC9Q4…",
"time": "2026-11-04T14:22:07.311Z",
"subject": {
"user": "user:m.chen",
"agent": "agent:claims-triage",
"delegation": "on_behalf_of"
},
"action": "search",
"resource": { "dataset": "claims.inbound" },
"classification": ["PHI"],
"decision": "allow",
"policies": ["pol_region_001", "pol_dlp_001"],
"model": "local:llama-70b",
"sources": [
{ "doc": "claims/2026/11/C-48812.pdf", "version": "v3" }
],
"tools": [],
"content": { "prompt": "sha256:…", "response": "sha256:…" }
}Illustrative example · final API surface documented in /docs
What reviewers ask, and the fields that answer it.
| Question | Answered from |
|---|---|
| Who accessed PHI through AI tools last quarter? | subject, classification, decision, time |
| Which agent took this action, and for whom? | subject.agent, subject.user, delegation |
| Why was this request allowed? | policies (IDs and versions in effect at the time) |
| Which documents did this answer draw on? | sources with document version |
| Did regulated data reach an external model? | model, classification, decision |
| Who approved this write? | linked approval record: approver, time, decision |
Built to be relied on as evidence.
Append-only
Records are written once. Corrections are new records, so history is never silently rewritten.
Local by design
The log lives in your environment. Hosted Data.co services never receive it, which keeps sensitive context out of a vendor's systems.
Policy-versioned
Each decision references the policy versions in effect, so you can show which rule applied on the day, even after it changed.
Content-free records
Records carry identities, resources, decisions, policy IDs, and hashes, never prompt text or tool argument values, so the evidence store does not become a second copy of regulated data.
Retention you set
Configure retention to match your obligations. Export to storage you control, including write-once storage, for longer holds.
Exportable
Filter by time, identity, dataset, classification, or decision and export for auditors, SIEM ingestion, or legal hold.
From an alert to a defensible answer.
- 1
Scope
Filter by identity, dataset, or time window to find every related request.
- 2
Reconstruct
Follow delegation chains, tool calls, and approvals linked to each request.
- 3
Explain
Show the policy versions that decided each request and the reason they returned.
- 4
Export
Produce a filtered evidence file locally and hand it to the reviewer or counsel.
A hash chain, so edits are detectable rather than merely forbidden.
Saying a log is append-only only describes what the product allows. Evidence also has to show that nothing was changed underneath it. In the customer-local runtime each record carries a sequence number, a timestamp, the event, and the hash of the record before it, and its own hash is computed over all of those. Modifying, deleting, inserting, or reordering any record breaks the chain from that point forward, and a verification command walks the chain and reports where it breaks.
Writes are synchronous. If a decision record cannot be written, the request it describes is denied, so there is no window in which actions happen without a trace. The runtime also verifies the tail of the log at startup and refuses to start on a broken chain. When a file reaches its size limit it is rotated into an immutable segment named for its first and last sequence numbers, and the chain continues into the next file.
A chain proves internal consistency, not that the whole log was not replaced wholesale. For that, record the latest sequence number and head hash somewhere separate, such as a ticketing system or write-once storage, on a regular schedule. Anyone can then confirm that the log presented at audit time extends the head you recorded earlier.
Running the audit log as evidence.
- Back up rotated segments as they appear; they never change
- Snapshot the active file and the approvals store on a schedule
- Archive segments as a complete set so verification can start at the first
- Record the head sequence and hash outside the runtime host
- Run chain verification before producing evidence for a review
- Ship content-free records to your SIEM for correlation
- Align retention with your legal and regulatory obligations
- Restrict who can read the log with the same care as the data it describes
Questions buyers ask
Where is the audit log stored?
In the Control runtime inside your environment, on storage you provision. It is not sent to app.data.co, and you can ship exports to your SIEM or archive.
Do you store full prompts and responses in the audit log?
No. Decision records are content-free by design: they hold identifiers, decisions, policy IDs, dataset names, argument names, and hashes. A hash can show that a specific input was evaluated without keeping the sensitive text in a second place.
Can an administrator delete or edit records?
The log is append-only through the product. Retention expiry is the defined way records are removed, and changes to retention settings are themselves logged. For stronger guarantees, export to write-once storage you control.
Is this enough for a HIPAA or SOC 2 audit?
It is designed to support those audits with per-request access evidence. Your auditors decide what evidence they need, and your compliance team maps these records to the specific controls in scope.
Are denied requests logged?
Yes. Denials and pending approvals are recorded with the same detail as allowed requests, which is often what reviewers want to see first.
What else is recorded besides AI requests?
Approval changes, administrative actions, license changes, and authentication failures are written to the same chain, so a reviewer can see who changed a policy or approved an action alongside the requests it affected.
What happens if the disk holding the log fills up?
A failed write causes the request to be denied, so the runtime fails closed rather than continuing without a record. Monitor free space and rotation the way you would for any system of record.
See it against your own use case.
A 30-minute technical walkthrough, policy simulation on your scenarios, and a deployment recommendation for on-prem, private cloud, or hybrid.