The Evidence Pack That Answers "Can You Prove It?"

An agent that can read your systems and act on them needs guardrails, the same way a new hire with production access needs an onboarding checklist and someone reviewing their first few changes. That's what Cognous's Open Control Stack is: a manifest declares what an agent may do before it ever runs, a control plane enforces that live, and every run leaves behind a replay bundle — a signed file recording exactly what the agent proposed, what got decided, and what it relied on, so anyone can check it later.

That's real technical proof, and it's the file you'd reach for in a deployment review — except the person running that review isn't going to open a JSON file and check whether a signature is valid. They're going to ask what the agent is for, what it can touch, what got blocked, and whether you can prove it, and they want that answer in a document, not a file they have to parse.

That's the gap Agent Governance Evidence Pack closes. It doesn't record anything at runtime and it doesn't replace the replay bundle. It's where someone — a human, for now — turns the technical record into the document a risk committee actually reads.

The Report Itself

Cognous's tooling for this layer is agep — a schema, a validator, and a renderer. Run agep render on a completed pack and this is what comes out:

$ agep render support_agent_evidence_pack.json --out report.md

## 1. Executive Summary

**SupportAgent** is deployed in the **production** environment. Business
purpose: Reduce first-response time on support tickets by pulling account
context and drafting a reply for a human to send.

The agent has access to **3** tool(s) and can propose **3** action(s), of
which **2** require authority or human review.

**1** replay bundle(s) are available (1 signed).
Validation summary: 1 valid bundle(s), 0 invalid, 0 error(s), 1 warning(s).

**1** open risk(s) (0 critical).

The rest of the report breaks into eight areas:

• Agent and Deployment Overview — who owns the agent, why it exists, and where it's running.
• Tool and Action Inventory — every tool the agent can reach and every action it can propose, each flagged for whether it needs authority or review.
• Authority Model — the rules of authority itself: what counts as privileged, how a grant gets requested, whether it expires.
• Policy Controls — the mechanisms actually implemented to enforce those rules, each with a status and an evidence reference.
• Blocked-Action and Reliance Summaries — what got stopped and why, and what data the agent leaned on to do its job.
• Replay Bundle Inventory and Validation Summary — which replay bundles back this report up, and whether those bundles passed validation.
• Redaction and Export Summary — a record that the replay bundle was redacted for an outside recipient: which fields were stripped and where the redacted file lives, not the redacted content itself.
• Risk Register — open risks, each tied back to real evidence rather than asserted.

Two sections are left off that list on purpose. Review Records is empty because this pack is still in_review — a review record only exists once someone's actually signed off, and nobody has yet. Known Limitations is fixed text the renderer appends to every pack regardless of content, not something specific to this one.

Nothing Builds This For You

The evidence pack is built from a JSON file. That file is data-driven, but human-curated: it incorporates data pulled from the replay bundle — the block count, the reliance record, and so on.

Pulling those raw facts out of the bundle takes a script written for this workflow. It's not part of the evidence pack format itself.

As an example, send_email got blocked once. The script counts that, and pulls the raw reason logged for it: Tool 'send_email' is explicitly blocked in this frame. That's as far as the script gets. The schema doesn't leave room to add anything more structured than that — a blocked-action record has exactly one free-text field for explaining what happened, reason_summary, and nothing else. So if you also want the record to say why nothing overrode the block — that no authority was ever granted for it — the only place that fact can go is into that same sentence, written by a person.

Here's what that produced, with each field marked for where it came from:

{
  "action_name": "send_customer_email",
  "action_type": "external_send",
  "tool_name": "send_email",
  "count": 1,
  "reason_summary": "Email send blocked: send_email is explicitly blocked in this frame and no authority grant for the email.send.customer scope exists.",
  "evidence_reference": "run:e6d9a08e-40cf-4b4f-b4dd-82201bc15901"
}

tool_name, action_type, count, and evidence_reference all come straight from the bundle. action_name is a readable label a person chose — the bundle only knows the tool as send_email. reason_summary is the one sentence written from scratch.

The same script could call an LLM to write reason_summary instead of a person — combining a couple of facts into one sentence is exactly what an LLM is good at. Cognous has a replay-bundle import helper and "richer executive summaries — enhanced narrative generation" on the roadmap, so a script-plus-LLM setup is a reasonable stopgap until that lands.

Validation Catches What You Forget

Once a pack is built, agep validate checks it against the schema's own rules — things like "if an action requires authority, the pack has to say what that authority actually is." The first draft of this pack didn't say that, and validation caught it:

$ agep validate support_agent_evidence_pack.json
Pack ID : ep-support-agent-2026-001
Valid   : False
Issues  : 4
  [ERROR] E018 [authority_model]: One or more actions have authority_required=True but authority_model is missing.
  [WARNING] W014 [review_records]: review_records is empty.
  [WARNING] W019 [action_inventory]: Action 'draft_ticket_reply' is type 'write' but authority_required is False.

The error is straightforward: send_customer_email was marked as needing authority, but nothing in the pack said what that authority was. That's not something the script would catch — it only reads replay bundles, and a replay bundle doesn't carry that information. It exists, though: the manifest declares it, back at the Declare layer, as the email.send.customer scope. The script just never looks there. The fix is adding it by hand: the email.send.customer scope from the manifest, with a note that no grant exists yet for this deployment. That note is accurate. It's the real reason the send got blocked instead of just flagged for review.

W019 is worth a one-line note: the validator's docs undersell which action types trigger it — the code also flags plain write actions like draft_ticket_reply, not just external sends. The warning is left standing rather than papered over, because draft_reply genuinely has no authority gate today.

With the missing authority section added, the pack validates clean:

$ agep validate support_agent_evidence_pack.json
Valid   : True
Issues  : 3
  [WARNING] W014 [review_records]: review_records is empty.
  [WARNING] W015 [review_status]: Production deployment has review_status 'draft' or 'in_review'.
  [WARNING] W019 [action_inventory]: Action 'draft_ticket_reply' is type 'write' but authority_required is False.

All three remaining warnings are honest, not bugs to fix. There's no review record because nobody has reviewed this pilot run yet. draft_reply genuinely has no authority gate. A pack with zero warnings at this stage would be hiding something, not proving something.

That gap is also the pack's one open risk. The Risk Register says the same thing in plain terms: draft_reply needs manual review on every single invocation, because it was never added to the control plane's allowed-tools list.

Confirming the Evidence

The last step is a manual approval. Recall that the Review Records section sits empty right now. Once validation passes, a human — typically a CISO or Risk Manager — reviews the pack and signs off, adding a ReviewRecord: their name, their role, a decision, and a timestamp. That's what moves review_status from in_review to approved.

The schema enforces this, not just documents it. A pack can't be marked approved without that record on file, and a critical, unresolved risk in the register blocks approval outright, no matter who signed off.

With the official sign-off, the evidence pack is ready for whatever comes next — an audit, a board review, or wider deployment of the agent it covers.

Proving The Whole Stack Held

In this series, we've covered the four layers of Cognous's Open Control Stack: a manifest that declares what an agent may do, a control plane that enforces it live, a replay bundle that proves a specific run followed the rules, and an evidence pack that turns all of that into something a non-engineer can actually approve or reject. Each layer produces something real the next one consumes — sometimes with a clean mapping, sometimes, like this one, with a script and a person doing the work no importer does yet.

Clone Agent Governance Evidence Pack and try agep against the example packs in the repo, or build one from your own control plane and replay bundle records.