AI Incident Reporting Needs a Standard Language

The Cybersecurity Alliance is drafting guidelines to standardize how companies report AI security incidents.

What the SAFE guidelines actually do

The Cybersecurity Alliance is creating a framework called SAFE to help organizations share information about AI attacks. Right now, when an AI system gets hacked or used to steal data, companies struggle to report it. They do not know what data to collect, how to describe the attack, or who to send it to. The SAFE guidelines aim to fix this by creating a common format for these reports. This allows security teams to see patterns across different companies. It helps defenders understand how an attacker might manipulate an AI model to break into a system or leak sensitive information.

The governance failure we are seeing

The main failure here is the lack of standardized reporting for AI-specific threats. Traditional cybersecurity reporting focuses on malware or phishing. It does not cover prompt injection or data poisoning. Because companies cannot easily report these incidents, the broader security community cannot learn from them. This leaves everyone vulnerable. We saw this problem recently with the Samsung incident in 2023. Staff members pasted confidential source code into a public chatbot. The system processed the data and sent it to a third party. Because there was no clear reporting mechanism for this specific type of data leak, the incident went unreported until it was too late. Similarly, the Bing and Copilot demos in 2023 showed how attackers can hide instructions in web pages. These hidden commands hijacked the assistant, causing it to leak data or perform actions it was not supposed to do. Without a standard way to report these events, the industry remains blind to these evolving risks.

How the attack mechanism works

To understand the risk, you have to understand the mechanism. Prompt injection attacks work by manipulating the input that an AI model receives. The attacker tries to trick the model into ignoring its original instructions or system prompt. In the Samsung case, the failure was human behavior. Staff members treated public tools like internal memos. They copied and pasted sensitive text directly into the chat interface. The AI model then treated this text as normal conversation and processed it. In the Bing case, the attack was technical. Attackers inserted specific strings of text into emails or web pages. When the AI assistant read these pages, it interpreted the strings as commands. It stopped following its safety guidelines and revealed information or executed unauthorized tasks. These incidents show that the action path for AI systems is different from traditional software. The user input is directly processed by the model, creating a new surface for attack.

Controls and obligations for prevention

Companies need to implement specific controls to stop this from happening. First, you need strict input and output filtering. This means checking every piece of data that enters the model and every response that leaves it. You must block any attempt to send sensitive secrets or PII to a public model. Second, you need an acceptable use policy that is clear and enforced. Staff need to know exactly what they can and cannot paste into AI tools. Third, you must limit the tools the AI can access. The AI should have the least amount of privilege necessary to do its job. If it can only read files and not write them, it cannot cause as much damage. Finally, you need to track your risk indicators. You should monitor the injection block rate against a maintained attack corpus. You also need to ensure there are zero sensitive tool calls without secondary authorization.

What to do

• Review your current incident response plan to see if it includes AI-specific attacks like prompt injection.
• Implement real-time filtering on your AI action paths to catch sensitive data before it reaches the model.
• Train your team on the Samsung and Bing precedents to make them aware of how these attacks look in practice.
• Set up monitoring for your key risk indicators, such as the injection block rate, to catch anomalies early.

More from our platforms

These sister platforms cover the parts of this problem that sit outside governance.

• Argus (argus.threatclaw.ai) records every trace an AI application produces and scans it for prompt injection, jailbreaks and data leaks, including the attacks hidden inside retrieved documents and tool results rather than in what the user typed. Governance decides what an AI agent is allowed to do. Argus shows what it actually did.
• ThreatClaw (www.threatclaw.ai) tracks the threat side of the same systems: 22 live intelligence feeds, exploitation predicted before it is officially confirmed, threat actor profiles, and detection rules you can deploy straight away. A control is only as good as the threat it is sized against.