Incident Self-Report Guidance

The framework

Four steps. In order.

1. Report fast. Same day if possible. Within 24 hours at the outside. Do not wait until you have figured out whether it was "really" a problem. Reporting an event that turns out to be fine costs you ten minutes. Not reporting an event that turns out to be serious costs you your clearance.

2. Document the timeline. Write down what happened, in order, as soon as you can. Times, devices, accounts, URLs, what you typed, what was returned, who else was present. Memory degrades fast and adversarially fast under stress. Write before you forget.

3. Work with your security officer. They have done this before. They know the reporting channels, the investigation process, and what level of detail they need from you. Your job is to cooperate. Their job is to translate what happened into the language the system needs.

4. Do not hide. Do not delete logs. Do not delete chat history. Do not reset the device. Do not edit the timeline. Do not coach anyone else on what to say. Any of these turns a manageable incident into a clearance-ending one.

The math

Self-reporting in good faith is the lowest-cost path in almost every realistic scenario.

• Incidents reported promptly by the person who made them are almost always handled administratively. Counseling, retraining, additional supervision, sometimes a brief loss of access. People keep their clearances. Careers continue.
• Incidents discovered by someone else (a coworker, a monitoring tool, a counterintelligence office, a foreign government) are handled as security incidents. The presumption shifts. Outcomes get worse. Loss of clearance becomes likely. In some cases, prosecution becomes possible.
• The delta between the two outcomes is almost entirely about who reported it first and how fast.

The instinct to wait and see is the wrong instinct. The instinct to hope nobody notices is the wrong instinct. The right instinct is the boring one. Report it.

Scenario 1: You pasted CUI into ChatGPT three days ago

What happened. Three days ago, you pasted a paragraph from a CUI-marked document into a public AI tool. You did it under deadline pressure. You did not think about the marking. You realized it tonight.

What to do, in order:

1. Do not paste anything else.
2. Take a screenshot of your chat history with the tool, showing what you pasted and when. Do not delete the chat.
3. Write down the timeline: when you accessed the source document, when you pasted, what tool, what account, what you remember about the paragraph.
4. Email your security officer tonight. Subject line: "Possible mishandling incident, need to discuss." One paragraph. Do not include the CUI content in the email.
5. If your security officer is unreachable until morning, call the after-hours line if your program has one. If not, send the email and call first thing.
6. In the morning, meet with the security officer. Bring the timeline. Bring the screenshot. Answer their questions honestly.
7. Cooperate with whatever steps follow. This may include requesting the AI tool's vendor purge the chat under their enterprise or law-enforcement process, additional training, or a documented counseling.

What not to do:

• Do not delete the chat to "clean it up." That looks like a cover-up and removes the evidence needed to assess scope.
• Do not paste more of the document to ask the AI tool to "forget" what you pasted. That makes it worse.
• Do not tell coworkers before you tell your security officer.

Scenario 2: You attended a conference where someone asked unusual questions

What happened. At a vendor booth or a hallway conversation, someone asked questions about your customer, your program, or your tools that felt off. They knew more than they should have. They suggested follow-up over coffee, dinner, or messaging app.

What to do, in order:

1. While at the conference, do not provide more information. Use the cover story. "I cannot get into specifics." Repeat as needed.
2. Get the person's name, affiliation, business card if offered, and any handle they suggested.
3. Note the time, location, and what was asked, in writing, the same day. Memory of these conversations decays fast and the details are what counterintelligence needs.
4. Do not accept follow-up invitations in the moment. "Let me check my schedule." Then do not follow up.
5. Report to your security officer within 24 hours of returning. They will route the report to the counterintelligence office at your program.
6. If the person contacts you after the conference, do not respond. Forward the message to your security officer.

What not to do:

• Do not try to "play along" to gather more information. You are not trained for this and will make it worse for the actual investigators.
• Do not assume it was nothing because the person seemed friendly. Friendly is the technique.
• Do not delete the LinkedIn or messaging contact request. The metadata is useful to investigators.

Scenario 3: You discovered prompt injection in production

What happened. You found that a deployed AI system at your program is vulnerable to prompt injection. A crafted input causes the model to ignore its system prompt, exfiltrate context, or take an unintended tool action. The system handles sensitive data.

What to do, in order:

1. Stop public exposure if you have the authority. Pull the system behind a feature flag, take it offline, or restrict access. If you do not have the authority, get the person who does on the phone now.
2. Preserve evidence. Capture the inputs that triggered the behavior, the outputs, timestamps, request IDs, and the model and prompt version that were running. Do not edit logs.
3. Notify your security officer and your program's incident response lead. If the system handles CUI or classified data, treat the injection as a potential data spill and follow the spill reporting process.
4. Notify the vendor or model provider if a third-party model is involved, through the approved channel for your program.
5. Document the timeline: when you discovered it, how, what you tested, what you did to mitigate, who you notified.
6. Participate in the post-incident review. Do not assign blame in writing. Stick to facts.

What not to do:

• Do not patch quietly and skip the report. Even if the patch holds, the existence of the vulnerability is a reportable event for many programs.
• Do not test the vulnerability further than needed to confirm it. Each test may create more spill.
• Do not discuss the incident on a public forum, vendor mailing list, or social media until your program has authorized disclosure.
• Do not use the incident as a resume bullet later. "Found prompt injection in production" is fine in abstract. The specifics are not.

The single sentence to remember

If you are reading this guidance because something already happened, stop reading and email your security officer right now. You can finish reading after.