Compliance-aiops converts read-only AIops audit trails into framework-mapped, tamper-evident compliance evidence bundles with verification and export tooling.
Discover and read sibling ~/.<tool>-aiops/audit.db sources, then query cross-tool audit events with filters and timelines.
Map audit activity to HIPAA, PCI-DSS, SOC 2, GDPR, ISO 27001, and DJCP L3 controls, including coverage, control evidence, gap analysis, and strong/partial evidence strength.
Generate SHA-256 hash-chain-sealed evidence bundles, optionally add an HMAC signature, list bundles, and verify bundle or source-chain integrity.
Produce approval and exception reports for change-management, least-privilege, enforcement, and anomaly evidence.
Export bundles as Markdown, CSV, JSON, or OSCAL Assessment Results; render OSCAL documents inline.
Compose cron-based periodic sealing hints without writing files or starting a daemon.
List and apply recorded undo tokens, with dry-run preview support.
Reads local SQLite audit databases (audit.db) produced by sibling AIops tools as read-only compliance evidence sources. It discovers available audit trails, queries audit events, verifies source hash chains, and generates hash-chain-sealed evidence bundles for frameworks such as HIPAA, PCI-DSS, SOC 2, and GDPR.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@compliance-aiops Generate HIPAA evidence bundle for last week's audit events."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Audit availability: Real writes require a committed
pendingaudit row and stop before contacting the platform if storage is unavailable. Reads and previews may continue with a warning; new audit rows store outcome summaries rather than full responses.
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).
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.
Related MCP server: TrustAtom MCP Server
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.
Tool | Purpose |
| Discovered sibling audit DBs (path, tool, readable, row count) |
| Cross-tool event query — filter by tool/skill/status/risk/approved/selector/since/until |
| Event counts bucketed by hour or day |
| Supported frameworks + control counts |
| Per-control covered/weak/uncovered for ONE framework |
| Evidence rows + population + a reproducible query for ONE control |
| Controls with no/weak evidence + honest caveat + remediation |
| High-risk write ops + who approved + rationale (the CC8.1 / PCI 7-8 / HIPAA §312(a) artifact) |
| Denied / error / budget_exceeded ops — enforcement + anomaly evidence |
| Chain head + row-id gap detection for one source |
| Verify a sealed bundle: chain + seal head + optional signature |
| Bundles under |
| A sealed bundle as a NIST OSCAL 1.2.3 Assessment Results document, inline, with its limitations named |
| Ready-to-paste cron line + non-interactive command for periodic sealing (writes nothing) |
Tool | Risk | Purpose |
| low | One call: coverage + approval trail + exceptions + sealed records → a bundle |
| low | Render a bundle to markdown / csv / json / oscal |
| medium | HMAC over the seal using the stored signing key |
The CLI exposes a convenience subset; the full 19-tool surface is available over MCP.
Framework | Sample controls (strength) |
HIPAA (§164.312) | 164.312(b) Audit controls (strong), 164.312(a)(1) Access control (strong), 164.312(c)(1) Integrity (strong) |
PCI-DSS v4.0 | 10.2 Audit log content (strong), 10.3 Protect audit logs (strong), 7-8 Least privilege / authn (partial) |
SOC 2 TSC | CC6.1 Logical access (strong), CC7.2 Monitoring (strong), CC8.1 Change management (strong) |
GDPR | Art.30 Records of processing (partial), Art.32 Security of processing (strong) |
ISO/IEC 27001:2022 (Annex A) | A.5.15 Access control (strong), A.5.16 Identity mgmt (strong), A.5.18 Access rights (partial), A.8.2 Privileged access (partial), A.8.15 Logging (strong), A.8.16 Monitoring (strong), A.8.32 Change management (strong) |
等保2.0 (DJCP L3) (GB/T 22239-2019 三级) | 8.1.5.4 安全审计 (strong), 8.1.4.2 访问控制 (partial), 8.1.5 安全管理中心/集中审计 (strong) |
uv tool install compliance-aiops # or: pipx install compliance-aiopsOne install gives an agent both the skill and the MCP server:
/plugin marketplace add AIops-tools/marketplace
/plugin install compliance-aiops@aiops-toolsThe MCP server is fetched with uv and pinned to the
package version this plugin declares, so an audit row can be traced back to the
code that wrote it. Credentials are still configured with compliance-aiops init — see below.
The same bundle is published on ClawHub, where one install delivers the skill and its MCP server together:
openclaw plugins install clawhub:@zw008/compliance-aiops
openclaw skills info compliance-aiops # expect: Visible to model: yesRestart the OpenClaw gateway afterwards so it loads the plugin. The MCP server is
fetched with uv, pinned to this exact release, so
uvx has to be on PATH — without it the skill still installs but reports
Visible to model: no. Credentials are configured exactly as below.
compliance-aiops init # discover sibling ~/.*-aiops/audit.db, set org name, optional signing key
compliance-aiops doctor # which sibling audit DBs are present/readable
compliance-aiops overview # audit sources + per-framework covered/total
compliance-aiops report coverage soc2 # per-control SOC 2 coverage
compliance-aiops bundle generate soc2 # sealed evidence bundle → ~/.compliance-aiops/bundles/
compliance-aiops bundle verify <path> # re-verify the chain + seal (+ signature)Run as an MCP server (stdio):
export COMPLIANCE_AIOPS_MASTER_PASSWORD=... # only needed to unlock a signing key
compliance-aiops mcp # or: compliance-aiops-mcpWhere that password then lives: an exported variable is readable by every process this shell starts and is recorded by shell history. On a shared or long-lived host, prefer the interactive prompt, or inject it from a secret manager for the life of the one command that needs it.
Evidence bundles are most useful when sealed on a cadence (e.g. weekly), so
each period has a tamper-evident anchor. This tool ships no daemon — instead
bundle schedule prints a ready-to-paste cron line plus the exact non-interactive
command, and writes nothing:
compliance-aiops bundle schedule soc2 --cron "0 2 * * 1" --period 7d --signIt returns a cronLine you paste into crontab -e, for example:
0 2 * * 1 compliance-aiops bundle generate soc2 --period 7d --sign--period (also available on bundle generate) is a convenience relative
window — 7d, 24h, 2w, or last-7-days — resolved to a since/until pair
ending "now", so each scheduled run seals the trailing window.
Export COMPLIANCE_AIOPS_MASTER_PASSWORD in the cron job's environment so a
stored signing key unlocks non-interactively. Do not inline the real
password in the crontab file — reference it from a protected env file.
Tamper-EVIDENT, not tamper-PROOF. The hash chain and optional signature
let an auditor detect alteration; they do not prevent it. The source
audit.db files remain the system of record — record the chainHead
out-of-band if you need an independent anchor.
Operating effectiveness vs. design. An audit trail strongly evidences that
a control ran (samples, approvals, denials) but only partially evidences that
a control is designed / configured correctly (e.g. MFA required,
least-privilege roles). Every control carries a strong / partial label and
gap_analysis surfaces the caveat rather than overclaiming.
Evidence, not certification. This produces auditor-ready evidence bundles; it does not issue attestations, opinions, or certifications.
In scope: the six frameworks above, over the audit_log trails written by
governed AIops tools discovered via ~/.*-aiops/audit.db.
Not in scope: it does not scan infrastructure, connect to any platform, or replace a GRC platform. For platform operations use the other AIops-tools.
OSCAL export is v0.2. v0.1 emits JSON + Markdown + CSV.
Interfaces may change before v1.0.
Verification: the integrity claims are covered by deterministic offline tests;
see docs/VERIFICATION.md for the reproducible run.
Want another framework, control mapping, export format (OSCAL, CSV shape), or a verification you don't see here? Open an issue or a PR — contributions welcome.
[READ] Op counts bucketed by hour/day — monitoring-continuity evidence.
Args: since / until: ISO timestamps bounding the period. bucket: "hour" or "day".
Inputs: since, until, bucket.
[READ] High-risk write ops with approver + rationale (the change-approval trail).
The who/what/when/why/approval artifact for SOC 2 CC8.1, PCI 7-8, HIPAA §312(a).
Args: since / until: ISO timestamps bounding the period. high_only: True = only high/critical-risk writes (default); False = all writes.
Inputs: since, until, high_only.
[READ] Ready-to-paste cron line + command for periodic sealed-bundle generation.
WRITES NOTHING and starts no daemon — it only composes and validates the
crontab line and the exact non-interactive compliance-aiops bundle generate
invocation (with the master-password env note) an operator can schedule.
Args: framework: hipaa / pci_dss / soc2 / gdpr / iso27001 / djcp_l3. cron: A standard 5-field cron expression (default: 02:00 every Monday). period: Relative window each run should cover (e.g. "7d", "last-7-days"). sign: If True, include --sign in the composed command.
Inputs: framework (required), cron, sign, period.
[READ] Evidence rows for ONE control + population size + reproducible query.
Args: framework: hipaa / pci_dss / soc2 / gdpr. control_id: e.g. "164.312(b)", "10.2", "CC8.1", "Art.30". since / until: ISO timestamps bounding the period. sample_size: Number of representative evidence rows to include.
populationSize is the full evidence count; sample is capped at
sample_size and sets truncated when there was more. scanTruncated
reports whether the underlying event scan itself hit its cap — if it is true,
the population is a slice and no coverage claim should be made from it.
Inputs: framework (required), control_id (required), since, until, +1 more.
[READ] Per-control coverage for a framework over a period (are we covered?).
Args: framework: hipaa / pci_dss / soc2 / gdpr. since / until: ISO timestamps bounding the reporting period.
Inputs: framework (required), since, until.
[READ] Denied / error / budget-exceeded ops — enforcement + anomaly evidence.
Denials prove the governance controls actually block, not rubber-stamp.
Args: since / until: ISO timestamps bounding the period.
Inputs: since, until.
[WRITE][risk=medium] Render a bundle to markdown / csv / json / oscal.
"oscal" emits a NIST OSCAL 1.2.3 Assessment Results document (written as .oscal.json). Read oscal_assessment_results first if you need the document inline plus its limitations — notably that control ids are not resolved against an imported OSCAL catalog, and that OSCAL has no "partially satisfied" state for the controls this tool evidences only partially.
Args: bundle_path: Path to a bundle .json. fmt: "markdown", "csv", "json", or "oscal". out_path: Output path (default: alongside the bundle).
Inputs: bundle_path (required), fmt, out_path.
[READ] Controls with no/weak evidence, each with an honest reason + remediation.
States the design-vs-operating caveat: audit trails evidence operating effectiveness strongly and control design/configuration only partially.
Args: framework: hipaa / pci_dss / soc2 / gdpr. since / until: ISO timestamps bounding the period.
Inputs: framework (required), since, until.
[WRITE][risk=medium] Assemble + hash-chain-seal an evidence bundle for a framework.
One-call happy path: coverage + approval trail + exceptions + sealed evidence records → a bundle .json under ~/.compliance-aiops/bundles/. Reads audit DBs and writes a local artifact only; touches no external system.
Args: framework: hipaa / pci_dss / soc2 / gdpr / iso27001 / djcp_l3. period_start / period_end: ISO timestamps bounding the reporting period. out_path: Where to write the bundle (default: the bundle dir). sign: If True and a signing key is stored, attach an HMAC signature. period: Convenience relative window (e.g. "7d", "last-7-days") used only when period_start / period_end are not supplied.
Inputs: framework (required), sign, period, out_path, +2 more.
[READ] List sibling audit DBs (~/.-aiops/audit.db) + readability/row counts.
Call this first to see which governed AIops tools' trails are available as compliance evidence.
Inputs: no named parameters.
[READ] Previously generated bundles + their chain head and metadata.
Inputs: no named parameters.
[READ] Supported compliance frameworks (HIPAA / PCI-DSS / SOC 2 / GDPR) + control counts.
Inputs: no named parameters.
[READ] A sealed bundle as an OSCAL 1.2.3 Assessment Results document.
Returns the document inline (writing a file is export_bundle's job) with a
summary and an explicit limitations list. Three things OSCAL cannot express
are handled rather than hidden: import-ap points at a back-matter resource
saying no assessment plan exists; control ids are framework-native and NOT
resolved against an imported catalog; and because status has only
satisfied/not-satisfied, controls this tool evidences only PARTIALLY are
reported satisfied with an evidence-strength prop plus remarks naming what
the audit trail does not prove — the count is in summary so it cannot be
skimmed past.
UUIDs are deterministic (v5, derived from the bundle's chain head), so re-exporting the same bundle produces a byte-identical document.
Args: bundle_path: Path to a bundle .json (from list_bundles).
Inputs: bundle_path (required).
[READ] Cross-tool audit event query — the workhorse.
Args: source: Restrict to one source tool (e.g. nutanix-aiops). skill / tool / status / risk_level: Field filters. approved: True = only ops with an approver; False = only ops without one. selector: Evidence class filter — audit_trail / attribution / change / enforcement / exception. since / until: ISO timestamps bounding the period. limit: Max rows to return.
Returns {"events": [...], "count": N, "returned": N, "limit": L, "truncated": bool | null, "scanTruncated": bool}. When truncated is
true more events matched than were returned — narrow the filters or raise
the limit. With a selector, truncated is null when the bounded scan
hit its cap before filling limit: more matches may exist. Never
characterise the trail (counts, "no violations found") from a truncated or
null-truncated result.
Inputs: tool, limit, since, skill, +6 more.
[WRITE][risk=medium] Attach an HMAC signature over a bundle's seal (uses stored key).
Requires a signing key in the encrypted store ('compliance-aiops secret set signing-key'). Medium risk because it reads the encrypted secret store.
Args: bundle_path: Path to a bundle .json.
Inputs: bundle_path (required).
[WRITE][risk=medium] Apply a recorded undo by dispatching its inverse tool.
The inverse runs through its own governed tool, so its real risk tier is recorded there. Pass dry_run=True to preview the inverse call without executing it. A token can only be applied once.
Args:
undo_id: The undoId from undo_list (or an _undo_id in a write result).
dry_run: If True, preview the inverse tool + params without running it.
target: Passed through to the inverse tool when it accepts a target.
Inputs: undo_id (required), target, dry_run.
[READ] List recorded, not-yet-applied undo tokens (most recent first).
Each entry names the original tool, the inverse tool that undo_apply
would run, and a human note. Use the undoId with undo_apply.
Returns {"undos": [...], "returned": N, "limit": L, "truncated": bool}.
truncated is measured (one extra row is fetched), not guessed from a
length coincidence: when it is true there are MORE tokens than shown, so
re-run with a higher limit rather than reporting the list as complete.
Each entry carries effectVerified. False means the original write lost
its response, so the change it reverses is PROBABLE, not confirmed — check
the live state before applying, and do not report the result as a restore
of a state that may never have been reached.
Args: limit: Max rows to return (default 50, capped at 500). target: Unused (undo state is host-local); accepted for CLI uniformity.
Inputs: limit, target.
[READ] Verify a sealed evidence bundle: chain integrity, seal head, signature.
Args: bundle_path: Path to a bundle .json produced by generate_evidence_bundle.
Inputs: bundle_path (required).
[READ] Chain head for a source's current events + row-id gap detection.
Record the returned chainHead out-of-band; re-run later to detect changes. Row-id gaps may indicate deleted audit rows.
Args: source: Source tool name (from list_audit_sources). since / until: ISO timestamps bounding the range.
Inputs: source (required), since, until.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
Loading tool schema changelog…
Scored across 19 tools
Most tools target clearly distinct objects/actions (evidence bundles, audit chains, reports, undo tokens), and descriptions cross-reference each other well. Minor overlaps remain: export_bundle(fmt=oscal) vs oscal_assessment_results both produce OSCAL from a bundle, and coverage_summary vs gap_analysis are complementary per-framework views that could be confused at a glance.
All names use consistent snake_case with readable, domain-specific terms. Verb style is mixed (sign_bundle, verify_bundle vs coverage_summary, gap_analysis, approval_report) and a few are noun phrases, but the convention is never chaotic.
19 tools is slightly above the typical well-scoped band, but the domain is broad (bundle lifecycle, audit querying, verification, reporting, undo, scheduling) and each tool maps to a distinct capability. Nothing looks like filler.
The surface covers the core lifecycle: generate, sign, verify, export (markdown/csv/json/OSCAL), list, coverage/control/gap analysis, audit query, chain verification, approval/exceptions reports, and undo list/apply. Gaps are minor — no bundle retrieval-by-id, retention/prune, or bundle diff/compare operations.
Compliance frameworks (SOC 2, ISO 27001, CMMC, NIST, more) delivered to AI agents as MCP tools.
Manage compliance controls, policies, and audit readiness for SOC 2, HIPAA, ISO 27001 and more.
HIPAA compliance AI agent — scan, grade, SRA, and generate compliance docs.
AI agent security, MCP 2026 schema & graph audits, <250ms guardrails, and compliance dossiers
