Audit log: recorded events, coverage gaps, and verification

Lists which events Duale AI records in its audit log, identifies coverage gaps, and explains how to verify record content.

This page covers Duale AI audit log coverage, gaps, Tool Analytics, query limits, and hash verification of record content.

Audit log coverage: recorded events and their content.
Audit log gaps: events with no Platform record.
Tool Analytics aggregate outcomes and their limits.
Query capabilities, access tiers, and search limitations.
Hash verification of record content and anchoring limits.

Summaries were generated by AI.

Use the audit log as supporting evidence for the events below. When a business, audit, contractual, legal, support, or recovery need depends on a missing event, the gap table identifies evidence an existing customer system can keep.

When you must retain an approval, decision, or exception, keep it in its existing change or business record. Platform records can support that record, but they do not contain the customer’s decision.

What Duale AI records

Use the audit log to support these events:

Recorded	What the record carries
Tenant, Agent Identity, member, token, and invitation changes	Who acted, what changed, before and after
Configuration changes, including model routes	The change, with secret values redacted
Configuration and directory reads	An access event
Tenant policy, group, and binding changes	The reported change and the resolved acting identity
Platform-supplied policy and role changes	The version, policy-definition and supplied-group changes, and group-level grant diff, with audit-only `system` provenance
Library access-grant changes	The subject, action, and effect of the grant
Task lifecycle	Completion, timeout, and stop
Tool requests	The name of each Built-in, SDK, or MCP Tool that a Task sent a request to, recorded when Duale AI sends the request
Authorization decisions	A sample of decisions: a repeated check within a short time is not recorded again
Credential refusals with an identified Tenant	The presented key identifier, refusal reason, and acting identity when resolved

Use these entries as supporting evidence, then check the next section for the records that do not exist. Default policies explains why a supplied-policy definition diff does not prove that every Tenant member’s effective permissions changed. Credential lifecycle explains how to correlate recorded refusals and where the coverage stops.

An event marked success reports the outcome that the acting component reported. The record alone does not prove that the corresponding state change committed; if that distinction matters, check the current resource state or the owning change record.

What Duale AI does not record

Each row is a record an auditor routinely assumes exists. None of them does.

Not recorded	What no record can show	Possible customer evidence
Document lifecycle actions. Uploading or deleting a document in a Library raises no audit event.	Who uploaded or deleted a document	An existing action record, written at that moment, when you need this proof
Document reads. A Task reading a document raises no audit event.	Which document a Task read	Not available from current public interfaces
Policy-change approval. A record of an applied policy change does not contain your approval decision.	Who approved that change and against what evidence	The existing change record, when approval must be retained
Every authorization decision. The record holds a sample of decisions, not every one.	A complete access-decision history	Nothing
Credential refusals before Tenant identification. A refused platform token that Duale AI cannot link to a Tenant is not in that Tenant’s log.	Every presentation of an expired or deleted platform token	Failure information returned to your own client
Per-call Tool completion and result. The Tool request record is made when Duale AI sends the request, before the Tool runs.	Whether one specific Tool ran, succeeded, or what it returned	The owning Tool or business record; Tool Analytics provide aggregates only
Model selection. The Tool request record names the Tool, not the model choice.	Why a given model ran a Task	Usage analytics show provider and model for recorded work. Nothing records the reason
Why two comparable Tasks differ. Duale AI can change how it ranks routes, and no record names the ranking a Task used.	Why two otherwise comparable Tasks differ	Nothing
Model-pool approval. A configuration change does not contain the customer’s approval evidence.	Who approved the change and against what evidence	The existing change record, when approval must be retained
Library-sharing approval. A Grant record describes the applied rule, not the customer’s approval decision.	Who approved the share and for what purpose	The existing change record, when approval must be retained
Task Result acceptance. Business acceptance is not a Platform event.	Why your application or reviewer accepted a result	The existing business record, when acceptance evidence is required

Use Tool Analytics for aggregate outcomes

Tool Analytics in the Dashboard counts one final outcome for each requested Tool Call, not each retry, and aggregates those outcomes across the Tenant and by Tool Source, model-facing Tool name, and Agent Identity. The aggregates can show whether a Connection or Tool fails more often and which Agent Identities use it. They do not expose arguments or results, identify the effect of one call, or prove that the destination system changed.

Operate Tools owns the outcome categories, the confirmed success rate, and when that rate appears. Tool Call outcomes defines what each outcome means.

What you can query, and what you cannot

The Dashboard queries records by tenant, action, resource type, resource identifier, and time range. One page contains 100 records by default and at most 1,000. An export contains at most 100,000 records and uses JSONL or CSV.

There is no filter by acting person and no free-text search. A request for every event concerning one person cannot be answered through this query interface. If these records concern an identifiable person and your obligations include data-subject requests, plan that procedure around this limit.

Reads of the audit log are themselves recorded.

Audit operations use the Tenant-scoped resource audit:<tenant_id>. Querying records requires audit:read_events, exporting them requires audit:export_events, and requesting a proof requires audit:read_proof.

With the supplied human tiers, an Administrator can query and export records and request proofs. A Viewer can query records and request proofs but cannot export them. An Editor has no audit access.

You can verify record content, not append-only anchoring

When you request a proof for one event in the Dashboard, your browser checks the hash and shows the result. To check records yourself, export them: each export row carries the exact canonical_event_data text and its content_hash. Compute SHA-512 over the UTF-8 bytes of canonical_event_data, without parsing or reformatting it, and compare the lowercase hexadecimal result with content_hash.

A match proves that the exact returned canonical text produces the returned stored hash. It detects a change to that text unless the hash changes with it.

The canonical text omits user_context, which can describe a person or Agent Identity together with request context, or carry the exceptional audit-only system origin of a supplied-policy change. It never makes a service a Tenant actor. Duale AI encrypts that object separately, but this hash check does not cover it. A matching hash verifies none of those actor or request-context fields. Identity defines these distinctions.

You cannot verify the append-only anchoring independently today. The interface returns transaction values but no inclusion path and no independently trusted root. Treat that anchoring as an internal integrity control. Do not present it to an auditor as independently verified tamper evidence.

Link a Platform failure to your own records

When a Platform failure needs support or reconciliation, store each request, trace, or span identifier it carries with the owning business record, and include the available identifiers in a support request. Errors and reliability defines how the SDK exposes them.

When a business record must correlate a Task with Platform evidence, store the Task identifier when you submit the Task, not only after a failure. It is the durable link between those records.

Assign owners and record the change lists fields for a material change record.

Retain customer-held evidence only for its owning purpose and period. Do not copy prompts, credentials, or unrelated personal data merely to fill a Platform audit gap.

Contractual notification, data-return, deletion, audit, and availability terms belong to the legal documents, not to this record inventory.

Return to Security to place these records in the lifecycle of one Task.