Compliance Aiops
Compliance evidence from AIops audit trails: HIPAA/PCI/SOC2/GDPR, OSCAL export, 19 tools.
- Transport
- Not stated
- Package
- —
- Registry id
- io.github.AIops-tools/compliance-aiops
No install snippet on purpose. A working MCP config is a command, its arguments and an environment block — the last two are where API keys live, so this catalogue never stores them and cannot publish them. Follow the link above for the authors' own instructions.
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
~/.<tool>-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.dbfiles 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
strongorpartial.gap_analysissays 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). ThechainHeadis reproducible for the same (framework, period, sources).verify_bundlecatches tampering;verify_source_chaindetects 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 reproduciblechainHeadis 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)
From the project's README.