Audit Log Management

Arbitex Gateway records every request, policy decision, DLP finding, authentication event, and administrative action in a tamper-evident audit log. This guide covers how to view and filter logs, export records for compliance retention, verify the HMAC integrity chain, and connect your SIEM for real-time event streaming.

All audit log endpoints require the Org Admin role.

---

What gets logged

Every audit log entry captures:

Field	Description
request_id	Unique identifier for this log entry
timestamp	ISO 8601 UTC timestamp
action	Event type (see Action types)
user_id	UUID of the user who triggered the event
model	Model identifier (e.g., claude-sonnet-4-20250514)
provider	Provider name (e.g., anthropic)
outcome	Policy engine decision: ALLOW, BLOCK, REDACT, REQUIRE_APPROVAL
dlp_findings	Array of DLP detections (type, tier, confidence, location)
policy_rules_matched	Names of policy rules that matched
credint_hit	Whether a credential matched the breach corpus
routing_mode	How the request was routed (Single, Fallback, Balanced)
prompt_tokens	Input token count
completion_tokens	Output token count
latency_ms	End-to-end gateway latency
hmac	HMAC-SHA256 signature of this entry
previous_hmac	Signature of the preceding entry (chain link)

The hmac and previous_hmac fields form an unbroken chain. Any tampering, deletion, or reordering of entries is detectable by walking the chain.

Action types

Action	Trigger
chat_completion	Normal model request
dlp_block	Request blocked by DLP finding
dlp_redact	Request content was redacted
policy_block	Request blocked by policy rule
policy_approval_requested	Request held for human review
policy_approval_approved	Human reviewer approved a held request
policy_approval_denied	Human reviewer denied a held request
auth_success	Successful API key authentication
auth_failure	Failed authentication attempt
admin_login	Admin portal sign-in
key_created	API key created
key_rotated	API key rotated
key_deleted	API key deleted
rule_created	DLP or policy rule created
rule_updated	DLP or policy rule updated
rule_deleted	DLP or policy rule deleted
siem_config_created	SIEM connector configured
provider_created	Provider credential added

---

Viewing and filtering logs

Search endpoint

GET /api/v1/admin/audit-logs/
Authorization: Bearer arb_live_your-api-key-here

All filter parameters are optional and ANDed together:

Parameter	Type	Description
limit	integer (1–500, default 50)	Results per page
offset	integer (default 0)	Pagination offset
action	string	Exact action type (e.g., dlp_block)
user_id	string (UUID)	Filter by user
model_id	string	Filter by model (e.g., claude-sonnet-4-6)
provider	string	Filter by provider (e.g., anthropic)
created_after	ISO 8601	Lower bound on created_at (inclusive)
created_before	ISO 8601	Upper bound on created_at (inclusive)
search	string	Substring search on prompt and response text
outcome	string	Filter by policy outcome (ALLOW, BLOCK, REDACT)

List recent entries

curl "https://gateway.arbitex.ai/api/v1/admin/audit-logs/?limit=20" \
  -H "Authorization: Bearer $ARBITEX_API_KEY"

{
  "entries": [
    {
      "request_id": "req_01HZ8X9K2P3QR4ST5UV6WX7YZ",
      "timestamp": "2026-03-12T14:32:01.847Z",
      "action": "chat_completion",
      "user_id": "usr_alice_johnson",
      "model": "claude-sonnet-4-20250514",
      "provider": "anthropic",
      "outcome": "ALLOW",
      "dlp_findings": [],
      "policy_rules_matched": [],
      "credint_hit": false,
      "routing_mode": "Single",
      "prompt_tokens": 28,
      "completion_tokens": 42,
      "latency_ms": 387
    }
  ],
  "total": 14823,
  "limit": 20,
  "offset": 0
}

Filter by blocked requests in a date range

curl "https://gateway.arbitex.ai/api/v1/admin/audit-logs/?outcome=BLOCK&created_after=2026-03-01T00:00:00Z&created_before=2026-03-11T23:59:59Z&limit=100" \
  -H "Authorization: Bearer $ARBITEX_API_KEY"

Find all DLP events for a user

curl "https://gateway.arbitex.ai/api/v1/admin/audit-logs/?action=dlp_block&user_id=usr_alice_johnson&limit=50" \
  -H "Authorization: Bearer $ARBITEX_API_KEY"

Look up a specific request

Use the X-Arbitex-Request-Id response header from any gateway call to find the exact audit entry:

REQUEST_ID="req_01HZ8X9K2P3QR4ST5UV6WX7YZ"
curl "https://gateway.arbitex.ai/api/v1/admin/audit-logs/?request_id=$REQUEST_ID" \
  -H "Authorization: Bearer $ARBITEX_API_KEY"

---

Exporting logs

Export a signed package

Use the export endpoint to download a signed audit log archive for compliance retention, offline analysis, or handoff to regulators:

curl -X POST "https://gateway.arbitex.ai/api/v1/admin/audit-logs/export" \
  -H "Authorization: Bearer $ARBITEX_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "created_after": "2026-03-01T00:00:00Z",
    "created_before": "2026-03-11T23:59:59Z",
    "format": "jsonl"
  }'

{
  "export_id": "exp_01HZ...",
  "status": "processing",
  "record_count": null,
  "download_url": null,
  "expires_at": null
}

Export jobs are asynchronous. Poll for completion:

EXPORT_ID="exp_01HZ..."
curl "https://gateway.arbitex.ai/api/v1/admin/audit-logs/export/$EXPORT_ID" \
  -H "Authorization: Bearer $ARBITEX_API_KEY"

{
  "export_id": "exp_01HZ...",
  "status": "complete",
  "record_count": 4823,
  "format": "jsonl",
  "download_url": "https://exports.arbitex.ai/signed/exp_01HZ....jsonl?token=...",
  "signature": "sha256=a3f2c1...",
  "expires_at": "2026-03-14T14:00:00Z"
}

The download_url is a pre-signed URL valid for 48 hours. The signature is an HMAC-SHA256 over the export file contents — verify it before ingesting the data.

Streaming export for large date ranges

For very large exports (millions of entries), use streaming export with chunked transfer:

curl -X POST "https://gateway.arbitex.ai/api/v1/admin/audit-logs/export/stream" \
  -H "Authorization: Bearer $ARBITEX_API_KEY" \
  -H "Content-Type: application/json" \
  --no-buffer \
  -d '{
    "created_after": "2026-01-01T00:00:00Z",
    "created_before": "2026-03-31T23:59:59Z",
    "format": "jsonl"
  }' \
  > audit-q1-2026.jsonl

Streaming exports write one JSON object per line as records are read from the database. No intermediate storage is required on the server side.

Export formats

Format	Description	Best for
jsonl	One JSON object per line	Log pipelines, SIEM ingestion, programmatic processing
csv	Comma-separated, headers on first row	Spreadsheet analysis, reporting
ndjson	Identical to jsonl	Compatibility alias

---

Verifying HMAC chain integrity

Every audit entry contains an hmac field (HMAC-SHA256 over the entry’s data) and a previous_hmac field (the hmac of the preceding entry). This forms a linked chain — deleting, modifying, or reordering any entry breaks the chain.

Verify via API

Trigger a full chain verification on demand:

curl -X POST "https://gateway.arbitex.ai/api/v1/admin/audit-logs/verify" \
  -H "Authorization: Bearer $ARBITEX_API_KEY"

{
  "valid": true,
  "entries_checked": 14823,
  "errors": []
}

If tampering is detected:

{
  "valid": false,
  "entries_checked": 14823,
  "errors": [
    {
      "entry_id": "req_01HZ...",
      "position": 4201,
      "error": "HMAC mismatch: computed a3f2c1... expected b7e9d4..."
    }
  ]
}

The position field identifies which entry in the chain is broken. Check errors for the exact entry IDs and error descriptions.

Verify an exported package

To verify the integrity of an export file before ingesting it:

import hashlib
import hmac
import json

HMAC_KEY = b"your-audit-hmac-key"

def verify_export(filepath: str) -> bool:
    with open(filepath) as f:
        entries = [json.loads(line) for line in f]

    previous_hmac = None
    for i, entry in enumerate(entries):
        # Reconstruct the HMAC (exclude hmac and previous_hmac fields)
        data = {k: v for k, v in entry.items() if k not in ("hmac", "previous_hmac")}
        if previous_hmac is not None:
            data["previous_hmac"] = previous_hmac

        expected = hmac.new(
            HMAC_KEY,
            json.dumps(data, sort_keys=True).encode(),
            hashlib.sha256,
        ).hexdigest()

        if entry["hmac"] != expected:
            print(f"Chain broken at entry {i}: {entry['request_id']}")
            return False

        previous_hmac = entry["hmac"]

    print(f"Chain verified: {len(entries)} entries intact")
    return True

verify_export("audit-q1-2026.jsonl")

The AUDIT_HMAC_KEY is configured by your platform admin in the gateway environment variables. Contact your admin if you need the verification key.

---

SIEM integration

Connect a SIEM to receive audit events in real time via push connector. Events are forwarded as they are generated — no polling required.

Supported SIEM connectors

Connector	connector_type value
Splunk HTTP Event Collector	splunk_hec
Microsoft Sentinel (Log Analytics)	sentinel
Elastic (Elasticsearch / ESQL)	elastic
Datadog Log Management	datadog
Sumo Logic	sumo_logic
Palo Alto Cortex XSIAM	cortex_xsiam
IBM QRadar	qradar

Splunk HEC setup

1. In Splunk: Create an HTTP Event Collector token under Settings > Data Inputs > HTTP Event Collector. Note the HEC endpoint URL and token.

2. In Arbitex: Create the SIEM connector config:

curl -X POST "https://gateway.arbitex.ai/v1/org/siem-configs" \
  -H "Authorization: Bearer $ARBITEX_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "connector_type": "splunk_hec",
    "name": "Splunk Production",
    "config": {
      "hec_url": "https://splunk.example.com:8088/services/collector/event",
      "token": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
      "index": "arbitex_audit",
      "source": "arbitex_gateway",
      "sourcetype": "arbitex:audit"
    },
    "enabled": true
  }'

3. Test the connection:

SIEM_CONFIG_ID="siem_01HZ..."
curl -X POST "https://gateway.arbitex.ai/v1/org/siem-configs/$SIEM_CONFIG_ID/test" \
  -H "Authorization: Bearer $ARBITEX_API_KEY"

{
  "success": true,
  "latency_ms": 42,
  "message": "Test event delivered successfully"
}

Microsoft Sentinel setup

1. In Azure: Navigate to your Log Analytics workspace. Under Agents management, note the Workspace ID and Primary Key.

2. In Arbitex:

curl -X POST "https://gateway.arbitex.ai/v1/org/siem-configs" \
  -H "Authorization: Bearer $ARBITEX_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "connector_type": "sentinel",
    "name": "Azure Sentinel Production",
    "config": {
      "workspace_id": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
      "primary_key": "base64encodedprimarykey==",
      "log_type": "ArbitexAuditLog"
    },
    "enabled": true
  }'

Arbitex uses the Log Analytics Data Collector API to POST events. Events appear in Sentinel under the ArbitexAuditLog_CL custom log table within 5–10 minutes.

3. Sentinel KQL query to find blocked requests:

ArbitexAuditLog_CL
| where outcome_s == "BLOCK"
| where TimeGenerated > ago(24h)
| project TimeGenerated, user_id_s, action_s, dlp_findings_s, policy_rules_matched_s
| order by TimeGenerated desc

Elastic setup

1. In Elasticsearch: Create an API key with index permissions on the target index pattern (arbitex-*):

curl -X POST "https://elastic.example.com:9200/_security/api_key" \
  -H "Content-Type: application/json" \
  -u elastic:password \
  -d '{
    "name": "arbitex-ingest",
    "role_descriptors": {
      "arbitex-writer": {
        "cluster": ["monitor"],
        "indices": [{"names": ["arbitex-*"], "privileges": ["create_index", "index", "create"]}]
      }
    }
  }'

2. In Arbitex:

curl -X POST "https://gateway.arbitex.ai/v1/org/siem-configs" \
  -H "Authorization: Bearer $ARBITEX_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "connector_type": "elastic",
    "name": "Elastic Production",
    "config": {
      "url": "https://elastic.example.com:9200",
      "api_key": "base64encodedapikey==",
      "index": "arbitex-audit"
    },
    "enabled": true
  }'

Events are indexed as documents in arbitex-audit-{YYYY.MM.DD} using daily index rotation.

Viewing connector health

curl "https://gateway.arbitex.ai/v1/org/siem-configs" \
  -H "Authorization: Bearer $ARBITEX_API_KEY"

{
  "configs": [
    {
      "id": "siem_01HZ...",
      "connector_type": "splunk_hec",
      "name": "Splunk Production",
      "enabled": true,
      "last_delivery_at": "2026-03-12T14:35:00Z",
      "last_delivery_status": "success",
      "error_count_24h": 0
    }
  ]
}

last_delivery_status shows the outcome of the most recent event delivery. error_count_24h shows delivery failures in the past 24 hours. If this is non-zero, check the connector configuration and test the connection.

For platform-level connector health across all organizations, see SIEM Admin API.

---

Compliance use cases

SOC 2 — Access and change management evidence

Export all admin_login, key_created, key_rotated, rule_created, and rule_updated events for a period and retain them for 12 months:

curl -X POST "https://gateway.arbitex.ai/api/v1/admin/audit-logs/export" \
  -H "Authorization: Bearer $ARBITEX_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "action_types": ["admin_login", "key_created", "key_rotated", "rule_created", "rule_updated"],
    "created_after": "2026-01-01T00:00:00Z",
    "created_before": "2026-12-31T23:59:59Z",
    "format": "jsonl"
  }'

HIPAA — Access log for PHI-adjacent requests

Filter for requests that triggered NER findings of type MEDICAL_RECORD or NPI:

curl "https://gateway.arbitex.ai/api/v1/admin/audit-logs/?dlp_finding_type=MEDICAL_RECORD,NPI&limit=500" \
  -H "Authorization: Bearer $ARBITEX_API_KEY"

PCI-DSS — Cardholder data access

Filter for CREDIT_CARD findings and export quarterly:

curl -X POST "https://gateway.arbitex.ai/api/v1/admin/audit-logs/export" \
  -H "Authorization: Bearer $ARBITEX_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "dlp_finding_types": ["CREDIT_CARD"],
    "created_after": "2026-01-01T00:00:00Z",
    "created_before": "2026-03-31T23:59:59Z",
    "format": "jsonl"
  }'

---

Reference

Resource	Link
Audit Event API (search, filter, pagination)	Audit Event API
Audit Log Export (signed packages, streaming)	Audit Log Export
SIEM Admin API (connector registry)	SIEM Admin API
SIEM Integration Guide	SIEM Integration Guide
Data Retention configuration	Data Retention
Alert configuration	Alert Configuration

---

Complete audit entry field reference

Each audit log entry contains the following fields grouped by category.

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 5-tier DLP pipeline. Each finding includes: entity_type, tier (0–4), 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

GeoIP fields are derived from src_ip at write time using the MaxMind GeoIP2 database. They are not included in the HMAC chain because they are dataset-version-dependent.

Field	Type	Description
src_ip	string	Client IP address, from X-Forwarded-For or direct connection
src_country_code	string	ISO 3166-1 alpha-2 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

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	HMAC-SHA256 digest for this entry — used for tamper-evidence verification
previous_hmac	string	HMAC of the preceding audit entry — the chain link
hmac_key_id	string	Identifier of the HMAC key used to compute hmac; used to select the correct key after key rotation

---

HMAC chain construction detail

Genesis sentinel

The first entry in the chain has no predecessor. In place of a real previous_hmac, it carries the genesis sentinel: 64 consecutive zero characters.

0000000000000000000000000000000000000000000000000000000000000000

This value is a fixed constant. Its presence confirms that an entry is the chronological first in the chain.

HMAC message formula

The HMAC is computed over a canonical message string assembled as:

key_id + ":" + json.dumps(content, sort_keys=True, default=str) + previous_hmac

Where content is the entry’s field dictionary with hmac, previous_hmac, and hmac_key_id excluded. The fields included in content for HMAC computation are:

Field
timestamp
user_id
action
conversation_id
model_id
provider
prompt_text
response_text
token_count_input
token_count_output
cost_estimate
latency_ms
metadata
tenant_id
ip_address

GeoIP enrichment fields and CredInt enrichment fields are excluded from HMAC computation because they are derived, not observed facts. This means that upgrading your GeoIP database does not invalidate existing HMAC chains.

The chain is ordered by created_at ASC. Verification must process entries in this order to correctly thread previous_hmac values through the sequence.

Tamper evidence — what violations look like

The verification engine identifies four categories of integrity violation:

Modified entry — an entry’s content was changed after it was written:

Hash mismatch on entry id=ae4f2c1b at 2026-03-07T11:42:08Z: stored hmac does not match recomputed value

Deleted entry — an entry was removed from the chain:

Chain gap on entry id=9d3e7a22 at 2026-03-07T11:42:09Z: previous_hmac does not match hmac of preceding entry

Reordered entries — entries were moved to a different position:

Chain gap on entry id=7b1c4d09 at 2026-03-07T11:42:11Z: previous_hmac does not match hmac of preceding entry

Injected entries — an entry was inserted into the middle of the chain:

Chain gap on entry id=2f8a6b44 at 2026-03-07T11:42:10Z: previous_hmac does not match hmac of preceding entry

An injected entry cannot carry a valid HMAC because the attacker would need the HMAC secret to recompute a consistent chain from the injection point forward.

A single tampering event typically produces one error at the modified or deleted entry and cascading errors on every subsequent entry in the chain.

Key rotation: After rotating AUDIT_HMAC_KEY, entries written before the rotation carry the old hmac_key_id. The verification engine uses hmac_key_id to select the correct key for each entry. Historical keys must remain available to the server for verification to succeed across rotation boundaries.

---

Portal export

The Cloud Portal provides a simplified export endpoint for ad-hoc analysis (distinct from the compliance export API):

GET /v1/orgs/{org_id}/audit/export
Authorization: Bearer <org_jwt>

Parameter	Type	Default	Description
format	string	json	Output format: csv or json
action	string	—	Filter by exact action type
user_id	string (UUID)	—	Filter by user UUID
start_time	string (ISO 8601)	—	Lower bound on event timestamp
end_time	string (ISO 8601)	—	Upper bound on event timestamp
severity	string	—	Filter by severity: low, medium, high, critical
limit	integer (1–10000)	10000	Maximum events to export

Maximum 10,000 events per export. For larger exports, use the compliance export API (POST /api/v1/admin/audit/export).

CSV columns: event_id, timestamp, action, user_id, severity, resource_type, resource_id, ip_address.

---

Compliance export — signed package and HMAC verification

The compliance export API produces a signed JSON package with hmac_chain_status metadata:

Status	Meaning
intact	All record HMACs are valid and the chain is unbroken
broken	One or more records have invalid HMACs — possible tampering
disabled	AUDIT_HMAC_KEY is not configured; records lack HMACs

Verify the export signature (Python):

import hashlib, hmac, json

def verify_export(export_path: str, audit_hmac_key: str) -> bool:
    with open(export_path) as f:
        export = json.load(f)
    records_json = json.dumps(export["records"], sort_keys=True, default=str)
    computed = hmac.new(
        audit_hmac_key.encode("utf-8"),
        records_json.encode("utf-8"),
        hashlib.sha256,
    ).hexdigest()
    match = hmac.compare_digest(computed, export["signature"])
    print(f"{'Verified' if match else 'MISMATCH'}: {len(export['records'])} records")
    return match

Constraints: Maximum 90-day window per export request. Exports exceeding 10,000 records stream as chunked JSON.

---

Audit log retention

Tier	Retention	Access
Hot	90 days	Full query, filter, and export
Archive	2 years	Compliance export API only

For retention beyond 90 days, configure SIEM integration to stream events in real time. For long-term archival, use an append-only or immutable storage backend (AWS S3 Object Lock, Azure Blob immutable storage, GCS bucket lock).

---

Automated export scheduling

Monthly curl script

#!/bin/bash
YEAR=$(date -d "last month" +%Y)
MONTH=$(date -d "last month" +%m)
START_DATE="$YEAR-$MONTH-01"
END_DATE=$(date -d "$START_DATE +1 month -1 day" +%Y-%m-%d)
curl -s -X POST https://api.arbitex.ai/api/v1/admin/audit/export \
  -H "Authorization: Bearer $ARBITEX_ADMIN_KEY" \
  -H "Content-Type: application/json" \
  -d "{\"start_date\": \"$START_DATE\", \"end_date\": \"$END_DATE\"}" \
  --output "audit-export-$YEAR-$MONTH.json"

Cron schedule

# Run on the 1st of each month at 02:00 UTC
0 2 1 * * /opt/arbitex/scripts/monthly-audit-export.sh >> /var/log/arbitex/audit-export.log 2>&1

---

Compliance evidence filters

HIPAA — access control evidence

Filter	Evidence for
action=login	User access log — who accessed the system and when
action=logout	Session termination
action=mfa_verify	Multi-factor authentication usage
action=dlp_block	PHI protection — blocked attempts to exfiltrate PHI
action=dlp_redact	PHI protection — redacted PHI in transit

PCI-DSS 10.2 — cardholder data access

Filter	PCI-DSS Requirement
action=api_key_created	10.2.1 — individual access to cardholder data
action=api_key_deleted	10.2.1 — individual access to cardholder data
action=dlp_block	10.2.4 — invalid logical access attempts
action=config_changed	10.2.2 — actions by admin users
action=user_role_changed	10.2.5.c — changes to accounts/permissions

SOC 2 CC7.2 — anomaly detection

Indicator	How to find it
Volume spike (3× baseline)	Compare daily event counts across export periods
Off-hours activity	Filter events by timestamp outside business hours
Multiple failed logins	Filter action=login_failed
Credential intelligence hits	Filter action=credint_hit (severity: critical)

---

Enriched fields in search results

GeoIP enrichment

GeoIP fields are populated at write time from the MaxMind GeoIP2 database and are excluded from the HMAC chain:

Field	Description
src_country_code	ISO 3166-1 alpha-2 country code
src_country_name	Full country name
src_region	State or province
src_city	City name
src_isp	Internet service provider
src_asn	Autonomous System Number
src_asn_org	AS organization name
src_arin_org	ARIN Bulk Whois organization name

Credential Intelligence (CredInt) enrichment

CredInt fields are populated when a corpus match is detected:

Field	Description
credint_enabled	Whether CredInt was active for this org at request time
credint_hit	true if a breach corpus match was detected
frequency_bucket	Hit severity tier: critical, high, medium, or low
context_type	L1 extractor context type for the matched token
sha1_prefix	First 8 hex characters of SHA-1 digest of the matched token — never the full hash
credint_confidence	L3 NLI confidence score for the hit, in [0.0, 1.0]

The HMAC chain fields (hmac, previous_hmac, hmac_key_id) are excluded from search API responses. Use the dedicated verify endpoint or compliance export API to access them.

---

Outpost sync entries

Audit entries with source="outpost" were forwarded from a Hybrid Outpost deployment via the audit sync endpoint. These entries carry an outpost_id field identifying the originating Outpost. They are included in normal search results and filtered the same way as platform-generated entries.

---

OCSF event format for SIEM

Arbitex audit events map to Open Cybersecurity Schema Framework (OCSF) event classes for compatibility with major SIEM platforms:

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 Arbitex-specific fields. Configure SIEM connectors via:

POST /api/v1/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
}

One connector per SIEM platform per organization is supported. Multiple platforms may be active simultaneously.