Evidence

Compliance reporting

Export your governance record as CSV or JSON over any date range, generate a period report, and verify the chain that backs both. What Arcus can evidence — and what it cannot.

What Arcus gives an auditor#

Most AI governance claims are policy documents. "Agents may not access production data without approval" is a statement of intent, and an auditor's next question is how you know it held.

Arcus's answer is a sealed sequence of decisions. Not a description of the control — the control's own record of every time it ran, what it decided, and who overrode it.

That last row is the one that tends to matter most in review, and it is why rule changes live in the same chain as the decisions. A control that can be silently disabled is not a control; a control whose disabling is a sealed, attributed, timestamped event is.

Exporting the record#

curl -sS "$ARCUS_URL/v1/admin/compliance/export?format=csv&from=2026-07-01&to=2026-07-31" \
  -H "Authorization: Bearer <clerk-session-token>" \
  -o arcus-audit-2026-07.csv

CSV for a spreadsheet or a reviewer who wants to sort and filter. JSON when the destination is a SIEM, a warehouse, or your own verification script — it preserves the hash and prevHash fields, so an export can be re-verified independently of Arcus.

# Monthly JSON archive
curl -sS "$ARCUS_URL/v1/admin/compliance/export?format=json&from=2026-07-01&to=2026-07-31" \
  -H "Authorization: Bearer <clerk-session-token>" \
  -o "arcus-audit-2026-07.json"

Period reports#

curl -sS "$ARCUS_URL/v1/admin/compliance/report?from=2026-07-01&to=2026-07-31" \
  -H "Authorization: Bearer <clerk-session-token>"

A summarised report rather than a row dump: dispatch volume, the distribution of enforcement outcomes across the five gates, approval activity, credential lifecycle events and configuration changes in the window.

This is the artefact for a quarterly review or a board pack — the shape of what your controls did, without asking a reader to interpret thousands of rows.

Reports require the reports capability (Max). The underlying data is available on every plan via the export endpoint plus /v1/admin/audit/events; what Max adds is the summarisation.

Verifying before you file#

Export and verification belong together. An export is a copy of the record; verification is the statement that the record was intact when the copy was taken.

#!/usr/bin/env bash
# Monthly: verify, then archive. Refuse to archive a broken chain.
set -euo pipefail

MONTH="${1:?usage: archive.sh 2026-07}"
AUTH="Authorization: Bearer ${ARCUS_SESSION_TOKEN}"

verdict=$(curl -sS "$ARCUS_URL/v1/admin/audit/verify" -H "$AUTH")
echo "$verdict" > "arcus-verify-${MONTH}.json"

if ! grep -q '"valid":true' <<<"$verdict"; then
  echo "CHAIN VERIFICATION FAILED — investigate before archiving" >&2
  echo "$verdict" >&2
  exit 1
fi

curl -sS "$ARCUS_URL/v1/admin/compliance/export?format=json&from=${MONTH}-01&to=${MONTH}-31" \
  -H "$AUTH" -o "arcus-audit-${MONTH}.json"

echo "archived ${MONTH}: chain verified, export written"

Keep both files. The verification result is what lets you say the chain was intact at a known point in time, rather than only that it is intact now.

Mapping to control frameworks#

Arcus is not a certification and does not make you compliant with anything. What it provides is technical evidence that specific control objectives were enforced. The mapping below is offered so you can point an assessor at the right endpoint — your own auditor decides what satisfies them.

Retention and what to keep#

Every event is written on every plan. Free limits how far back you can read — upgrading reveals history that was recorded all along. If you are on Free and compliance evidence matters, export on a schedule from day one, because the 7-day read window is the constraint, not the record.

What Arcus deliberately does not record#

Stating this plainly is more useful to an auditor than a claim of completeness.

• Payload bodies of completed dispatches. Only payloadSize. Arcus is a gateway, not a copy of your data — and a governance system holding a second copy of every message is a larger liability than the one it mitigates.
• DLP matched values. Category and path only, on every plan. Echoing the secret it caught would copy that secret into a place with looser access control.
• Destructive-pattern regexes. The catalogue's ids, labels and severities are exposed; the patterns are not, because publishing them would document the bypass.
• Your target's response body. Arcus records the HTTP status, not what came back.
• Anything about model behaviour. Arcus governs the requests an agent makes. It has no view of prompts, completions, tool selection or reasoning.

If your control objective needs full message-content retention, that has to be built at your receiving endpoint, where the data legitimately lands.

Presenting this to a reviewer#

The sequence that lands best, in practice:

1. Show the policy list. This is the complete set of destinations any agent can reach. Anything not on it is refused by default.
2. Send a dispatch that gets refused. A live 422 with a DLP category is more convincing than any document — the control is running while they watch.
3. Open the audit view. The refusal they just triggered is there, in sequence, with a hash.
4. Click verify. The chain covering their own test is confirmed intact.
5. Hand over the export. They can re-verify it themselves, offline, without your database.

Steps 2 through 4 take about ninety seconds and convert "you have a governance layer" from a claim into something they observed.