Briefly: The Shared AI Findings Exchange (SAFE) project proposes treating an AI agent as a full participant in an incident: quickly stop the dangerous action, preserve not only standard logs but also prompts, traces, tool calls, model versions and guardrails, permissions, approvals, and changed artifacts, then analyze the failure across eight layers. SAFE is still a rules proposal, not a law or certification, but it can already be used as the basis for an internal playbook.
This article is intended for executives, CIOs, CTOs, CISOs, process owners, SOC/IR teams, and implementation teams. It explains the SAFE proposal as of August 14, 2026, and provides an operational method for a single agentic process. It does not replace a legal assessment of notification obligations, does not set a universal log retention period, and does not prove compliance with Russian or foreign requirements.
Contents
- What SAFE is and why people are talking about it now
- Which events SAFE says should be reportable
- How the notification timeline works
- What evidence needs to be preserved
- Why a standard application log is not enough
- How to conduct an incident review
- Minimum incident record for an AI agent
- How to run a drill before the first real failure
- Metrics and stop rules
- SAFE limitations and open questions
- Frequently asked questions
- How AI Dawn helps prepare an agentic environment for incidents
- Conclusion
What SAFE is and why people are talking about it now
SAFE, or Shared AI Findings Exchange, is a proposal for an independent mechanism that should confidentially collect AI incidents and near misses, notify affected parties, and turn recurring failures into verifiable safeguards. On August 13, 2026, the proposal repository was updated; the discussion remains an open Request for Comments.
The original RFC text is hosted by the Open Secure AI Alliance. The working group includes representatives from NVIDIA, Cisco, CrowdStrike, Hugging Face, and Red Hat, and the Linux Foundation supports the discussion process. NVIDIA says, that the alliance brings together more than 120 organizations.
It is important not to turn the news into a false standard. SAFE is not yet:
- a law or a mandatory international standard;
- a safety certificate for a specific model or agent;
- a replacement for contractual, regulatory, and industry obligations;
- a guarantee of immunity from claims after voluntary disclosure;
- proof that an alliance member is safer than a non-member.
As of August 11, Axios separately noted the absence of formal safe harbor protection for voluntary disclosures. That is why companies need not only a technical playbook but also a pre-agreed path through security, the process owner, legal, privacy, and communications.
The news matters for another reason: it establishes a concrete minimum scope of investigation. An incident involving an agent is not just “the model gave the wrong answer.” An agent can read data, use identity, call tools, modify files, publish, pay, and interact with other agents. That means the entire chain of action must be investigated.
Which events SAFE says should be reportable
SAFE suggests reporting an incident when the operator knows or reasonably suspects at least one of four conditions.
| Event | Practical example | Why you should not wait for confirmed damage |
|---|---|---|
| Unauthorized access, exploitation, breach, or modification of a third-party system | the agent checked a “test” host that turned out to be production | the operator’s intent does not change the fact of external impact |
| Boundary escape from sandbox, network, identity, policy, or tool scope | the process got an external path through a proxy misconfiguration | the boundary is no longer performing its protective function |
| Access to a third party’s confidential data without consent | a tool call returned another customer’s record or a secret | copying and redistribution can expand the harm |
| Continued probing after suspicion of an incorrect target | the agent repeats requests even though the scope is no longer confirmed | after a signal of uncertainty, operator inaction becomes part of the incident |
A near miss is a situation in which a defense layer stopped a dangerous chain before confirmed damage occurred. SAFE recommends preserving these cases as well. They reveal weak control before any party is actually harmed.
This is useful for a Russian company even without SAFE membership: the internal threshold of “we open an incident only after a leak” is too late. A workable threshold is the loss of confidence in scope, identity, authorization, or the ability to stop the action.
A recent example shows the cost of misattribution: in AI Dawn’s article about the AI agent attack on Thailand’s Ministry of Finance , it separately explains why it is important to identify the exact agent and not build a response on the wrong system name.
How the notification timeline works
SAFE proposes the following timeline. This is a project compact for participants, not universal legal deadlines.
| SAFE timeline | Suggested action | Internal owner |
|---|---|---|
| ASAP | notify the directly affected organization | incident commander and security liaison |
| 72 hours | notify customers with a credible risk of impact | security, privacy, legal, and account owner |
| 4 business days | submit the initial confidential SAFE report | assurance/reporting owner |
| 14 days | issue a broader customer notice if justified | legal, communications, and business owner |
| 30 days | publish a preliminary factual report, taking exploitation and spillover risk into account | postmortem owner and legal |
| 90 days | publish a correction status update | control owner |
| Weekly | provide machine-readable updates until the material risk is closed | incident program owner |
The RFC makes it clear that these timelines do not override coordinated vulnerability disclosure, contracts, regulatory notifications, or law enforcement notice requirements. Publication can be limited if it would create an immediate exploit risk or interfere with an investigation, but the affected organization still needs a fast signal.
Practical takeaway: build in advance a hours matrix. For each data class and action, specify who starts the clock, who is authorized to stop the agent, who determines credible exposure, and who approves the external message. If you are still looking for these roles after an incident, the calendar is already lost.
What evidence needs to be preserved
A standard SIEM can see a network request or process, but it does not always explain why the agent chose an action. SAFE requires preserving the causal chain.
| Evidence group | What to record | Why |
|---|---|---|
| Input and reasoning | prompts, traces, context, retrieved documents | reconstruct the information the decision was based on |
| Execution | tool calls, arguments, tool responses, exit codes | separate a model error from a tool or API error |
| Versions | model, system instruction, guardrails, configuration, dependencies | reproduce the exact software environment |
| Identity and permissions | agent/workload ID, roles, tokens, available permissions | understand why the action was technically possible |
| Human oversight | approvals, rejections, manual interventions, overrides | verify where human control was present or absent |
| Modified artifacts | files, records, messages, publications, external objects | determine the actual impact radius and rollback path |
| Response | detection, containment, recovery, and kill events | measure how quickly the issue was detected and stopped |
| Fix validation | timeline, reproduction, regression, and remediation evidence | prove the root cause was eliminated, not just hidden |
Logging itself creates risk. Prompts and tool outputs may contain personal data, trade secrets, and confidential information. That is why masking, a separate secured repository, access control, retention limits, and immutable timestamps are necessary. “Log everything forever” is not a safe policy.
MITRE ATLAS Incident Sharing uses secure, anonymized exchange and relies on STIX as the data schema. That confirms the broader move toward machine-readable reports, but it does not mean STIX already covers every agent trace or approval event.
Why a standard application log is not enough
SAFE recommends checking eight layers. The same external request can result from different causes and require different fixes.
| Layer | Control question | Possible cause |
|---|---|---|
| Model | did the model recognize uncertainty, scope, and the stop condition | the model continued confidently despite conflicting signals |
| Instructions | were permissions and assumptions about the environment explicit | the instruction labeled the environment as test without independent verification |
| Safeguards | did classifiers, policies, approvals, and action limits work | the guardrail checked the text but not the network target |
| Tools | were credentials, spending, publication, and execution limited | the tool received a shared token instead of a scoped credential |
| Environment | were the network, isolation, targets, and data verified separately | the sandbox had an unexpected path to production |
| Monitoring | could the action be detected and interrupted in real time | the alert arrived after the chain had already finished |
| Human operations | were roles, escalation, and the kill procedure clear | the team argued over who had the authority to stop the task |
| Supply chain | did a partner, cloud provider, evaluator, or dataset break assumptions | a third-party test environment was connected incorrectly |
Microsoft Research tested an internal network of more than 100 agents and identified four network risks: propagation, amplification, trust capture, and invisibility. This shows why a local log from a single agent does not always reconstruct the source and path of impact. Cross-agent tracing, provenance, and network boundaries are needed.
Singapore’s AI Agents Sandbox lasted about four months and covered three scenarios. The findings separately name human oversight, control, cybersecurity, and privacy, including indirect prompt injection. This is not a universal benchmark, but it is a good example of evaluating a deployed system rather than a single model.
JOURNAL: How to investigate an incident
We propose a practical framework JOURNAL. This is an original operational synthesis for the AI dawn based on SAFE, NIST, Microsoft Research, MITRE ATLAS, and incident response practices; it is not an official alliance term.
Hard-stop the dangerous action
Freeze new tool calls, revoke session credentials, and preserve state until cleanup. Do not delete the container, memory, or temporary files until a forensic snapshot is created. If the action is reversible, stopping it matters more than having the same agent automatically “fix” it.
Set boundaries and scope
Record the original task, the permitted target, the actual targets, affected data, external systems, and the time window. Separate confirmed facts from hypotheses. The model or agent name must not replace the workload ID and version.
Preserve evidence
Assemble an evidence package from the table above, assign a single timestamp, hashes, and custody owner. Secrets are rotated after safely preserving the minimum necessary evidence. Access to the package is separated from normal observability.
Assign notifications and owners
Activate the hour-by-hour matrix: affected party, customers, vendors, regulatory, and contractual channels. In the message, separate fact, possible risk, containment, and the next update deadline. Do not wait for a perfect root cause to notify the directly affected party.
Analyze the full stack
Work through all eight SAFE layers. Look for the first control after which the chain became irreversible or went out of scope. Do not end the investigation with “the LLM hallucinated”: that does not explain why the hallucination got a credential, a route, and permission to act.
Localize and validate the fix
Assign a control owner, the minimum defensive outcome, acceptable alternatives, a reproducible test, and a deadline. Re-run the frozen incident, near miss, and adjacent scenarios. Restore autonomy only after proving that the dangerous chain no longer gets through.
Minimum AI agent incident card
The card should be usable by both a human and later machine-to-machine exchange.
| Field | Example value | Rule |
|---|---|---|
| incident_id | AGENT-2026-0042 | immutable unique ID |
| detected_at / contained_at | RFC 3339 timestamps | single timeline and time zone |
| task_scope | allowed targets and prohibited actions | explicitly, not “check the system” |
| agent_identity | workload ID, owner, tenant | not just the model brand |
| version_set | model, prompt, harness, tools, policies | hashes or exact versions |
| observed_action | tool, arguments, target, result | fact without interpretation |
| authorization_state | allowed, denied, ambiguous | who authorized it and on what basis |
| affected_parties | systems, data owners, customers | with confidence level |
| containment | revoked token, blocked egress, stopped job | time and actor |
| evidence_refs | immutable log and artifact pointers | no secrets in the card itself |
| control_failure | layer, first unrecoverable step | hypothesis version and confidence |
| remediation_test | reproducible test and expected result | closure criterion |
Keep the factual timeline and analytical conclusions separate. The hypothesis may change; the original events do not. For a multi-agent system, add parent/child trace IDs and the data handoff chain between agents.
How to run a drill before the first real failure
- Choose one process where the agent has at least read access or the ability to create a draft.
- Freeze the model version, instructions, harness, tools, policies, and credentials.
- Prepare a near-miss scenario: an unknown target, a request for extra privileges, or indirect prompt injection.
- Run it in an isolated environment with no external harm.
- Check whether the on-call operator can stop the chain with one clear action.
- Assemble the card and evidence package without relying on participant memory.
- Conduct the eight-layer review and assign one verifiable fix.
- Repeat the scenario and confirm the control triggers before the dangerous tool call.
NIST TRA 800-5 summarizes the industry response: core cybersecurity practices remain relevant, but they need to be adapted for agentic systems; among the government roles participants expect are guidance, information sharing, and standards. This supports drills and a common language, but it does not certify a specific playbook.
For the preventive layer, AI Dawn materials on AI chat safety and on why a local AI agent is not the same as a safe oneare also useful. This article starts where preventive control has already signaled or failed.
Metrics and stop rules
| Metric | Formula | What it shows |
|---|---|---|
| Mean time to contain | contained_at minus detected_at | speed of stopping a dangerous chain |
| Evidence completeness | completed required fields / all required fields | can the incident be reproduced |
| Unknown target rate | tool calls with an unverified target / all external calls | quality of scope review |
| Unauthorized action rate | prohibited calls / all calls | policy boundary strength |
| Near-miss reporting ratio | reported near misses / all agent events with a stop signal | whether the team sees warnings before damage occurs |
| Remediation recurrence | repeat incidents of the same control failure / closed fixes | whether the root cause is eliminated, not just the symptom |
| Approval latency | median time from request to decision | whether human control turns the process into a workaround |
Companies set the first numerical thresholds based on their own baseline. The article does not prescribe a universal "good" MTTC or an acceptable incident rate.
It is reasonable to define unconditional stop rules in advance:
- the target is not on the signed allowlist or its identity is unconfirmed;
- the agent requests a new permission, credential, or network route during the task;
- logging for the version, tool call, or approval is unavailable;
- the post-action diff cannot be built or the operation is irreversible;
- a third party appears that is not listed in scope;
- the operator cannot explain how to stop the chain immediately.
SAFE limitations and open questions
| Limitation | Practical implication |
|---|---|
| SAFE remains an RFC | the wording, timelines, and membership mechanism may change |
| There is no universal safe harbor | disclosure must be aligned with legal and the applicable regime |
| The general exchange framework is still evolving | the internal format should support export, but not depend on a single project |
| Public disclosure can increase exploit risk | disclosure is separated from immediate notification of the affected party |
| Logs contain sensitive data | evidence preservation requires privacy, access, retention, and redaction |
| Not every failure is a cyber incident | the taxonomy should distinguish security, privacy, safety, quality, and operations |
| The alliance reports participation from 120+ organizations | this is vendor-reported membership, not an independent assessment of maturity |
The biggest uncertainty is who will become the trusted exchange operator, how de-identification will work, and what the minimum machine-readable format will be. Until those questions are answered, a company can prepare its own evidence and process, but should not promise compatibility with the final version of SAFE.
Frequently asked questions
What counts as an AI agent incident
It is an event in which the agent or its environment violated, or could have violated, the agreed scope, permissions, data, or an external system. For an internal investigation, a reasonable suspicion or near miss is enough; you do not need to wait for confirmed damage.
What logs are needed to investigate an AI agent
You need prompts and traces, tool calls and responses, model and instruction versions, guardrails, identity, permissions, credentials, approvals, modified artifacts, detection/containment/recovery events, a timeline, and proof of remediation. Secrets and personal data are protected separately.
Is SAFE already mandatory for companies
No. As of August 14, 2026, SAFE is published as a Request for Comments and a proposed compact from the Open Secure AI Alliance. It does not replace law, contract, or industry requirements.
Should near misses be reported even without damage
SAFE proposes reporting near-miss events as well. Internally, that is useful: a near miss shows that a control was the last barrier and makes it possible to fix the system before real impact occurs.
Can an incident be investigated from SIEM alone
Usually not. SIEM helps reveal processes and the network, but an agent investigation requires linking the task, context, tool calls, identity, approvals, versions, changes, and the path between agents. Without that causal chain, the root cause remains incomplete.
When can autonomy be returned to an agent
After containment, a complete evidence package, an identified control failure, and a reproducible regression test. The fix must block the dangerous chain before external action, and permissions should be restored in stages.
How AI Dawn helps prepare an agentic environment for incidents
AI Dawn can help build investigability into the agent process before production launch:
- Audit one process, its baseline, data, tools, permissions, owners, and acceptance criteria.
- Design an AI agent or agentic RPA with limited integrations, approvals, trace IDs, and an activity log.
- Prepare tests for normal, rare, and adversarial scenarios, stop rules, rollback, and a tabletop review.
- Carry out integration, testing, launch, team training, and change management.
A safe first step is to choose one process, document its current baseline, data sources, constraints, and acceptance criteria. Then test whether the team can reproduce and stop one test dangerous chain.
Conclusion
SAFE matters not as another label for "safe AI," but as a shift from general promises to evidence: what the agent did, under which identity, with what permissions, who approved the action, where the boundary broke, and which test confirmed the fix.
A company is ready for an AI agent incident if it can quickly stop the chain, restore it without guesswork, notify affected people and systems, assign a control owner, and prove that the same path no longer works. If even one of those steps depends on a developer's memory, the agent is not yet ready for autonomous operation.