Compliance-AIops

Purpose

Compliance-AIops is aimed at compliance evidence generation for AI agent infrastructure operations. It reads the local audit trails already written by governed AIops agents—the SQLite databases located at ~/.<tool>-aiops/audit.db , which share the same audit_log schema—and converts this activity into framework-mapped, hash-chain-sealed compliance evidence bundles. It does not scan infrastructure, nor does it replace a GRC platform; instead, it turns the audit trails you have already produced into auditor-usable, tamper-evident evidence bundles.

Unlike other tools in the AIops-tools family, it is not a platform wrapper: no external APIs, no network, no platform credentials. Its only input is those audit databases on disk, opened read-only. This also makes it the easiest tool in the family to self-test—fully offline and deterministic.

Main capabilities

• Framework mapping, with honest labeling of evidence strength: Audit events can be mapped to HIPAA §164.312, PCI-DSS v4.0, SOC 2 TSC, and GDPR controls. Audit trails can strongly demonstrate the operational effectiveness of controls, but provide only partial evidence for control design/configuration; each control is labeled as strong or partial.gap_analysis explains this control by control, with caveats and remediation hints.
• Hash-chain-sealed evidence bundles: SHA-256 over sorted records (hash = SHA-256(prev_hash ‖ canonical_json(record)), genesis prev_hash is 64 zeros). For the same (framework, period, source),chainHead is reproducible.verify_bundle can detect tampering;verify_source_chain can detect row ID gaps/deletions in the source trail. Optional HMAC signing seals the evidence bundle with a stored signing key.
• Zero network, read-only: no credentials, no outbound calls, no modification of source trails. The only thing written is the evidence bundle under ~/.compliance-aiops/bundles/ .
• Deterministic, integrity verified by tests: The integrity claims themselves are covered by tests: synthetic audit databases are built through the real governance-harness AuditEngine , golden reproducible chainHeadis asserted, and tamper tests confirm detection works. No live infrastructure is required.
• Full operational audit: Every invocation (whether via MCP or CLI) leaves an audit row in ~/.compliance-aiops/audit.db . Each tool declares risk_level, kept consistent by tests with the [READ]/[WRITE] label in the documentation, and written to the audit row as a descriptive tier for reviewers to see. This is a label, not a gate.

Tool interface

Provides 16 MCP tools, of which 13 are read/analysis tools and 3 are write/artifact tools (no external changes). The CLI exposes a convenience subset; the full 19-tool surface is available through MCP.

Usage

As a Claude Code plugin

One installation provides both the skill and the MCP server. The MCP server is obtained via uv and pinned to the package version declared by the plugin, so audit rows can be traced back to the code that wrote them. Credentials still need to be configured via compliance-aiops init .

As an OpenClaw plugin

The same evidence bundle is published on ClawHub, and one installation delivers both the skill and its MCP server. After installation, the OpenClaw gateway must be restarted to load the plugin. The MCP server is obtained via uv and pinned to that exact version, so uvx must be on PATH —otherwise the skill will still install, but will report Visible to model: noCredentials are configured in the same way.

As a CLI or standalone MCP server

Can run as an MCP server (stdio).

Password storage location note: Exported environment variables can be read by every process started by that shell and will be recorded in the shell history. On shared or long-running hosts, prefer interactive prompts, or inject from a secret manager within the lifetime of a single command.

Scheduled sealing

Evidence packages are most valuable when sealed on a regular cadence (for example, weekly), so that each period has a tamper-evident anchor. This tool does not ship with a daemon; instead, bundle schedule prints a cron line that can be pasted directly, along with the exact non-interactive command, and writes nothing. It returns cronLine, which can be pasted into crontab -e .--period（bundle generate is also available) is a convenient relative window—7d、24h、2w or last-7-days—resolves to a since/until pair ending at "now", so each scheduled run seals the trailing window. Export COMPLIANCE_AIOPS_MASTER_PASSWORDin the cron job's environment so that the stored signing key can be unlocked non-interactively. Do not inline real passwords in the crontab file—reference them from a protected environment file.

Integrity, honest boundaries, and limitations

• Tamper-evident, not tamper-proof: The hash chain and optional signatures let auditors detect traces of modification; they cannot prevent modification. The source audit.db file remains the system of record—if an independent anchor is needed, record chainHeadout of band.
• Operating effectiveness vs. design: The audit trail can strongly demonstrate that a control ran (sampling, approvals, rejections), but it can provide only partial evidence as to whether the control is correctly designed/configured (for example, enforced MFA, least-privilege roles). Each control item carries a strong/partial label, andgap_analysis exposes that caveat rather than overclaiming.
• Scope and limitations: It produces evidence packages usable by auditors; it does not issue attestations, opinions, or certifications. In scope: the six frameworks above, based on the ~/.*-aiops/audit.db trails written by governed AIops tools discovered through audit_log . Out of scope: it does not scan infrastructure, connect to any platform, or replace a GRC platform. OSCAL export is a v0.2 roadmap item; v0.1 outputs JSON + Markdown + CSV. Interfaces may change before v1.0. Integrity claims are covered by deterministic offline tests; see docs/VERIFICATION.md for reproducible runs.

Community and license

A community-maintained open source project under the MIT license. It is not affiliated with, endorsed by, or sponsored by any framework body or GRC vendor. HIPAA, PCI-DSS, SOC 2, GDPR, and OSCAL are cited descriptively only, and the frameworks and trademarks belong to their owners. If you want to add other frameworks, control mappings, export formats, or verification methods to the tool, you can submit an issue or PR.