Case study · Runtime recovery
When incident AI actions diverge, the decision still has to be explained
A security operations team faced conflicting records after an AI-assisted remediation attempt during an active incident. Without Recon, explaining who authorized what—and what actually happened—would have depended on manual log stitching.
Illustrative ribbon — not a production screenshot or KPI chart.
01 · Before
What was happening before Recon?
Incident response ran on fragmented exports: SIEM alerts, chat transcripts, and agent logs that did not share a single correlation from attempted action to outcome. When leadership asked why a credential rotation fired, the team could describe intent—but not defend the decision with attributable proof.
- AI-assisted remediation crossed team boundaries without a shared decision record
- Workflow revisions left conflicting narratives about what the agent attempted
- Reviewers reconstructed timelines manually before every leadership briefing
02 · Governed moment
What consequential AI action created risk?
During an active incident, an autonomous security agent attempted credential revocation and endpoint isolation across a production segment—a high-blast-radius action that could disrupt live services if the wrong scope executed.
- The agent attempted cross-segment remediation without a durable authority check
- Conflicting workflow versions made it unclear which policy version should apply
- IR leadership needed an answer before the next customer-facing status update
03 · Recon intervention
What did Policy permit, hold, or escalate?
Recon evaluated the governed interaction at the boundary. Policy is business control—not an architecture diagram. The team's security Policy required SOC lead approval before high-impact remediation executed.
- Policy held the remediation attempt pending explicit SOC lead approval
- Recon returned a require_approval decision the workflow could enforce
- Operators received a clear escalation path instead of silent execution
04 · Proof retained
What Trust Receipt/Ledger evidence remained afterward?
Every governed interaction produces inspectable proof. The Trust Receipt captured the attempted action, Policy decision, and authority context. The Ledger appended durable evidence tied to the same correlationId—so the team did not depend on stitched logs to explain the hold.
- Trust Receipt — open the artifact and see why Recon held the remediation
- Ledger — confirm the entry persists for retention and investigation export
- One correlationId threads from attempted action → decision → receipt → ledger entry
Recon requires approval before this action proceeds.
- correlationId
- tacorr_8f3a2b1c4d5e6f708192a3b4c5d6e7f8
- receiptId
- a1b2c3d4e5f6789012345678901234567890abcdef1234567890abcdef123456
- decision
- require_approval
- policyId
- policy_soc_lead_approval_gate
- actionType
- cyber_remediation_access_action
Ledger
The Ledger is your durable evidence spine—every Trust Receipt links back to the same correlationId for retention and audit.
- correlationId
- tacorr_8f3a2b1c4d5e6f708192a3b4c5d6e7f8
- ledger.entryId
- b2c3d4e5f6789012345678901234567890abcdef1234567890abcdef1234567890
05 · What changed
What materially changed for operator or business?
Outcome frame: Decision explained. IR leadership received a defensible account of what the agent attempted, which Policy applied, and why execution paused—without asking the team to learn internal runtime vocabulary or rebuild timelines from chat exports.
- Leadership briefing used attributable proof instead of reconstructed narratives
- Operators spent less time reconciling conflicting workflow versions post-incident
- The team could show what was attempted and why it did not execute unchecked
Outcome frame
Decision explained
Simulation only—illustrative incident-response narrative with no real customer data, no production outage claim, and no measured ROI.