← All guides · Reviewed November 2026
Building a Disclosure Packet After an Agent Incident
The short answer
A disclosure packet is the structured document that states what an agent did, in the order it did it, with redacted evidence attached. BoundaryVault builds one from your scan findings in five steps: scan the log, review the findings, generate the packet (format boundaryvault-disclosure/1.0, modeled on OpenAI's published self-disclosure format), add operator notes, and validate it — review-only, never auto-filed. Packet structure as produced by BoundaryVault's packet generator, November 2026. Start with the free log scan.
What are the steps?
- Scan the log. Paste the recorded action log and, if you have one, the declared scope config that was in force. The detector returns the findings — start from how the forensics work.
- Review the findings. Open your own log at each finding's action index. Confirm or dismiss each one while the context is fresh; the packet inherits whatever the findings say.
- Generate the packet. The generator assembles the structure in the table below from the findings — summary, patterns, timeline, evidence references, worklist — and seals it with an evidence fingerprint and a packet id derived from that fingerprint.
- Add operator notes. What you found on review, what you rotated, what you decided. The packet has a dedicated operator_notes field; a packet without notes discloses the machine's view only.
- Validate, then file it yourself. Check the packet carries every required key (below). Its review_status starts at pending_operator_review and its transmission block records filed: false — because filing is your explicit action, never the platform's.
What is inside the packet?
| Key | What it carries |
|---|---|
| packet_format / packet_id | boundaryvault-disclosure/1.0 and a bv- id hashed from the evidence fingerprint and generation time |
| incident_summary | Log name, findings total, actions scanned, counts by pattern, highest severity, first and last finding timestamps, and a plain-language summary text |
| patterns | One entry per pattern found: rule id, occurrences, severities, the action indices involved, and a description of the pattern |
| timeline | Every finding in timestamp order: pattern, tool, agent, action index |
| evidence_refs | Numbered references (evidence-1, …) with the redacted excerpt from detection time — raw secrets never enter a packet |
| blast_radius | The rotation worklist: every credential, token, wallet and destination touched, in exposure order, each with its rotation step |
| policy_at_scan | The declared scope exactly as it stood for this scan, so a reviewer can re-run the same log under the same policy and get the same findings |
| operator_notes / review_status | Your notes, and the review state — pending_operator_review until you act |
| transmission / disclaimer | filed: false, no destinations, the not-auto-filed note; and the honest-scope disclaimer (known patterns via declared rules only) |
| evidence_fingerprint | A hash over the findings that seals the evidence set |
What variants exist?
The base packet is the operator's document. On top of it the platform builds audience variants from the same findings — insurer and customer packet variants, and an Article 73 clock packet that shows the reporting clock, the deadline and the fields still missing for that audience (Team, over the API). Every variant is computed from the same findings and stays review-only: no variant is transmitted anywhere by the platform. Packet JSON export is a Pro capability; the free tier includes a packet preview.
Run the free log scan · What scope escape means · Ingenious AI
Frequently asked questions
What is a disclosure packet after an agent incident?
A structured document that states what happened, in the order it happened, with the evidence attached in redacted form. BoundaryVault's packet (format boundaryvault-disclosure/1.0, modeled on OpenAI's published self-disclosure format) carries an incident summary, the pattern entries, a timeline, evidence references, operator notes, a blast-radius rotation worklist and the policy in force at scan time.
Does BoundaryVault file or send the packet for me?
Never. The packet is generated for operator review only: its transmission block records filed: false and no destinations, and the generator contains no sending, filing, posting or emailing code path. Downloading or forwarding the packet is always the operator's explicit action.
What goes in the packet's evidence section?
One reference per finding — evidence-1, evidence-2, and so on — each with the pattern, timestamp, tool, agent and the redacted excerpt from detection time, labelled 'secret values redacted at detection time'. Raw secret values never enter a packet. An evidence fingerprint (a hash over the findings) seals the set so a reviewer can tell if it changed.
What is the blast-radius worklist?
A rotation checklist derived from the findings in exposure order: every credential, token, wallet and destination touched, each with its rotation step — rotate the credential and revoke the old value; revoke the minted token and any token derived from it; move funds to a new wallet and treat the old one as burned; block the destination at egress and review every send to it.
Can I check a packet is complete before I use it?
Yes. A valid packet carries the required keys — packet_format, packet_id, generated_at, generator, incident_summary, patterns, timeline, evidence_refs, operator_notes, review_status, transmission, disclaimer and evidence_fingerprint — and the platform's validator checks them, including that the format string matches boundaryvault-disclosure/1.0 and the timeline and evidence lists are present.