Audit logs: what is captured, how to query, how to export to your SIEM - Apragya Docs

Apragya AI is audit-first by design: every state-changing action across the platform writes an audit_logs row before it commits. Who did what, when, with what before/after state. The audit log is the single source of truth for security reviews, compliance audits, and the inevitable "what happened to this record?" investigation.

What gets logged

Every mutating action - create / update / delete on any record across every Enterprise App
Auth events - login, logout, session refresh, failed login, password reset, SSO group changes
Admin actions - role grants, RBAC matrix edits, plan changes, SSO config updates
Agent runs - agent invocations and HITL approvals/rejections
Each row carries: actor (who), action (what), resource (which record), before/after values, timestamp, and originating IP address - everything an auditor asks for

Searching the audit log

Sidebar > Admin > Audit > Search. Filter by actor email, resource type, action, or date range. Export the filtered view as CSV for compliance packets, or push events continuously into your SIEM (see below).

Retention

Default retention is 7 years - the standard SOX-compatible window. Configurable down to 1 year (some tenants prefer the smaller footprint) or up to 10 years (regulated industries). After retention expires, the platform archives the rows to cold storage (S3 Glacier) and surfaces them on demand via a separate query path.

Export to SIEM

Splunk - native HEC (HTTP Event Collector) endpoint; the platform pushes events in real-time
Datadog - Logs API push every 60 seconds in batches of 1000
S3 / GCS - hourly Parquet files for cold-storage analytics + Athena/BigQuery queries
Syslog - the legacy fallback for tenants whose SIEM doesn't have a native API

Configure under Admin Settings > Audit > SIEM Exports. The audit.export.ready webhook fires when a scheduled S3/GCS batch finishes - useful for downstream pipelines that wait for each hour's batch.

Read events are NOT logged by default - audit_logs would explode in volume. To capture reads (for highly regulated tenants), enable per-resource read auditing in Admin Settings > Audit > Read Auditing. Adds ~20% to audit_logs volume on a typical tenant; tune what's enabled.

What you cannot disable

Some categories of audit cannot be turned off, even by SaaS Admin - role grants, plan changes, SSO config edits, audit-config changes, API key issuance/revocation. The platform refuses to operate without these. Useful for SOC 2 / ISO 27001 review - the assurance that a privileged user couldn't have covered their tracks.