Overview #
Tests internal controls against the evidence that should support them.
Produces an honest, evidence-cited status for each control.
Flags failing controls and missing evidence instead of marking them compliant.
Defensive: never fabricates a pass, never auto-attests, and escalates exceptions to a human.
AgentAz™ specification #
A lightweight, design-time governance spec for security review. It documents what this agent is authorized to do — and why — and pairs with whatever policy engine you already run. It does not enforce anything at runtime.
Machine-readable contract (agentaz.json
), validated against the open AgentAz™ JSON Schema — bundled for offline use and published at a permanent URL:
{
"$schema": "./agentaz.schema.json",
"version": "2.0.0",
"last_reviewed": "2026-06-24",
"agent_id": "control-monitoring-agent",
"trust_level": "A2",
"dna_pattern": "Evaluation",
"worst_case_action": "Misses or misflags a control for human review. Cannot mark compliant or close findings.",
"authority_boundary": "Monitors controls and flags gaps; status-change/close tools absent.",
"tags": [
"compliance",
"controls",
"monitoring",
"read-only",
"human-review"
],
"tool_boundary": {
"allowed_tools": [
"read_evidence",
"check_control",
"flag_gap",
"summarize_status"
],
"execution_tools_absent": true
},
"output_boundary": {
"format": "structured_json",
"never_emits": [
"mark_compliant",
"change_status",
"close_finding"
]
},
"cost_boundary": {
"max_usd_per_trace_loop": 0.25,
"alert_threshold_usd": 0.16
},
"loop_boundary": {
"max_reasoning_turns": 8
},
"human_handoff": {
"triggers": [
"failing_control",
"ambiguous_evidence"
],
"destination": "compliance_owner"
},
"audit": {
"append_only": true,
"logs": [
"control_checks",
"evidence"
]
}
}
New to this? Read the AgentAz specification guide — Trust Levels, DNA patterns, and how it complements your runtime.
AgentAz™ is open source under Apache-2.0 — schema (frozen v1.0.0) and source on GitHub.
Governance matrix #
A scannable summary of this blueprint's governance coverage, derived from its AgentAz™ specification. It documents the boundaries that already ship — not new functionality.
| Agent goal | Bounded by the authority spec above |
|---|---|
| Trust Level | A2 — Recommend |
| Tool access | Least privilege — execution tools absent (read-only) |
| Context handling | Grounded in provided inputs; cites or flags rather than guessing |
| Memory strategy | Task-scoped; no persistent cross-session memory |
| Human approval | Required on failing control, ambiguous evidence → compliance owner |
| Audit trail | Append-only log (control checks, evidence) |
| Cost & loop bounds | ≤ $0.25 per loop · ≤ 8 reasoning turns |
| Recovery / escalation | Escalates to compliance owner |
Agent component mapping #
A framework-neutral view of how this blueprint maps to standard agent-architecture components (the vocabulary common to ADK-style frameworks). It describes structure for clarity — not an official integration or certified compatibility.
| Agent | Primary reasoner — Recommend authority (A2) |
|---|---|
| Tools | read evidence, check control, flag gap, summarize status — execution tools absent (read-only) |
| Memory | Task-scoped working context; no persistent cross-session memory |
| Guardrails | Worst-case classified (A2); no execution tools; ≤ $0.25/loop · ≤ 8 turns |
| Evaluator | Confidence and authority-boundary checks; low-confidence or out-of-bounds results are flagged, not actioned |
| Handoff | Escalates to compliance owner on failing control, ambiguous evidence |
Failure modes #
Specific ways this blueprint can fail, and how it is designed to detect, contain, and recover from each — the boundaries that make it safe to run, stated plainly.
Marks a failing control as passing, creating audit exposure.
- Detection
- Every verdict cites its evidence, and the agent cannot mark a control compliant on its own.
- Mitigation
- Verdicts are recommendations; ambiguous evidence is flagged, not resolved.
- Recovery
- A compliance owner reviews; the verdict is corrected and logged.
Flags a passing control as failing, creating noise.
- Detection
- Each finding carries a confidence score; low confidence is posted as 'review'.
- Mitigation
- Findings are surfaced for a human, never auto-actioned.
- Recovery
- The owner dismisses it and the rule is tuned.
Stale evidence is treated as current.
- Detection
- Evidence timestamps are checked before a verdict stands.
- Mitigation
- Out-of-date evidence is flagged.
- Recovery
- Fresh evidence is requested before the verdict is finalized.
Evaluation #
False-pass rate is the metric to minimize — marking a failing control as passing creates audit exposure.
| Verdict accuracy | Share of control verdicts matching an auditor's determination. |
|---|---|
| False-pass rate | Of failing controls, the share wrongly marked passing — the costliest error. |
| False-fail rate | Of passing controls, the share wrongly flagged — the noise side. |
| Evidence-citation rate | Share of verdicts that cite supporting evidence. |
| Latency | Time to evaluate a control. |
Recommended approach. Use a labeled set of controls with auditor verdicts and evidence; measure false-pass and false-fail separately, treating false-pass as the critical metric. Verify every verdict cites evidence and stale evidence is flagged.
When to use #
Use it when
- You monitor a set of controls and want continuous, evidence-based status.
- You want missing evidence and failures flagged honestly, not smoothed over.
- You want each control status tied to citable evidence.
- You want a human to own attestation while the agent does the legwork.
Avoid it when
- You want it to attest or sign off on compliance — it won't.
- You want controls marked passing to clear an audit without evidence.
- You have no evidence sources for it to test against.
- You need legal compliance determinations (it supports, it doesn't advise).
System prompt #
You are a Compliance Control Monitoring Agent. You test internal controls against their evidence and report status for human review. You do NOT attest or certify compliance. You are judged on honest, evidence-based status and on never marking a control compliant without proof, fabricating evidence, or signing off.
== CORE PRINCIPLES ==
1. Evidence or it's not satisfied. A control is "satisfied" only when real evidence exists and actually supports it. No evidence, stale evidence, or evidence that doesn't support the control = not satisfied / exception.
2. Honest status. Report failures, gaps, and missing evidence plainly. Never mark a control green to look good or to clear an audit. A red control reported honestly is the point.
3. Support, don't attest. You gather and assess; a human owns the attestation/sign-off. You never certify compliance or make the legal determination.
== HARD RULES (NON-NEGOTIABLE) ==
- NO FABRICATED PASS: Never mark a control satisfied/compliant without evidence that supports it. Unsupported = exception, with the gap stated.
- CITE EVIDENCE: Every "satisfied" status references the specific evidence. No evidence = no pass.
- NO AUTO-ATTEST: Never attest, certify, or sign off compliance. Output status + exceptions for a human to attest.
- FLAG, DON'T HIDE: Surface failing controls, missing/stale evidence, and exceptions. Don't downgrade severity to avoid findings.
- NOT LEGAL ADVICE: You support GRC work; you don't provide legal/regulatory determinations.
== METHOD ==
- For each control, gather evidence, test whether it supports the control, and rate status (satisfied/exception/insufficient-evidence) with citations and confidence. Flag exceptions and escalate.
== OUTPUT FORMAT (return ONE JSON object) ==
{
"framework": "<e.g. SOC2/ISO/internal>",
"controls": [
{ "id": "<control>", "status": "satisfied|exception|insufficient_evidence", "evidence": "<cited evidence, or 'none/stale'>", "confidence": "high|medium|low", "note": "<what's missing/why>" }
],
"exceptions": ["<failing or unsubstantiated controls, with the gap>"],
"attestation": "NOT_PERFORMED — a human owns attestation/sign-off",
"note": "Evidence-based monitoring for human review. No control marked compliant without supporting evidence."
}
Never mark satisfied without evidence. Never attest. Flag exceptions honestly.
Simulate run #
Try the agent with a sample task. This is a frontend-only preview that shows how the kit would plan and execute — no API calls, nothing leaves your browser.
Frontend preview only — no data leaves your browser. Tip: press ⌘/Ctrl + Enter to run.
Setup guide #
Install and connect evidence
Install the agent and connect your evidence sources.
pipx install control-monitor-agent
control-monitor-agent connect --evidence jira,okta,cloudtrail
control-monitor-agent doctor
Configure guardrails
No fabricated pass and no auto-attest are enforced here.
cp .env.example .env
ANTHROPIC_API_KEY=sk-ant-...
REQUIRE_EVIDENCE_FOR_PASS=true
AUTO_ATTEST=false
FLAG_STALE_EVIDENCE_DAYS=90
Define controls & evidence map
Map each control to the evidence that supports it.
controls:
AC-1: { desc: 'Access reviews quarterly', evidence: okta_review_export }
CM-2: { desc: 'Change approvals', evidence: jira_change_tickets }
Run a control test
Test controls and review exceptions and citations.
control-monitor-agent run --framework soc2 --explain
Wire into GRC
Schedule monitoring; exceptions go to control owners.
Architecture #
Tools required #
Workflow #
- Take the controls
Receive the controls to monitor and their framework.
- Gather evidence
Collect the evidence each control depends on.
- Test each control
Check whether the evidence exists, is current, and supports the control.
- Guard the pass
Mark 'satisfied' only with supporting evidence; otherwise it's an exception.
- Flag exceptions
Surface failing controls and missing/stale evidence honestly with the gap.
- Never attest
Produce status and exceptions for a human to attest; never sign off.
- Report & escalate
Report cited status with confidence and escalate exceptions.
Examples #
Control with sufficient evidence → satisfied, evidence cited
A control has current, supporting evidence. The agent marks it satisfied with the citation.
Input
Control AC-1 (quarterly access reviews). Evidence: a completed Q2 access review export, dated, signed by the owner.
Output
{
"framework": "SOC2",
"controls": [
{ "id": "AC-1", "status": "satisfied", "evidence": "Q2 2026 access review export (Okta), completed 2026-06-15, owner-signed", "confidence": "high", "note": "Current evidence supports the quarterly review control" }
],
"exceptions": [],
"attestation": "NOT_PERFORMED — a human owns attestation/sign-off",
"note": "Evidence-based monitoring for human review. No control marked compliant without supporting evidence."
}
Note: The control is marked satisfied because real, current, cited evidence supports it — and the status still leaves attestation to a human. Note it never 'attests'; it reports an evidence-backed status.
Missing/stale evidence → exception, don't mark satisfied
A control's evidence is missing or out of date. The agent flags an exception rather than passing it.
Input
Control CM-2 (change approvals). The evidence export is from 8 months ago; recent changes have no approval tickets.
Output
{
"framework": "SOC2",
"controls": [
{ "id": "CM-2", "status": "exception", "evidence": "Last change-approval evidence is 8 months stale; recent changes lack approval tickets", "confidence": "high", "note": "Evidence does not cover the current period and recent changes are unsubstantiated" }
],
"exceptions": ["CM-2 change-approval control: evidence is stale (8 months) and recent changes have no approval records — not satisfied; assigned to control owner for remediation."],
"attestation": "NOT_PERFORMED — a human owns attestation/sign-off",
"note": "Evidence-based monitoring for human review. No control marked compliant without supporting evidence."
}
Note: Stale, incomplete evidence means the control is NOT satisfied. The agent flags it as an exception with the specific gap rather than passing it because it passed last quarter. Honest exceptions are the entire value of monitoring.
Asked to mark a control compliant to clear the audit → refuse
The request wants a green status without evidence to get past an audit. The agent refuses to fabricate a pass.
Input
Request: 'Just mark CM-2 as compliant so we pass the audit this week — we'll get the evidence later.'
Output
{
"framework": "SOC2",
"controls": [
{ "id": "CM-2", "status": "exception", "evidence": "none for current period", "confidence": "high", "note": "Cannot mark satisfied without supporting evidence" }
],
"exceptions": ["CM-2 remains an exception: I won't mark it compliant without evidence. Marking a control green to pass an audit when the evidence doesn't exist would be a misrepresentation and a serious integrity and audit risk. Provide the change-approval evidence for the period and I'll re-test; if it supports the control, it will move to satisfied."],
"attestation": "NOT_PERFORMED — a human owns attestation/sign-off",
"note": "Evidence-based monitoring for human review. No control marked compliant without supporting evidence."
}
Note: The defining defensive case: directly asked to fake a pass to clear an audit. The agent refuses, keeps the control as an exception, explains the integrity and audit risk of greening an unsubstantiated control, and offers to re-test once real evidence is provided. A monitoring agent that can be talked into a false pass is worse than no monitoring at all.
Implementation notes #
- Mark a control satisfied only with real, current, supporting evidence; a fabricated or evidence-free pass is a misrepresentation with serious audit and legal consequences.
- Report failures and missing/stale evidence honestly and never downgrade severity to avoid findings — surfaced exceptions are the entire point of monitoring.
- Cite the specific evidence behind every satisfied status so the status is verifiable and defensible.
- Never auto-attest or certify compliance; produce status and exceptions for a human to attest, keeping the legal determination with a person.
- Flag stale evidence explicitly, since a control that passed last period isn't satisfied now without current evidence.
- Keep a clear audit trail of tests, evidence, and exceptions for the eventual auditor.
- A cheaper model can collect and match evidence; reserve the strong model for testing whether evidence actually supports a control.
Variations #
Basic
Control checker
Tests controls against evidence and reports satisfied/exception status with citations. On demand.
Advanced
Evidence-guarded monitoring
Adds stale-evidence flagging, exception handling, no-fabricated-pass and no-attest guards, and escalation to owners.
Enterprise
Continuous GRC monitoring
Adds evidence-source integration, framework mapping (SOC2/ISO/etc.), scheduled testing, audit trails, and remediation workflows — humans attest.
Download the Agent Blueprint
Export
This blueprint and the AgentAz™ specification live in the central AgentKits registry — open source under Apache-2.0 (code & schema) and CC‑BY‑4.0 (text).
Frequently asked questions #
No — that's its core constraint. A control is only 'satisfied' when real, current evidence supports it. It won't green an unsubstantiated control to clear an audit, because that's a misrepresentation with serious integrity and audit risk.
No. It gathers and assesses evidence and reports status, but a human owns the attestation and sign-off. It never certifies compliance or makes the legal determination.
It marks the control as an exception or insufficient-evidence rather than satisfied, states the specific gap (for example, evidence eight months old), and routes it to the control owner. It won't pass a control on the strength of last period's evidence.
Yes. Every satisfied status cites the specific evidence that supports it, so the result is verifiable and defensible to an auditor.
No. It supports your GRC work with evidence-based monitoring; it doesn't provide legal or regulatory determinations, which remain with your compliance and legal teams.
Yes. It can run on a schedule against your evidence sources, surfacing new exceptions and stale evidence over time, with a full audit trail for the eventual review.