AIops-tools/Compliance-AIops

> **Disclaimer**: Community-maintained open-source project. **Not affiliated with, endorsed by, or sponsored by any framework body or GRC vendor.** HIPAA, PCI-DSS, SOC 2, GDPR and OSCAL are referenced descriptively; the frameworks and trademarks belong to their owners. MIT licensed.
Governed **compliance-evidence** tooling for AI-agent infrastructure ops. It
**reads the audit trails your governed AIops agents already write** — the local
~/. -aiops/audit.db SQLite trails, all sharing one audit_log schema —
and turns that activity into **framework-mapped, hash-chain-sealed compliance
evidence**. It **never scans your infrastructure and never replaces a GRC
platform**: it converts the trails you already produce into auditor-ready,
tamper-evident evidence bundles.
Unlike the other tools in the AIops-tools line it is **not a platform wrapper**:
**no external API, no network, no platform credentials**. Its only inputs are
those on-disk audit databases, read **read-only**. That also makes it the
easiest-to-self-test tool in the line — fully offline and deterministic.
> **Evidence, not certification.** Fully offline; the source audit.db
> files remain the system of record. OSCAL export is a documented v0.2 roadmap
> item (v0.1 emits JSON + Markdown + CSV shaped to ease a future OSCAL
> Assessment-Results adapter).
Key features
- **Framework mapping with honest evidence-strength** — audit events map to
**HIPAA §164.312 / PCI-DSS v4.0 / SOC 2 TSC / GDPR** controls. Audit trails
prove *operating effectiveness* strongly but *control design / configuration*
only partially, and each control is labelled strong or partial.
gap_analysis says so per control, with the caveat and a remediation hint.
- **Hash-chain-sealed evidence bundles** — SHA-256 over ordered records
(hash = SHA-256(prev_hash ‖ canonical_json(record)), genesis prev = 64
zeros). The chainHead is **reproducible** for the same (framework, period,
sources). verify_bundle catches tampering; verify_source_chain detects
row-id gaps / deletions in a source trail. An optional HMAC signature seals a
bundle under a stored signing key.
- **Zero-network, read-only** — no credentials, no outbound calls, no mutation
of the source trails. Bundles are the only thing written, under
~/.compliance-aiops/bundles/.
- **Deterministic, test-verified integrity** — the integrity claims are
themselves covered by tests: synthetic audit DBs are built through the real
governance-harness AuditEngine, a golden reproducible chainHead is
asserted, and tamper tests confirm detection. No live infrastructure needed.
What this tool does, and does not, decide
It reads your audit trails and writes evidence bundles — and records every
operation. It does **not** decide whether producing or signing a bundle is
allowed: that is the agent's judgement, or the filesystem permissions of the
account it runs as. The source audit.db files are opened strictly read-only
regardless, and the only thing ever written is a bundle under
~/.compliance-aiops/bundles/.
So there is no read-only switch, no policy file, no approval gate to configure.
The one thing the tool guarantees is that nothing is silent: **every call, over
MCP and over the CLI alike, lands an audit row** in
~/.compliance-aiops/audit.db.
> Each tool declares a risk_level, kept in agreement with its [READ]/[WRITE]
> documentation tag by a test, and carried into the audit row as a descriptive
> tier — so a reviewer can see at a glance what a row was. It is a label, not a
> gate.
Tools (16 MCP tools)
Read / analysis (13)
| Tool | Purpose |
|------|---------|
| list_audit_sources | Discovered sibling audit DBs (path, tool, readable, row count) |
| query_audit_events | Cross-tool event query — filter by tool/skill/status/risk/approved/selector/since/until |