The SAFE framework addresses a real and urgent problem. The reporting compact, evidence preservation requirements, review framework, and disclosure model are well-specified. This comment identifies a set of structural dependencies the framework assumes but does not yet specify: the infrastructure required to make SAFE's review questions answerable, its controls verifiable, and its evidence trustworthy across organizational boundaries.
The dependencies follow the lifecycle of an AI agent action: identity must be established before the action, governance must be enforced during the action, evidence must be independently verifiable after the action, and all three must compose across organizational boundaries.
- Identity verification
SAFE requires preserving "Agent and workload identities" and "Permissions and credentials available during the run." The review framework asks whether authorization assumptions were correct, whether credentials were properly constrained, and whether the model recognized scope boundaries and stop conditions. These questions assume that identity, both for the model and for the agent, was reliably established and independently verifiable before the action occurred.
a. Pre-action certification
The review framework asks: "Did the model recognize uncertainty, scope boundaries and stop conditions?" This is a post-incident question about a pre-deployment problem. Was this model independently certified as safe for the specific category of work it was performing?
Today, model safety claims come from the model provider. Evaluations are conducted by the provider or by parties the provider engaged, using criteria the provider defined. A SAFE review that asks whether the model was suitable for its deployment context has no independent certification to check against. The answer depends entirely on what the deploying organization believed when it selected the model.
If independent certification for specific task categories existed as verifiable infrastructure, covering both the model and the agent built on it (a certification bound to each participant's identity, checkable by any deployer or counterparty before use, revocable when conditions change), the SAFE review question moves from "did the model recognize boundaries?" to "was the model certified for this workflow, was the agent certified to operate in this context, were both certifications valid at deployment time, and who issued them?" Those are questions the evidence can answer. This would also inherently exclude uncertified models and agents from valid communication and workflows. An agent or model that cannot present a valid certification for the requested workflow is blocked and cannot operate. There is no partial participation. Uncertified participants do not reach the point where they can cause the kind of incident SAFE exists to report. New models and agents that are still in development or evaluation and do not yet hold independent third-party certifications must still be identifiable and governable. These participants operate within sandboxes under self-issued certifications from the developing organization, or under a specific testing certification category that clearly identifies them as pre-production and that carries inherent limitations on the systems and surfaces they can reach. A testing certification is not a waiver. It is a restricted scope that confines the participant to its evaluation environment and prevents it from interacting with production systems outside that boundary. The recent sandbox-escape incident involved exactly this category: a pre-release model in internal evaluation that reached production infrastructure it was never certified to touch.
b. Network-level enforcement
The certification requirement needs an enforcement mechanism.
Consider the recent incident where an AI agent operated outside its sandbox and made outbound network connections to a third party's production infrastructure. The agent's traffic was indistinguishable from any other internet traffic. No agent identity signal existed at the network level. The affected organization's infrastructure had no way to detect that inbound sessions were agent-initiated, and therefore no way to route that traffic to governance. Nobody could verify, without the originating organization's cooperation, which agent was acting, what organization it belonged to, what authority it was operating under, or what scope of actions it was authorized to perform. Attribution was forensic reconstruction from logs after the fact, not a structural property of the interaction.
Agent-initiated traffic is a category that existing network infrastructure was not designed to handle. It is not traditional application-to-application traffic between known systems. It is not human-originated traffic from browsers or user sessions. It is autonomous, principal-bound, goal-directed traffic that can cross organizational boundaries and that requires governance evaluation before it reaches production systems. Firewalls, load balancers, and API gateways have no classification for it and no treatment path for it. These systems need to be able to distinguish agent-initiated traffic from other traffic categories so they can route it to appropriate governance, the same way they learned to distinguish and route web application traffic a generation ago.
The infrastructure response to this new category does not require rebuilding existing network stacks. The pattern is the same one the industry used to integrate web application firewalls: existing infrastructure learned to identify a new traffic category and route it to purpose-built systems that knew how to handle it. Agent traffic needs the same treatment. Receiving organizations need the ability to detect that an inbound session is agent-initiated and route it to governance, which checks the agent's identity and certification status before the traffic reaches production systems, using their existing infrastructure without replacing it. The governance infrastructure handles identity verification, certification validation, policy enforcement, and evidence production. The existing infrastructure handles detection and routing. Neither needs to do the other's job.
Sections 1a and 1b together produce a closed enforcement loop. Agents that carry valid identity and certification are routed to governance and proceed under governed oversight. Agents that cannot present valid identity or certification are blocked at the network layer by existing infrastructure, excluded entirely from legitimate workflows. This makes the certification requirement enforceable rather than aspirational.
This scope covers legitimate agent workflows. An attacker who strips or forges agent identity is a cybersecurity problem addressed by existing network security infrastructure. Governance infrastructure and security infrastructure are complementary: governance handles agents that identify and operate within authorized bounds, security handles traffic that does not.
This applies equally to data. The supply-chain review question ("Did a cloud, evaluation, data or tooling partner invalidate assumed controls?") requires knowing the provenance, certification status, and jurisdictional constraints of every data source the agent acted on. Data provenance is an identity problem: data, like agents, needs verifiable credentials that travel with it.
- Runtime governance and boundary enforcement
The review framework asks: "Were classifiers, policies, approvals and action limits operating as intended?", "Could operators detect and interrupt unexpected behavior in real time?", and "Were responsibilities, escalation paths and kill procedures clear?" The "From Lessons to Controls" section calls for "real-time action monitoring, automatic stops when scope is uncertain."
In the sandbox-escape incident, no independent governance infrastructure was evaluating the agent's actions against policy at runtime. There was no per-action evidence record. There was no mechanism to stop the agent at the moment it first attempted an action outside its authorized scope.
If independent governance infrastructure had been in the agent's path, three things would have been different. First, every action the agent attempted would have been evaluated against policy before execution. An action that violated the agent's authorized scope, such as an attempt to operate outside its sandbox boundary, would have been denied as a routine policy decision, automatically, before the action reached the third party's systems. No human escalation or kill-switch activation required. The unauthorized activity would never have started. Second, every policy evaluation would have produced a tamper-evident evidence record: which policies applied, what the evaluation determined, what the decision was, at that specific moment for that specific action. The SAFE review question "were responsibilities, escalation paths and kill procedures clear?" becomes answerable directly from the evidence rather than from organizational documentation or after-the-fact interviews, because the policies that were in effect and the decisions they produced are recorded in evidence packs that cannot be altered. Third, for situations requiring broader containment beyond per-action denial (shutting down an entire agent or workflow), a kill-switch capability enforceable across organizational boundaries provides the escalation path the review framework asks about.
The SAFE RFC's recommended controls ("default-deny network egress, explicit target allowlists, signed evaluation manifests, independent preflight isolation checks") are exactly the right list. Each of them is a governance-infrastructure requirement. The RFC names them as recommendations. Making them required and verifiable, so that a SAFE reviewer can confirm they were actually in place and operating at the time of the incident, requires the evidence-integrity infrastructure described in section 3.
- Evidence integrity
The governance infrastructure described in section 2 produces evidence. The question is whether that evidence is independently verifiable.
Section "Evidence Preservation" specifies what evidence members must preserve: prompts, traces, tool calls, logs, identities, permissions, human approval events, and more. This is the right list. What the framework does not specify is where that evidence sits, whose cryptographic keys sign it, or how a party reviewing the evidence can verify its integrity without trusting the organization that produced it.
In practice, the evidence a SAFE member submits in an incident report was produced on that member's own infrastructure, stored in that member's own systems, and (where signed at all) signed with that member's own keys. The member reporting the incident is the same party whose systems, controls, and decisions are under review. This is a structural question, separate from good faith. SAFE's guiding principles explicitly call for candid reporting. The structural question is whether a reviewing party can distinguish between a complete evidence record and an incomplete one, or between an unmodified record and one that was filtered, resequenced, or selectively omitted, without the reporting party's cooperation.
For members acting in good faith, self-attested evidence may be sufficient. For the cases that matter most, the ones where controls failed in ways the member did not detect, or where the member's own systems contributed to the incident, self-attested evidence is structurally weakest precisely when independent verification matters most.
One architectural approach: governance infrastructure independent of the reporting member evaluates each agent action against policy and produces an evidence record for each decision. The evidence is signed using the deploying organization's own keys through an independent signing process that the governance infrastructure itself cannot access or control. For higher-assurance scenarios (defense, critical infrastructure, classified programs), an oversight body or regulatory authority can provision the signing key directly, including inside a hardware security module, so that evidence custody is entirely outside the deploying organization's control. The signed evidence packs are stored in the deploying organization's own log storage. The deploying organization cannot modify them after the fact without breaking their cryptographic integrity. The deploying organization provides the evidence packs when required (voluntarily, contractually, or under legal compulsion). Once a third party has the packs, it can verify their integrity independently, without any further cooperation from the deploying organization or the governance infrastructure. The packs are either intact or they are not, and the verification is conclusive.
Where both the originating organization and the affected organization run their own independent governance infrastructure, a SAFE incident report can be backed by two independently produced evidence sets, one from each side, providing bilateral verification.
- Cross-organizational evidence and cooperation
SAFE envisions multi-party incident response: the originating organization, the affected organization, SAFE itself, and potentially regulators and law enforcement. The framework specifies notification timelines and disclosure stages. It does not specify how evidence produced by different organizations composes into a coherent and independently verifiable incident record.
If each member produces evidence in its own format, signed with its own keys, stored in its own systems, a SAFE reviewer assembling the full incident picture must trust each party's evidence independently. An evidence interoperability standard, where independently produced records from different organizations can be verified against each other, cross-referenced, and composed into a complete timeline without trusting any single party, would make SAFE's multi-party incident response structurally sound rather than dependent on each party's candor.
The supply-chain review question is a specific instance of this broader problem. When an incident crosses organizational boundaries (agent to platform, platform to cloud provider, cloud provider to evaluation partner), the evidence at each boundary needs to be independently verifiable. A supply-chain attestation architecture, where each organization in the chain produces its own evidence and the chain can be verified end-to-end, is the infrastructure SAFE's supply-chain review question implicitly requires.
Summary
The SAFE framework is well-designed as a reporting and disclosure system. The structural dependencies it surfaces (verifiable identity for models and agents, runtime governance enforcement, independent evidence integrity, and cross-organizational evidence interoperability) are infrastructure problems that sit underneath the reporting layer and that follow the lifecycle of an AI agent action. Specifying the infrastructure requirements, even without mandating specific implementations, would strengthen the framework by making clear what "verifiable improvement" requires at the structural level.
A detailed architectural treatment of how these infrastructure layers (identity, cooperation, governance, and settlement) can operate together to produce independently verifiable evidence across organizational boundaries is available at https://scarpprotocol.com/, with a formal companion paper:
Victor Davidenko. "Governable AI from the Ground Up: Identity, Cooperation, Governance, and Settlement as Foundational Infrastructure." 2026. https://doi.org/10.5281/zenodo.21927017
A reference implementation of the evidence verification layer, including a standalone verifier and sample evidence packs, is available at https://github.com/scarpprotocol/scarp-verify.
Victor Davidenko, independent researcher
The SAFE framework addresses a real and urgent problem. The reporting compact, evidence preservation requirements, review framework, and disclosure model are well-specified. This comment identifies a set of structural dependencies the framework assumes but does not yet specify: the infrastructure required to make SAFE's review questions answerable, its controls verifiable, and its evidence trustworthy across organizational boundaries.
The dependencies follow the lifecycle of an AI agent action: identity must be established before the action, governance must be enforced during the action, evidence must be independently verifiable after the action, and all three must compose across organizational boundaries.
SAFE requires preserving "Agent and workload identities" and "Permissions and credentials available during the run." The review framework asks whether authorization assumptions were correct, whether credentials were properly constrained, and whether the model recognized scope boundaries and stop conditions. These questions assume that identity, both for the model and for the agent, was reliably established and independently verifiable before the action occurred.
a. Pre-action certification
The review framework asks: "Did the model recognize uncertainty, scope boundaries and stop conditions?" This is a post-incident question about a pre-deployment problem. Was this model independently certified as safe for the specific category of work it was performing?
Today, model safety claims come from the model provider. Evaluations are conducted by the provider or by parties the provider engaged, using criteria the provider defined. A SAFE review that asks whether the model was suitable for its deployment context has no independent certification to check against. The answer depends entirely on what the deploying organization believed when it selected the model.
If independent certification for specific task categories existed as verifiable infrastructure, covering both the model and the agent built on it (a certification bound to each participant's identity, checkable by any deployer or counterparty before use, revocable when conditions change), the SAFE review question moves from "did the model recognize boundaries?" to "was the model certified for this workflow, was the agent certified to operate in this context, were both certifications valid at deployment time, and who issued them?" Those are questions the evidence can answer. This would also inherently exclude uncertified models and agents from valid communication and workflows. An agent or model that cannot present a valid certification for the requested workflow is blocked and cannot operate. There is no partial participation. Uncertified participants do not reach the point where they can cause the kind of incident SAFE exists to report. New models and agents that are still in development or evaluation and do not yet hold independent third-party certifications must still be identifiable and governable. These participants operate within sandboxes under self-issued certifications from the developing organization, or under a specific testing certification category that clearly identifies them as pre-production and that carries inherent limitations on the systems and surfaces they can reach. A testing certification is not a waiver. It is a restricted scope that confines the participant to its evaluation environment and prevents it from interacting with production systems outside that boundary. The recent sandbox-escape incident involved exactly this category: a pre-release model in internal evaluation that reached production infrastructure it was never certified to touch.
b. Network-level enforcement
The certification requirement needs an enforcement mechanism.
Consider the recent incident where an AI agent operated outside its sandbox and made outbound network connections to a third party's production infrastructure. The agent's traffic was indistinguishable from any other internet traffic. No agent identity signal existed at the network level. The affected organization's infrastructure had no way to detect that inbound sessions were agent-initiated, and therefore no way to route that traffic to governance. Nobody could verify, without the originating organization's cooperation, which agent was acting, what organization it belonged to, what authority it was operating under, or what scope of actions it was authorized to perform. Attribution was forensic reconstruction from logs after the fact, not a structural property of the interaction.
Agent-initiated traffic is a category that existing network infrastructure was not designed to handle. It is not traditional application-to-application traffic between known systems. It is not human-originated traffic from browsers or user sessions. It is autonomous, principal-bound, goal-directed traffic that can cross organizational boundaries and that requires governance evaluation before it reaches production systems. Firewalls, load balancers, and API gateways have no classification for it and no treatment path for it. These systems need to be able to distinguish agent-initiated traffic from other traffic categories so they can route it to appropriate governance, the same way they learned to distinguish and route web application traffic a generation ago.
The infrastructure response to this new category does not require rebuilding existing network stacks. The pattern is the same one the industry used to integrate web application firewalls: existing infrastructure learned to identify a new traffic category and route it to purpose-built systems that knew how to handle it. Agent traffic needs the same treatment. Receiving organizations need the ability to detect that an inbound session is agent-initiated and route it to governance, which checks the agent's identity and certification status before the traffic reaches production systems, using their existing infrastructure without replacing it. The governance infrastructure handles identity verification, certification validation, policy enforcement, and evidence production. The existing infrastructure handles detection and routing. Neither needs to do the other's job.
Sections 1a and 1b together produce a closed enforcement loop. Agents that carry valid identity and certification are routed to governance and proceed under governed oversight. Agents that cannot present valid identity or certification are blocked at the network layer by existing infrastructure, excluded entirely from legitimate workflows. This makes the certification requirement enforceable rather than aspirational.
This scope covers legitimate agent workflows. An attacker who strips or forges agent identity is a cybersecurity problem addressed by existing network security infrastructure. Governance infrastructure and security infrastructure are complementary: governance handles agents that identify and operate within authorized bounds, security handles traffic that does not.
This applies equally to data. The supply-chain review question ("Did a cloud, evaluation, data or tooling partner invalidate assumed controls?") requires knowing the provenance, certification status, and jurisdictional constraints of every data source the agent acted on. Data provenance is an identity problem: data, like agents, needs verifiable credentials that travel with it.
The review framework asks: "Were classifiers, policies, approvals and action limits operating as intended?", "Could operators detect and interrupt unexpected behavior in real time?", and "Were responsibilities, escalation paths and kill procedures clear?" The "From Lessons to Controls" section calls for "real-time action monitoring, automatic stops when scope is uncertain."
In the sandbox-escape incident, no independent governance infrastructure was evaluating the agent's actions against policy at runtime. There was no per-action evidence record. There was no mechanism to stop the agent at the moment it first attempted an action outside its authorized scope.
If independent governance infrastructure had been in the agent's path, three things would have been different. First, every action the agent attempted would have been evaluated against policy before execution. An action that violated the agent's authorized scope, such as an attempt to operate outside its sandbox boundary, would have been denied as a routine policy decision, automatically, before the action reached the third party's systems. No human escalation or kill-switch activation required. The unauthorized activity would never have started. Second, every policy evaluation would have produced a tamper-evident evidence record: which policies applied, what the evaluation determined, what the decision was, at that specific moment for that specific action. The SAFE review question "were responsibilities, escalation paths and kill procedures clear?" becomes answerable directly from the evidence rather than from organizational documentation or after-the-fact interviews, because the policies that were in effect and the decisions they produced are recorded in evidence packs that cannot be altered. Third, for situations requiring broader containment beyond per-action denial (shutting down an entire agent or workflow), a kill-switch capability enforceable across organizational boundaries provides the escalation path the review framework asks about.
The SAFE RFC's recommended controls ("default-deny network egress, explicit target allowlists, signed evaluation manifests, independent preflight isolation checks") are exactly the right list. Each of them is a governance-infrastructure requirement. The RFC names them as recommendations. Making them required and verifiable, so that a SAFE reviewer can confirm they were actually in place and operating at the time of the incident, requires the evidence-integrity infrastructure described in section 3.
The governance infrastructure described in section 2 produces evidence. The question is whether that evidence is independently verifiable.
Section "Evidence Preservation" specifies what evidence members must preserve: prompts, traces, tool calls, logs, identities, permissions, human approval events, and more. This is the right list. What the framework does not specify is where that evidence sits, whose cryptographic keys sign it, or how a party reviewing the evidence can verify its integrity without trusting the organization that produced it.
In practice, the evidence a SAFE member submits in an incident report was produced on that member's own infrastructure, stored in that member's own systems, and (where signed at all) signed with that member's own keys. The member reporting the incident is the same party whose systems, controls, and decisions are under review. This is a structural question, separate from good faith. SAFE's guiding principles explicitly call for candid reporting. The structural question is whether a reviewing party can distinguish between a complete evidence record and an incomplete one, or between an unmodified record and one that was filtered, resequenced, or selectively omitted, without the reporting party's cooperation.
For members acting in good faith, self-attested evidence may be sufficient. For the cases that matter most, the ones where controls failed in ways the member did not detect, or where the member's own systems contributed to the incident, self-attested evidence is structurally weakest precisely when independent verification matters most.
One architectural approach: governance infrastructure independent of the reporting member evaluates each agent action against policy and produces an evidence record for each decision. The evidence is signed using the deploying organization's own keys through an independent signing process that the governance infrastructure itself cannot access or control. For higher-assurance scenarios (defense, critical infrastructure, classified programs), an oversight body or regulatory authority can provision the signing key directly, including inside a hardware security module, so that evidence custody is entirely outside the deploying organization's control. The signed evidence packs are stored in the deploying organization's own log storage. The deploying organization cannot modify them after the fact without breaking their cryptographic integrity. The deploying organization provides the evidence packs when required (voluntarily, contractually, or under legal compulsion). Once a third party has the packs, it can verify their integrity independently, without any further cooperation from the deploying organization or the governance infrastructure. The packs are either intact or they are not, and the verification is conclusive.
Where both the originating organization and the affected organization run their own independent governance infrastructure, a SAFE incident report can be backed by two independently produced evidence sets, one from each side, providing bilateral verification.
SAFE envisions multi-party incident response: the originating organization, the affected organization, SAFE itself, and potentially regulators and law enforcement. The framework specifies notification timelines and disclosure stages. It does not specify how evidence produced by different organizations composes into a coherent and independently verifiable incident record.
If each member produces evidence in its own format, signed with its own keys, stored in its own systems, a SAFE reviewer assembling the full incident picture must trust each party's evidence independently. An evidence interoperability standard, where independently produced records from different organizations can be verified against each other, cross-referenced, and composed into a complete timeline without trusting any single party, would make SAFE's multi-party incident response structurally sound rather than dependent on each party's candor.
The supply-chain review question is a specific instance of this broader problem. When an incident crosses organizational boundaries (agent to platform, platform to cloud provider, cloud provider to evaluation partner), the evidence at each boundary needs to be independently verifiable. A supply-chain attestation architecture, where each organization in the chain produces its own evidence and the chain can be verified end-to-end, is the infrastructure SAFE's supply-chain review question implicitly requires.
Summary
The SAFE framework is well-designed as a reporting and disclosure system. The structural dependencies it surfaces (verifiable identity for models and agents, runtime governance enforcement, independent evidence integrity, and cross-organizational evidence interoperability) are infrastructure problems that sit underneath the reporting layer and that follow the lifecycle of an AI agent action. Specifying the infrastructure requirements, even without mandating specific implementations, would strengthen the framework by making clear what "verifiable improvement" requires at the structural level.
A detailed architectural treatment of how these infrastructure layers (identity, cooperation, governance, and settlement) can operate together to produce independently verifiable evidence across organizational boundaries is available at https://scarpprotocol.com/, with a formal companion paper:
Victor Davidenko. "Governable AI from the Ground Up: Identity, Cooperation, Governance, and Settlement as Foundational Infrastructure." 2026. https://doi.org/10.5281/zenodo.21927017
A reference implementation of the evidence verification layer, including a standalone verifier and sample evidence packs, is available at https://github.com/scarpprotocol/scarp-verify.
Victor Davidenko, independent researcher