What the SAGARIS audit trail records, and what it does not

What is recorded, and where

The activity trail

The agent's tool calls at every stage they reach and its runs, agent decisions, grounded AI responses, consent changes, lead assignment and book reassignment, committed contact and opportunity imports, GDPR erasures including the ones that were blocked, compliance sweeps, the SMS send gate, and webhook subscription lifecycle. Each row carries the workspace, the acting user and the action name, with columns for the model, tokens, latency and a structured input and output that not every writer fills in.

The configuration trail

Before and after on the settings that change how the product behaves: the workspace autonomy level, business hours, the recording-consent override, report branding, API keys created and revoked, and the inbound transcript webhook token being rotated.

The export trail

One row per attempt on the data export routes, allowed or refused, naming the export type, the permission checked, the record count and the format. Downloading a saved report as a file is not in this trail.

The import trail

One row per imported record rather than a summary: the row number, what it landed on, whether it was accepted, skipped, deduped or failed, and the reasons.

The model usage ledger

Every model call made through the SAGARIS model gateway, with its provider, purpose, token count, latency and whether it succeeded. The gateway writes the row before the call starts and refuses the call if it cannot. A few model calls do not go through the gateway, among them call transcription, generated speech and the classifier that decides how a dialed call was answered, so this is not a record of every model call.

The writing agents' traces

One row per model call made by the agents that research contacts and write sequence and follow-up messages: the prompt as sent and the raw response, each kept in full, the parsed output, tokens, cost, latency, and the contact, sequence and step it was for.

• Which AI sales tools keep an audit trail? The buyer's version of this page: what SAGARIS records about what its AI did, who can read it, and what it does not cover.

Who can read what

Reading is split deliberately, because an audit row's payload can contain the content of the thing being audited.

• Any workspace member can read the activity trail in summary: the action, the actor, the model, tokens, latency and the timestamp. The model usage ledger is member-readable in the same way.
• The input and output payload on an activity row requires an admin workspace role. Asking the JSON endpoint for it as a non-admin is a 403 rather than a row with the payload quietly stripped; the audit page in the product simply shows a non-admin the summary.
• The writing agents' traces, prompt and response included, are readable by any member of the workspace. That is wider than the activity payload, and worth knowing when deciding who belongs in a workspace.
• The configuration trail and the control-plane events are admin-only in the workbench. A non-admin is told they are admin-only rather than shown an empty list, so an absence is never mistaken for silence.

Retrieving it

The audit workbench in the product is the reading surface: the four sources merged into one reverse-chronological list, most recent first, capped at a hundred rows per source.

There is also a session-authenticated JSON endpoint for the activity trail, filterable by action name and by acting user, and paged with an offset and a limit that defaults to fifty and is capped at a hundred. It returns an exact total count and a has_more flag alongside the rows. Asking for the payload is a query flag, and it is the flag the admin check applies to. The row-level import trail is retrieved per import job.

Two things this log does not claim

It is not tamper-evident, and we would rather say so than let the phrase audit log imply it. A tamper-evidence endpoint exists and it answers honestly: the rows carry no stored hash links, so it reports that no persisted chain is available and returns a not-implemented status rather than a verification result. Rebuilding a chain from the current rows would only prove the freshly built payload is internally consistent, which is not evidence that a historic row was never edited or removed.

There is also no retention control. The product does not offer a configurable audit retention period, and nothing trims the trail on a schedule. Call recordings do carry a retention setting; the audit log does not, and you should not read a recording retention number as applying to it.