Every request,
on the record.

Astry writes an append-only journal of every query, every file the model could see and every answer it returned. The database itself refuses edits and deletes, and logging never blocks a request.

Book a call See access control

Security

Audit log.

Append-only record of every request, projection and capture.

Export CSV

When	Who	Action	Resource	Source	Latency
14:32:08	Claire Fontaine u_8f2c	ask.query	vault://finance/**	web	812 ms
14:31:44	Martin Bonan u_01ab	capture.sync	slack/#infra-deals	connector	96 ms
14:29:12	Anna Meyer u_44e0	ask.query	vault://mandates/vinci/**	web	1.02 s
14:26:51	Trust Layer sys	acl.project	sandbox://u_44e0	system	38 ms
14:25:03	Téo Dagher u_c791	wiki.read	wiki/decisions/pricing-vinci	web	44 ms
14:21:39	DLP sys	dlp.redact	drive/Q3_Payroll.xlsx	system	121 ms
14:18:20	Claire Fontaine u_8f2c	ask.query	vault://benchmarks/**	web	788 ms
14:12:57	API key · prod k_2210	ingest.push	api/v1/documents	api	203 ms

Append-only · query, files touched, latency, cost

A record that holds up.

Each entry captures the query, the files the model could see, the action, its latency and its cost. Nothing is edited after the fact, and writing it never slows the answer down.

Append-only at the database

The application's database role can only insert and read. Update and delete are revoked, so a past entry cannot be edited or removed.

Every file the model could see

Each request records the exact file IDs projected into its sandbox. You see precisely what the model could read, not a guess.

See the Trust Layer

Never blocks a request

Logging runs alongside the answer. A slow or failed write can never hold up a response or drop a record.

Anomaly detection

Astry flags access that breaks the normal pattern for an account, so unusual reads surface for review.

Dual-written and exportable

Every entry lands in both JSONL and Postgres. Export to CSV, or ship the JSONL stream to your own SIEM or warehouse.

See audit in the app

Erasure that records itself

GDPR Article 17 erasure and DSAR requests run through dedicated tooling, and the deletion writes its own entry to the journal.

Read the DPA

Answer an audit in three moves.

When a regulator or a security team asks who saw what, you do not reconstruct it. You filter, you trace, you export.

01
Filter
Narrow the journal by user, time window or source. Find the exact requests in question without scrolling endless rows.
02
Trace
Open a request to see every file the model could see for that answer. The projected set is recorded, not inferred.
03
Export
Export exactly those requests as CSV. Because the journal is append-only, the export is the record, not a copy someone could have edited.

The audit layer, in detail.

Record: Query, files the model could see, action, latency and cost.
Storage: Dual-written to JSONL and Postgres, workspace-scoped.
Mutability: Database role has INSERT and SELECT only; UPDATE and DELETE revoked.
Blocking: Logging never blocks a request.
Anomaly detection: Built-in; flags access that breaks the normal pattern.
Erasure: GDPR Art. 17 and DSAR tooling; the deletion is itself recorded.

Good to know.

No. The application's database role can only insert and read entries; update and delete are revoked at the database itself. A past entry cannot be edited or removed, including by us, and each entry is also written to a JSONL stream you keep.

Answer the next audit from the record.

Filter the journal, trace a request, export exactly what was asked. The evidence is already written, and the database will not let anyone edit it.