Audit log

Every request that passes through Arbitex Gateway produces an audit log entry. The audit log is a tamper-evident record of what happened: which user sent a request, which provider received it, what the 3-tier DLP pipeline detected, what the Policy Engine decided, and what action was taken. Log entries are immutable — no user role, including account owner, can modify or delete them.

The audit log is a 90-day buffer. Your security information and event management (SIEM) system is the record of truth for long-term retention. Arbitex provides the real-time pipeline and the integrity verification mechanism; your infrastructure owns the archive.

Audit entry fields

Each audit log entry contains the following fields:

Request metadata

Field	Type	Description
request_id	string	Unique identifier for the request — present in the X-Request-ID response header
timestamp	string	UTC timestamp with millisecond precision (ISO 8601)
org_id	string	Organization identifier
user_id	string	Identity of the user who sent the request, from the authentication context
provider	string	The AI provider that received the request (e.g., anthropic, openai)
model	string	The model identifier used to serve the request
routing_mode	string	Routing mode: Single, Compare, or Summarize

Policy evaluation fields

Field	Type	Description
outcome	string	Final outcome: ALLOW, BLOCK, CANCEL, REDACT, or ROUTE_TO
matched_pack_id	string	ID of the policy pack containing the matching rule; null if no rule matched
matched_rule_id	string	ID of the specific rule that matched; null if no rule matched
matched_sequence	integer	Sequence position of the matching rule in its pack
match_reason	string	Human-readable explanation of why the rule matched
action_taken	string	The enforcement action that was executed
applies_to	string	Whether the match was on input, output, or both

DLP findings

Field	Type	Description
dlp_findings	array	List of findings from the 3-tier DLP pipeline. Each finding includes: entity_type, tier (1, 2, or 3), confidence, action, and bundle_id if the finding triggered a Compliance Bundle rule
entity_types_detected	string[]	Deduplicated list of entity types detected across all DLP tiers

Credential Intelligence fields

Field	Type	Description
credint_enabled	boolean	Whether Credential Intelligence was active for this request
credint_hit	boolean	Whether credential material in the request matched the breach corpus
frequency_bucket	string	Exposure severity: Critical, High, Medium, Low, or null if no match
context_type	string	Context in which the credential appeared: password, api_key, connection_string, or similar
sha1_prefix	string	8-character SHA-1 prefix used for corpus lookup — not the full credential hash
credint_confidence	float	Detection confidence score (0.0–1.0)

Network and GeoIP enrichment

Field	Type	Description
src_ip	string	Client IP address, from X-Forwarded-For or direct connection
src_country_code	string	2-letter country code for the source IP
src_country_name	string	Country name for the source IP
src_region	string	Region or state
src_city	string	City
src_isp	string	ISP name
src_asn	string	Autonomous system number
src_asn_org	string	Organization name for the ASN
src_arin_org	string	ARIN organization (when available)
dst_ip	string	IP address of the model provider endpoint
dst_country_code	string	Country code for the provider endpoint
dst_asn	string	ASN for the provider endpoint
dst_asn_org	string	Organization name for the provider endpoint ASN

GeoIP enrichment happens at event time using offline datasets loaded into memory at startup. If a dataset is unavailable, the corresponding GeoIP fields are null — the audit entry is still written.

Performance fields

Field	Type	Description
stage_latencies	object	Milliseconds for each pipeline stage: intake, payload_analysis, policy_evaluation, provider_call
total_latency_ms	integer	End-to-end latency for the request in milliseconds

SIEM fields

Field	Type	Description
siem_forwarded	boolean	Whether the entry was forwarded to your configured SIEM connector
hmac	string	Hash-based message authentication code (HMAC) for this entry — used for tamper-evidence verification
prev_hmac	string	HMAC of the preceding audit entry — the chain link

HMAC chain verification

Audit log entries are chained using HMAC to provide tamper evidence. Each entry’s HMAC is computed over a fixed set of 17 fields including all request metadata, source and destination IP addresses, and the preceding entry’s HMAC value.

This chain means that modifying or deleting any single audit entry invalidates the HMAC of every subsequent entry in the sequence.

Fields included in HMAC computation:

• All request metadata fields (request_id, timestamp, org_id, user_id, provider, model, routing_mode)
• src_ip, dst_ip (observed network facts)
• Policy evaluation fields (outcome, matched_pack_id, matched_rule_id, action_taken)
• prev_hmac (the chain link from the preceding entry)

Fields excluded from HMAC computation:

• GeoIP enrichment fields (derived from datasets that may be updated between verifications)
• CredInt enrichment fields (derived, not observed)

This separation means that upgrading your GeoIP datasets does not invalidate existing HMAC chains.

flowchart LR
    IV["Init Vector"] --> E1["Entry 1\nHMAC₁ = HMAC(fields + IV)"]
    E1 --> E2["Entry 2\nHMAC₂ = HMAC(fields + HMAC₁)"]
    E2 --> E3["Entry 3\nHMAC₃ = HMAC(fields + HMAC₂)"]
    E3 --> EN["Entry N\nHMACₙ = HMAC(fields + HMACₙ₋₁)"]

    style E2 fill:#fdd,stroke:#c33
    linkStyle 1 stroke:#c33

If any entry is tampered with, every subsequent HMAC in the chain becomes invalid, making the point of modification immediately detectable.

Verifying the chain

To verify the integrity of your audit log:

1. Export the audit log for a time range using the export API
2. Sort entries by timestamp in ascending order
3. Starting from the first entry (where prev_hmac is the initialization vector), recompute the HMAC for each entry using the HMAC secret available in Settings > Audit > HMAC Keys
4. Compare each computed HMAC against the stored hmac field
5. Any mismatch indicates tampering or corruption at that point in the chain — all entries after the mismatch are suspect

The HMAC algorithm is HMAC-SHA256. The initialization vector for the first entry in a sequence is documented in the HMAC key metadata.

Important: Store your HMAC keys outside the Arbitex platform. If the platform were compromised, an attacker with access to both the log entries and the HMAC keys could recompute a valid-appearing chain. Your SIEM is the appropriate location for HMAC key escrow.

Retention

Arbitex retains audit logs for 90 days. After 90 days, entries are purged from the platform database. The 90-day window covers quarterly compliance review cycles and typical incident response timelines.

For long-term retention, configure SIEM integration to stream audit events in real time. Your SIEM becomes the record of truth for any audit period beyond 90 days. Arbitex does not offer extended retention within the platform.

Export API

Export audit log entries via the admin API:

GET /api/admin/orgs/{org_id}/audit-log?start=2026-03-01T00:00:00Z&end=2026-03-08T23:59:59Z
Authorization: Bearer your-arbitex-api-key
Accept: application/json

{
  "entries": [
    {
      "request_id": "req_01HZ8X9K2P3QR4ST5UV6WX7YZ",
      "timestamp": "2026-03-08T14:32:01.847Z",
      "org_id": "org_acme",
      "user_id": "usr_alex_johnson",
      "provider": "anthropic",
      "model": "claude-sonnet-4-20250514",
      "routing_mode": "Single",
      "outcome": "ALLOW",
      "matched_pack_id": null,
      "matched_rule_id": null,
      "dlp_findings": [],
      "credint_hit": false,
      "siem_forwarded": true,
      "hmac": "a3f8d2...",
      "prev_hmac": "b1c9e4..."
    }
  ],
  "cursor": "eyJ0aW1lc3RhbXAiOiIyMDI2LTAzLTA4VDE0OjMyOjAxLjg0N1oifQ=="
}

Use the cursor parameter in subsequent requests to paginate through large result sets. The cursor is opaque — do not parse or construct it manually.

Query parameters:

Parameter	Type	Description
start	string	ISO 8601 timestamp — start of the time range (inclusive)
end	string	ISO 8601 timestamp — end of the time range (inclusive)
limit	integer	Maximum entries per page. Default: 100. Maximum: 1000.
cursor	string	Pagination cursor from a previous response
outcome	string	Filter by outcome value: ALLOW, BLOCK, CANCEL, REDACT, ROUTE_TO
user_id	string	Filter by user identifier

SIEM integration

Arbitex streams audit events to external SIEM platforms using the Open Cybersecurity Schema Framework (OCSF) format and a connector framework. Events are forwarded in near-real-time, typically within seconds of the originating request.

OCSF event format

OCSF is an open standard that provides a normalized event schema compatible with major SIEM platforms. Arbitex audit events are mapped to OCSF event classes:

Event type	OCSF class	Class ID
DLP findings	Security Finding	2001
Authentication events	Authentication	3002
Configuration changes	Configuration State	5002
Compliance bundle activations	Compliance	5004

Each event includes the OCSF metadata envelope (version, product, vendor, event time) alongside the Arbitex-specific fields. The full Arbitex OCSF field mapping is available in the API reference.

Supported connectors

Platform	Connector mechanism
Splunk	HTTP Event Collector (HEC)
Microsoft Sentinel	Log Analytics API
IBM QRadar	Log Source API
Elastic Security	Elasticsearch ingest API
Sumo Logic	HTTP Source
Datadog	Logs API

Configuring a SIEM connector

SIEM integration is configured at the organization level through the admin API:

POST /api/admin/orgs/{org_id}/siem/connectors
Content-Type: application/json

{
  "platform": "splunk",
  "endpoint": "https://your-splunk-instance.example.com:8088/services/collector",
  "auth": {
    "type": "hec_token",
    "token": "your-hec-token"
  },
  "format": "ocsf",
  "enabled": true
}

{
  "connector_id": "con_splunk_01",
  "platform": "splunk",
  "status": "active",
  "created_at": "2026-03-08T14:00:00Z"
}

You can configure one connector per SIEM platform per organization. Multiple platforms may be active simultaneously — for example, streaming to both Splunk and Sentinel concurrently.

See also

• DLP Overview — how the 3-tier DLP pipeline produces the findings recorded in audit entries
• Credential Intelligence — details on the six CredInt fields in audit entries
• Policy Engine overview — how policy evaluation fields are generated
• Compliance Bundles — how compliance bundle rule matches are attributed in audit entries