Compliance Audit Evidence Guide

This guide explains how to collect, verify, and present Arbitex audit data as evidence in regulatory examinations and compliance audits. It covers the compliance export API, the OCSF event format, HMAC chain verification for audit integrity, and how to produce framework-specific evidence packs for SOC 2, PCI-DSS, HIPAA, and other frameworks.

What Arbitex generates as evidence

For every AI interaction passing through the gateway, Arbitex produces a structured audit record. These records form the evidentiary foundation for compliance reviews.

Evidence type	What it shows	Regulatory use
Audit log entries	Who accessed what model, when, from where; what DLP rules fired; what actions were taken	Demonstrates access controls are in place and operating
HMAC integrity chain	Cryptographic proof that no audit record has been modified or deleted	Satisfies tamper-evidence requirements (PCI-DSS Req 10.5, SOX ICFR)
Policy enforcement records	That governance policies blocked, redacted, or challenged sensitive content	Demonstrates preventive and detective controls
Override audit records	User identity, override reason, and timestamp for every policy exception	Demonstrates accountable exception management
SCIM provisioning logs	User and group provisioning/deprovisioning events	Demonstrates access lifecycle management
SIEM exports (OCSF)	Structured enforcement events forwarded to your security team’s SIEM	Provides the continuous monitoring record auditors expect

Arbitex does not retain prompt content or model responses in the audit log. Only event metadata (entity type detected, rule fired, action taken) is retained. This is by design — it means your audit trail does not itself become a source of sensitive data exposure.

The compliance export API

The compliance export API extracts compliance bundle definitions for documentation. Use it to demonstrate that specific compliance frameworks (HIPAA, PCI-DSS, SOC 2, etc.) are configured and active.

Export all active compliance bundles

curl -s \
  -H "Authorization: Bearer ${ADMIN_TOKEN}" \
  "https://api.arbitex.ai/api/v1/admin/compliance-bundles-export/" \
  | jq '.' > compliance-bundles-$(date +%Y%m%d).json

Sample output:

[
  {
    "name": "HIPAA-PHI",
    "description": "HIPAA Safe Harbor PHI detection and enforcement",
    "regulatory_framework": "HIPAA",
    "version": "2.0",
    "enabled": true,
    "seed_rule_mappings": ["name", "dob", "medical_record", "ssn", "email"],
    "exported_at": "2026-03-13T00:00:00.000000Z",
    "export_version": "1.0"
  },
  {
    "name": "PCI-DSS-Standard",
    "regulatory_framework": "PCI-DSS",
    "version": "1.2",
    "enabled": true,
    "seed_rule_mappings": ["credit_card", "cvv", "card_expiry"],
    "exported_at": "2026-03-13T00:00:00.000000Z",
    "export_version": "1.0"
  }
]

Present this file to auditors as evidence that specific regulatory framework bundles are enabled in your Arbitex deployment.

Export a single framework bundle

# Find the bundle ID
BUNDLE_ID=$(curl -s \
  -H "Authorization: Bearer ${ADMIN_TOKEN}" \
  "https://api.arbitex.ai/api/v1/admin/compliance-bundles" \
  | jq -r '.[] | select(.name == "HIPAA-PHI") | .id')

# Export it
curl -s \
  -H "Authorization: Bearer ${ADMIN_TOKEN}" \
  "https://api.arbitex.ai/api/v1/admin/compliance-bundles-export/${BUNDLE_ID}" \
  > hipaa-bundle.json

Querying audit events by compliance framework

Each audit record includes a framework_reference field that links enforcement events to specific regulatory requirements (e.g., PCI-DSS Requirement 3.4, HIPAA 45 CFR § 164.312).

Filter by framework reference

# Get all enforcement events matching HIPAA requirements
curl -s \
  -H "Authorization: Bearer ${ADMIN_TOKEN}" \
  "https://api.arbitex.ai/api/v1/admin/audit-logs?framework=hipaa&limit=1000" \
  | jq '.' > hipaa-enforcement-events.json

Filter by action type

# Get all BLOCK actions (strongest preventive controls)
curl -s \
  -H "Authorization: Bearer ${ADMIN_TOKEN}" \
  "https://api.arbitex.ai/api/v1/admin/audit-logs?action=block&limit=1000" \
  > blocked-requests.json

# Get all override events (exceptions with justification)
curl -s \
  -H "Authorization: Bearer ${ADMIN_TOKEN}" \
  "https://api.arbitex.ai/api/v1/admin/audit-logs?action=allow_with_override&limit=1000" \
  > override-events.json

Filter by date range (examination period)

Scope your evidence to the examination period. For an annual SOC 2 Type II audit covering the prior 12 months:

# SOC 2 evidence: Jan 1 – Dec 31 2025
curl -s \
  -H "Authorization: Bearer ${ADMIN_TOKEN}" \
  "https://api.arbitex.ai/api/v1/admin/audit-logs?start=2025-01-01T00:00:00Z&end=2025-12-31T23:59:59Z&limit=10000" \
  > soc2-audit-period.json

For large audit periods, paginate using the offset parameter or export via SIEM for bulk retrieval.

OCSF format explained

Arbitex exports enforcement events in OCSF v1.1 (Open Cybersecurity Schema Framework) format when sent to SIEM connectors. OCSF is a vendor-neutral schema that maps directly to compliance evidence requirements.

Key OCSF classes used by Arbitex

OCSF class	Class UID	Arbitex events
Security Finding	2001	DLP blocks, policy enforcement, CredInt hits
Authentication Activity	3002	Login, SSO, MFA events
Account Change	3001	User provisioning, group changes, admin operations

Security Finding fields relevant to compliance evidence

{
  "class_uid": 2001,
  "class_name": "Security Finding",
  "time": 1741824000000,
  "severity_id": 3,
  "status_id": 1,
  "activity_name": "dlp_block",
  "finding": {
    "title": "DLP enforcement — credit_card detected",
    "desc": "Request blocked by policy: pci-dss-standard",
    "uid": "evt_01HZABC123DEF456",
    "rule": {
      "name": "pci-dss-credit-card-block",
      "uid": "rule_01HZ..."
    }
  },
  "cloud": {
    "account": {
      "uid": "org_01HZ..."
    }
  },
  "metadata": {
    "framework_reference": "PCI-DSS Requirement 3.4",
    "entity_type": "credit_card",
    "policy_name": "PCI-DSS-Standard",
    "action": "BLOCK"
  },
  "actor": {
    "user": {
      "uid": "usr_01HZ...",
      "email_addr": "[email protected]"
    }
  }
}

Key fields for compliance evidence presentation:

Field	Compliance significance
`time`	Timestamp of the enforcement event
`activity_name`	Action taken (`dlp_block`, `policy_allow_override`, `prompt_hold_approve`)
`metadata.framework_reference`	Specific regulatory requirement satisfied (e.g., `PCI-DSS Requirement 3.4`)
`metadata.entity_type`	Category of content detected (not the content itself)
`metadata.action`	Policy action (`BLOCK`, `REDACT`, `ALLOW_WITH_OVERRIDE`)
`actor.user.email_addr`	Identity of the user who made the request
`cloud.account.uid`	Organization identifier (for multi-tenant environments)

HMAC chain verification for audit integrity

Before presenting audit logs to examiners, verify the HMAC integrity chain to confirm no records have been tampered with. This is a required step for frameworks like PCI-DSS (Req 10.5) and SOX ICFR.

Verify the chain for an examination period

curl -s -X POST \
  -H "Authorization: Bearer ${ADMIN_TOKEN}" \
  -H "Content-Type: application/json" \
  -d '{"start": "2025-01-01T00:00:00Z", "end": "2025-12-31T23:59:59Z"}' \
  "https://api.arbitex.ai/api/v1/admin/audit/verify" \
  | jq '.'

Expected response — chain intact:

{
  "valid": true,
  "events_checked": 48215,
  "errors": []
}

Response indicating tampering:

{
  "valid": false,
  "events_checked": 48215,
  "errors": [
    "Event 1423: HMAC mismatch (expected 'a3f...', got 'c7d...')",
    "Event 1424: previous_hmac mismatch"
  ]
}

If the verification fails, do not present the log to examiners until the integrity issue is investigated. Contact your Arbitex administrator to determine the root cause (this may indicate a database-level issue, a key rotation problem, or — rarely — tampering).

How the HMAC chain works (for examiner explanation)

Each audit record contains three cryptographic fields:

Field	Description
`hmac_key_id`	Identifier of the signing key used for this record
`previous_hmac`	HMAC of the immediately preceding record
`hmac`	HMAC-SHA256 of this record’s content + `previous_hmac`

The chain is anchored at the first record (previous_hmac = GENESIS_HMAC, a fixed 64-character zero string). Every subsequent record is cryptographically bound to its predecessor. Modifying, deleting, or reordering any record breaks the chain and is detected by the verification API.

Key talking point for examiners: The HMAC chain does not require trusting the database administrator. Even a privileged database user who modified a record would break the chain — the tampering would be visible via the verification API.

SOC 2 report generation

For SOC 2 examinations, assemble evidence across the five Trust Service Criteria:

Security (CC6 — Logical and Physical Access Controls)

Collect:

Audit log query filtered by action=login and action=logout for the examination period — demonstrates access logging
Audit log query filtered by action=policy_block — demonstrates controls preventing unauthorized access to sensitive data
Compliance bundle export showing active access control bundles
Chain verification result (valid: true) for the examination period

# Access events
curl -s -H "Authorization: Bearer ${ADMIN_TOKEN}" \
  "https://api.arbitex.ai/api/v1/admin/audit-logs?category=authentication&start=2025-01-01T00:00:00Z&end=2025-12-31T23:59:59Z" \
  > soc2-cc6-access-events.json

# Policy enforcement
curl -s -H "Authorization: Bearer ${ADMIN_TOKEN}" \
  "https://api.arbitex.ai/api/v1/admin/audit-logs?action=block&start=2025-01-01T00:00:00Z&end=2025-12-31T23:59:59Z" \
  > soc2-cc6-enforcement.json

# Integrity verification
curl -s -X POST -H "Authorization: Bearer ${ADMIN_TOKEN}" \
  -H "Content-Type: application/json" \
  -d '{"start":"2025-01-01T00:00:00Z","end":"2025-12-31T23:59:59Z"}' \
  "https://api.arbitex.ai/api/v1/admin/audit/verify" \
  > soc2-cc6-chain-verification.json

Availability (A1 — System Availability)

Collect:

Outpost heartbeat monitoring logs (if using Hybrid Outpost)
Platform uptime records from your monitoring system
Kill switch operation logs for any service interruptions

Confidentiality (C1 — Confidential Information is Protected)

Collect:

DLP enforcement events showing redaction and blocking of confidential content
Compliance bundle export showing active confidentiality controls
SIEM OCSF export showing enforcement event frequency and distribution

Processing Integrity (PI1 — Completeness and Accuracy)

Collect:

Audit records showing policy chain evaluation for the examination period
Override audit records (any exceptions are logged with user identity and reason)
Model routing logs showing requests were directed to authorized providers

Privacy (P-series criteria)

Collect:

REDACT action audit events (demonstrates de-identification controls)
Policy rules showing data minimization configurations
Audit log confirming prompt/completion content is not retained

Framework-specific evidence filters

PCI-DSS

Requirement	Evidence query	Output file
Req 3 — Protect cardholder data	`?action=block&entity_type=credit_card`	`pci-req3-blocks.json`
Req 10 — Track and monitor	All audit events for examination period	`pci-req10-full-log.json`
Req 10.5 — Protect audit trails	Chain verification result	`pci-req10-chain-verify.json`

# PCI-DSS evidence pack
curl -s -H "Authorization: Bearer ${ADMIN_TOKEN}" \
  "https://api.arbitex.ai/api/v1/admin/audit-logs?framework=pci_dss&start=2025-01-01T00:00:00Z&end=2025-12-31T23:59:59Z" \
  > pci-enforcement-events.json

curl -s -X POST -H "Authorization: Bearer ${ADMIN_TOKEN}" \
  -H "Content-Type: application/json" \
  -d '{"start":"2025-01-01T00:00:00Z","end":"2025-12-31T23:59:59Z"}' \
  "https://api.arbitex.ai/api/v1/admin/audit/verify" \
  > pci-chain-verification.json

HIPAA

§ Reference	Evidence query	Output file
§ 164.312(b) — Audit controls	All audit events	`hipaa-audit-controls.json`
§ 164.502 — Uses and disclosures	`?action=block&framework=hipaa`	`hipaa-disclosures.json`
PHI enforcement activity	`?entity_type=medical_record,dob,ssn`	`hipaa-phi-enforcement.json`

SOX

# SOX evidence — financial data enforcement events
curl -s -H "Authorization: Bearer ${ADMIN_TOKEN}" \
  "https://api.arbitex.ai/api/v1/admin/audit-logs?framework=sox&start=2025-01-01T00:00:00Z&end=2025-12-31T23:59:59Z" \
  > sox-enforcement-events.json

# SOX evidence — override audit (exceptions with justification)
curl -s -H "Authorization: Bearer ${ADMIN_TOKEN}" \
  "https://api.arbitex.ai/api/v1/admin/audit-logs?action=allow_with_override&start=2025-01-01T00:00:00Z&end=2025-12-31T23:59:59Z" \
  > sox-override-events.json

Presenting evidence to examiners

Pre-examination checklist

Before your examination date:

Run chain verification for the full examination period and confirm valid: true
Export compliance bundle definitions showing all active frameworks
Pull enforcement event queries for each framework in scope
Confirm audit log retention covers the full examination period (Arbitex default: 90-day hot + 2-year archive)
Export SIEM data for the examination period if your examiner requires OCSF-formatted evidence
Document your policy chain configuration (Admin → Policy Engine → Policy Chain export)

Evidence file naming convention

Organize evidence files by framework and date range:

evidence/
├── chain-verification-2025-01-01--2025-12-31.json
├── compliance-bundles-export-2026-03-13.json
├── pci-dss/
│   ├── pci-enforcement-events-2025.json
│   └── pci-chain-verification-2025.json
├── hipaa/
│   ├── hipaa-enforcement-events-2025.json
│   └── hipaa-phi-blocked-2025.json
├── sox/
│   ├── sox-enforcement-events-2025.json
│   └── sox-override-audit-2025.json
└── soc2/
    ├── cc6-access-events-2025.json
    ├── cc6-enforcement-events-2025.json
    └── chain-verification-2025.json

Examiner talking points

“How do you know the audit log hasn’t been tampered with?”

“Each audit record is HMAC-SHA256 signed and cryptographically linked to the previous record. We can run the chain verification API on demand. The verification checks every record in the requested period and returns either valid: true with a count of records checked, or specific error messages identifying any tampered record by index.”

“How do you ensure sensitive data detected by DLP is not retained in the audit log?”

“By design, Arbitex logs the type of entity detected (e.g., credit_card) and the action taken (e.g., BLOCK), but not the matched content. The prompt and completion text are never written to the audit log. The only text retained in audit records for override events is the user-supplied justification — which the user explicitly provides and is expected to be logged.”

“How do you demonstrate that controls are operating continuously, not just at audit time?”

“SIEM integration exports OCSF-formatted enforcement events in near real-time. Your security team can show SIEM dashboards with enforcement event frequency and distribution over the examination period. The events are timestamped in the audit record and cannot be retroactively added — they were generated at the time of the interaction.”

“What happens if a user tries to override a policy block?”

“BLOCK is a hard stop — there is no override path. For policies configured with ALLOW_WITH_OVERRIDE, the user must provide a written justification. Both the justification and their identity are written to the audit log before the request proceeds. Override events appear in the audit export with action=allow_with_override and include the full reason text.”

Retention and archival

Arbitex’s default audit retention:

Tier	Retention	Notes
Hot (queryable via API)	90 days	Full-text search via audit API
Archive (Azure Log Analytics)	2 years	Immutable; retrievable via SIEM export

For frameworks requiring longer retention (BSA/AML requires 5 years, SEC 17a-4 requires 3–6 years depending on record type), configure your SIEM to retain OCSF exports for the required period. The SIEM is the system of record for long-term retention; Arbitex provides the event stream.

Compliance Audit Evidence Guide

What Arbitex generates as evidence

The compliance export API

Export all active compliance bundles

Export a single framework bundle

Querying audit events by compliance framework

Filter by framework reference

Filter by action type

Filter by date range (examination period)

OCSF format explained

Key OCSF classes used by Arbitex

Security Finding fields relevant to compliance evidence

HMAC chain verification for audit integrity

Verify the chain for an examination period

How the HMAC chain works (for examiner explanation)

SOC 2 report generation

Security (CC6 — Logical and Physical Access Controls)

Availability (A1 — System Availability)

Confidentiality (C1 — Confidential Information is Protected)

Processing Integrity (PI1 — Completeness and Accuracy)

Privacy (P-series criteria)

Framework-specific evidence filters

PCI-DSS

HIPAA

SOX

Presenting evidence to examiners

Pre-examination checklist

Evidence file naming convention

Examiner talking points

Retention and archival

See also