Audit & compliance
Kilasec keeps two separate records, on purpose, because auditors and incident responders ask two different questions.
Where you do this: Cloud dashboard — kilasec.com/app/ → Live Traffic (decisions), Audit Log (config changes), Settings → Event retention (retention window). Requires the tenant_admin role. On the collector host you can also read the full-fidelity local tail at
/var/lib/kilasec/audit.log.jsonl— see the note under Live Traffic.
| Record | Answers | Where in the dashboard |
|---|---|---|
| Live Traffic | "What did agents try to do, and what did we decide?" | Live Traffic |
| Audit Log | "What did administrators change?" | Audit Log |
Conflating them is a common mistake — every serious framework (SOC 2, and every SIEM) treats decision history and configuration-change history as distinct.
Live Traffic — decision history
Dashboard → Live Traffic. Every policy decision on the wire: timestamp, verdict, agent, source IP, destination, matched rule, and reason. It's the forensic record of what your AI traffic did. Filter by agent, verdict, matched rule, free-text, or since-date; export to CSV for an investigation.
Note: raw request bodies are not stored in the cloud. The collector applies redaction and sanitization before anything is uplinked — the cloud sees the decision and metadata, not the prompt content (unless you explicitly opt into shipping content). Request bodies are not persisted on the collector either: the collector keeps the last 500 decisions in memory, with bodies, readable on the collector host via GET http://127.0.0.1:8000/audit (or /audit/export) with the collector token as a bearer (Authorization: Bearer $AGENTFW_CLOUD_TOKEN from /etc/kilasec/collector.env). The on-disk /var/lib/kilasec/audit.log.jsonl records approval-hold decisions only — metadata, never bodies.
Audit Log — configuration changes
Dashboard → Audit Log. Every administrative mutation: who edited which rule, who approved or rejected which collector, who changed retention, who enabled or reset 2FA. Each row carries the actor, timestamp, action, target, a human summary, and (where relevant) a before/after diff. This is your change-management and accountability record.
Retention
Dashboard → Settings → Event retention. Common targets:
| Days | Rationale |
|---|---|
| 30 | small shops |
| 90 | recommended baseline |
| 365 | SOC 2 minimum |
| 2190 | HIPAA minimum (6 years) |
| 0 | keep forever |
Events past the window are purged automatically; reducing retention purges older rows immediately. Retention controls the long-term store — the Live Traffic view always shows only the last few hours regardless.
Exporting
- CSV — Dashboard → Live Traffic or Audit Log → Export CSV for the current filter/window; hand it to an auditor or drop it in a ticket.
- SIEM — configured on the collector host or via cloud webhook; see Export audit log to SIEM for forwarding decisions to Splunk / Datadog / a generic HEC.
Scheduled security digest
Settings → Security digest. A formatted executive summary — headline catches, trend against the prior period, top secret types and blocked destinations, and lifetime ROI — mailed on a schedule you pick and/or posted to Slack.
- Subscribe and choose daily, weekly (pick the weekday) or monthly (pick a day, 1–28 so no month is ever skipped). The send hour is UTC, stated as such in the UI.
- Recipients are a comma-separated email list, a Slack incoming webhook, or both. A subscription with neither is refused rather than silently going nowhere.
- Window — the reporting period the digest covers (7 or 30 days), independent of how often it sends.
- Send now delivers the same email immediately, for a test or an ad-hoc report.
Scheduling is slot-based: each period has one send, so a cloud restart can't double-send, and a missed window still goes out on the next tick instead of sliding the schedule forward. Changing recipients mid-period neither re-sends nor skips that period.
Backups
Your audit history lives in the cloud database. On the Kilasec-hosted cloud, nightly snapshots are taken automatically. If you self-host, ensure a DB backup is in place — see Sizing & failure modes.