The SAFE framework's Evidence Preservation section requires preserving "Agent and workload identities" and "Permissions and credentials available during the run." The review framework asks whether authorization assumptions were correct and whether credentials were properly constrained. These requirements assume that a reliable identity infrastructure exists for every type of actor involved in an AI agent workflow.
No existing identity infrastructure meets this requirement across the full range of actors and workflows that SAFE incidents can involve.
The actor-type problem
An AI agent workflow involves multiple actor types: the agent itself, the model or models it uses, the tools it invokes, the data sources it accesses, the AI providers whose inference services the agent calls, and in multi-agent scenarios, other agents it communicates and cooperates with. Beyond software agents, the same identity requirements extend to every autonomous or semi-autonomous participant in a workflow: robotic systems operating in warehouses or on manufacturing floors, autonomous vehicles making real-time navigation decisions, IoT sensors feeding data into agent decision chains, and edge devices executing actions in physical environments. Each of these actors can independently contribute to an incident. A SAFE reviewer asking "what went wrong" needs to verify the identity, certification status, and authorized scope of every actor in the chain.
Each actor type has its own identity characteristics. Every entity in the workflow chain requires verifiable identity, including tools. A tool's output enters the decision chain and affects downstream actions. If the tool is compromised, misconfigured, or substituted, the agent acts on unverified output. Whether an entity makes autonomous decisions or simply returns a result when invoked, its contribution is relied upon without independent human verification at the point of use. That makes its identity a governance requirement. The argument that some entities are "just tools" and do not need identity is the argument that some links in the chain do not need to be verified. In a SAFE incident review, every unverified link is a gap the reviewer cannot close. An IoT sensor produces a temperature reading that an agent uses to decide whether to shut down a manufacturing line. If the sensor is compromised, miscalibrated, or reporting from the wrong location, the agent makes a correct decision on false data. The sensor's identity and certification status determines whether its readings should be trusted as input to governance-relevant decisions. A robotic system receives instructions from an agent and translates them into physical actions with safety-critical consequences. It interprets, constrains, and executes. It has its own failure modes, its own safety certifications, and its own operational envelope that may conflict with what the agent requested. An autonomous vehicle makes thousands of independent decisions per second, communicates with infrastructure and other vehicles, and acts on sensor data from multiple sources, all without a human reviewing each decision. Data produced by one organization and consumed by an agent in another organization carries provenance, jurisdictional constraints, and classification properties that the consuming agent cannot independently verify unless the data itself carries verifiable identity. In every case, the entity's output or action enters the workflow as a trusted input that downstream agents act on. Any entity whose contribution is relied upon without independent human verification at the point of use requires verifiable identity. If it does not have one, a SAFE reviewer cannot determine whether the incident originated from a compromised, miscertified, or unauthorized participant anywhere in the chain. A software agent that persists across sessions and accumulates context, a sensor operating on a constrained compute budget, a vehicle making decisions under millisecond latency requirements, and an AI provider whose model certifications change over time each require different identity attribute profiles: different lifecycle properties, different certification categories, different authority models, different constraints on verification latency and computational overhead.
These certifications and classifications must be carried inside the identity credential itself, not in external policy systems or configuration databases consulted at verification time. Consider model certification. Governments are already moving toward certifying LLMs before they can be released for public use, to prevent bad actors from using uncertified models to cause harm. It is reasonable to expect that classified scenarios will require a specific class of LLMs certified to operate in those environments: models evaluated and approved by an independent authority for use in national security, critical infrastructure, or defense workflows. That certification must travel with the model's identity. If the certification lives in a separate policy system, one misconfigured policy rule or one stale policy database means a model certified only for consumer use is accepted into a classified workflow, or a model that lost its certification continues operating because the policy system was not updated. The consequences of that single configuration error are catastrophic in proportion to the classification level of the workflow. The same logic applies across every actor type. An open-source LLM with open weights, a commercial API-served model, and a government-certified model each carry different certification levels and different constraints on which workflows, data sources, and counterpart agents they are authorized to interact with. Those properties must be embedded in the identity credential as independently verifiable attributes, issued by the certifying authority and checkable by any counterparty at the point of interaction, without calling out to an external system that may be stale, misconfigured, or unavailable. The same requirement extends to agents (authorized workflow types and delegation constraints), data (provenance, jurisdiction, classification level), sensors (calibration certification, operational envelope), and every other participant. When the certification is inside the identity, verification is atomic: present the credential, check the attributes, accept or reject. When the certification is external, verification depends on the availability, freshness, and correctness of a separate system, and every dependency is a failure mode.
A single flat identity specification that defines one attribute set for all actor types will either be too narrow (covering software agents while leaving robotic systems and IoT sensors without adequate identity properties) or too generic (defining the lowest common denominator while losing the type-specific governance attributes that make the identity useful for a SAFE review). The identity framework needs a common credential infrastructure that supports type-specific attribute profiles, where the entity type is a first-class property of the identity, set at issuance and enforced at every interaction. An agent credential, a sensor credential, a vehicle credential, and a data-source credential share the same verification infrastructure and the same cryptographic trust model, while carrying different governance attributes appropriate to their type.
All of these actor types must be accounted for in the identity architecture from the beginning. An identity framework that launches covering software agents and models but defers robots, IoT sensors, autonomous vehicles, AI providers, and data sources to future versions will require protocol addendums when those actor types are eventually included. Those addendums disrupt implementations already built against the earlier specification, force versioning complexity on adopters, and create coverage gaps during the transition where incidents involving uncovered actor types cannot be fully reviewed. Standards that start narrow and widen incrementally impose real costs on every implementer each time the scope expands. Starting with the full range of actor types is cheaper than retrofitting.
Current identity systems were each designed for a specific scope, and none of them answers the questions a SAFE review asks.
X.509 certificates authenticate endpoints and bind a public key to a named identity. They do not carry governance scope, task-category certification, or behavioral constraints. A certificate tells you which agent you are talking to, not whether that agent is certified for the workflow it is performing.
SPIFFE/SPIRE provides workload identity within compute clusters. It is scoped to infrastructure orchestration, not to autonomous agents that persist beyond a single workload execution, operate across organizational boundaries, or carry their own authority.
OAuth 2.0 and OpenID Connect provide delegated authorization on behalf of a human principal. They assume a human who granted consent. Autonomous agents acting on their own authority, or delegating to other agents across organizations, fall outside this model.
API keys authenticate service-to-service calls. They carry no identity properties, no certification status, no governance constraints. They are shared secrets, not verifiable credentials.
SAML federates authentication across enterprise identity providers. It is session-based and human-centric. It does not support persistent agent identity, agent-to-agent verification, or governance-scope attributes that travel with the agent across federation boundaries.
Decentralized Identifiers (DIDs) and Verifiable Credentials (VCs) come closest in architecture: self-sovereign identifiers with independently issued, offline-verifiable claims. Three structural limitations remain for SAFE's requirements. Verification infrastructure is fragmented across DID methods (did:web, did:key, did:ion), with no universal verification path that both parties in a cross-organizational incident already operate. Revocation is not uniformly immediate: when a compromised agent must be decertified during an active incident, propagation must happen in seconds, and DID revocation mechanisms vary by method. Adoption is limited: every organization already operates certificate-based verification infrastructure as part of its standard network stack, while DID/VC requires new infrastructure before an actor's identity can be verified. Beyond these infrastructure gaps, the DID/VC ecosystem lacks a governance-aware credential profile for AI agents: standardized claims for task-category certification, workflow-type authorization, delegation-chain constraints, classification levels, and revocation tied to governance events rather than calendar expiry.
None of these systems was designed to answer the questions SAFE's review framework asks: was this specific model certified for this category of work? Was this data source authorized for use in this jurisdiction and workflow type? Was this agent permitted to delegate to that agent, and under what constraints?
These are identity questions that carry governance scope. The identity credential itself needs to encode what the actor is certified to do, what workflow types it is authorized to participate in, and what constraints govern its interactions with other actors. Authentication alone (proving the actor is who it claims to be) is necessary but insufficient. The identity must also carry verifiable, independently issued properties that a counterparty or reviewer can check without trusting the organization that deployed the actor.
Workflow-level identity requirements
Different workflow types impose different identity requirements. SAFE's scope includes all of them, and each type exposes a different gap in current identity infrastructure.
Agent-to-agent delegation. When one agent invokes another agent across an organizational boundary, the receiving agent needs to verify the calling agent's identity, its authority to request the specific action, and whether that authority was legitimately delegated from the original principal. In a multi-hop delegation chain (agent A delegates to agent B, which delegates to agent C), each hop must verify that authority has not escalated beyond what was originally granted. No current identity system provides delegation-chain verification with non-escalation semantics across organizational boundaries.
Multi-agent coordination. When multiple agents work toward a shared objective (research synthesis, distributed analysis, coordinated operations), each agent needs to verify that every other participating agent is certified for the relevant workflow type and operating under compatible governance constraints. An agent that lacks certification for the task, or that operates under governance policies incompatible with the coordination requirements, must be excluded before it can contribute. Current identity systems have no mechanism for agents to verify each other's governance scope as a precondition for cooperation.
Classified and restricted workflows. Workflows involving sensitive data, critical infrastructure, or restricted operations require identity credentials that encode clearance or certification levels. An agent certified for general commercial workflows must be structurally prevented from participating in a workflow requiring higher clearance, regardless of whether it has network access to the relevant systems. The identity credential must encode the restriction, and the governance infrastructure must enforce it at every interaction. Current identity systems do not carry classification-level attributes that other actors can verify and that governance infrastructure can enforce.
Data as an actor. The SAFE supply-chain review question ("Did a cloud, evaluation, data or tooling partner invalidate assumed controls?") treats data provenance as a review concern. Data sources in an AI agent workflow carry their own identity requirements: provenance (where did this data originate?), jurisdictional constraints (is this data authorized for use in this jurisdiction?), classification level (is this data cleared for this workflow type?), and freshness or validity period (is this data still current and authorized?). These are identity properties of the data itself, verifiable by any actor that consumes it. If data lacks verifiable identity credentials, a SAFE reviewer cannot answer the supply-chain review question from the evidence alone.
Model certification. The SAFE review framework asks whether the model recognized scope boundaries and stop conditions. A stronger infrastructure question is whether the model was independently certified for the specific category of work it was performing, and whether that certification was valid and verifiable at the time of the incident. Model certification is an identity property: the model's credential should carry its certification status, the certifying authority, the task categories it is certified for, and the conditions under which the certification can be revoked. Current identity systems do not support model-level certification credentials that governance infrastructure and counterparties can verify at runtime.
What this means for SAFE
The SAFE framework cannot fully answer its own review questions without identity infrastructure that covers all actor types (agents, models, tools, data) and encodes governance scope (what each actor is certified to do, under what constraints, in what workflow types) as verifiable, independently issued properties of the identity credential itself.
Specifying the identity requirements at the infrastructure level, even without mandating specific implementations, would clarify what "preserved identities" must actually contain for a SAFE review to be conclusive, and would surface the gap between what current identity systems provide and what SAFE's review questions require.
A detailed treatment of how identity, cooperation, governance, and settlement layers can provide this infrastructure is available at https://scarpprotocol.com/, with a companion paper at https://doi.org/10.5281/zenodo.21927017.
Victor Davidenko, independent researcher
The SAFE framework's Evidence Preservation section requires preserving "Agent and workload identities" and "Permissions and credentials available during the run." The review framework asks whether authorization assumptions were correct and whether credentials were properly constrained. These requirements assume that a reliable identity infrastructure exists for every type of actor involved in an AI agent workflow.
No existing identity infrastructure meets this requirement across the full range of actors and workflows that SAFE incidents can involve.
The actor-type problem
An AI agent workflow involves multiple actor types: the agent itself, the model or models it uses, the tools it invokes, the data sources it accesses, the AI providers whose inference services the agent calls, and in multi-agent scenarios, other agents it communicates and cooperates with. Beyond software agents, the same identity requirements extend to every autonomous or semi-autonomous participant in a workflow: robotic systems operating in warehouses or on manufacturing floors, autonomous vehicles making real-time navigation decisions, IoT sensors feeding data into agent decision chains, and edge devices executing actions in physical environments. Each of these actors can independently contribute to an incident. A SAFE reviewer asking "what went wrong" needs to verify the identity, certification status, and authorized scope of every actor in the chain.
Each actor type has its own identity characteristics. Every entity in the workflow chain requires verifiable identity, including tools. A tool's output enters the decision chain and affects downstream actions. If the tool is compromised, misconfigured, or substituted, the agent acts on unverified output. Whether an entity makes autonomous decisions or simply returns a result when invoked, its contribution is relied upon without independent human verification at the point of use. That makes its identity a governance requirement. The argument that some entities are "just tools" and do not need identity is the argument that some links in the chain do not need to be verified. In a SAFE incident review, every unverified link is a gap the reviewer cannot close. An IoT sensor produces a temperature reading that an agent uses to decide whether to shut down a manufacturing line. If the sensor is compromised, miscalibrated, or reporting from the wrong location, the agent makes a correct decision on false data. The sensor's identity and certification status determines whether its readings should be trusted as input to governance-relevant decisions. A robotic system receives instructions from an agent and translates them into physical actions with safety-critical consequences. It interprets, constrains, and executes. It has its own failure modes, its own safety certifications, and its own operational envelope that may conflict with what the agent requested. An autonomous vehicle makes thousands of independent decisions per second, communicates with infrastructure and other vehicles, and acts on sensor data from multiple sources, all without a human reviewing each decision. Data produced by one organization and consumed by an agent in another organization carries provenance, jurisdictional constraints, and classification properties that the consuming agent cannot independently verify unless the data itself carries verifiable identity. In every case, the entity's output or action enters the workflow as a trusted input that downstream agents act on. Any entity whose contribution is relied upon without independent human verification at the point of use requires verifiable identity. If it does not have one, a SAFE reviewer cannot determine whether the incident originated from a compromised, miscertified, or unauthorized participant anywhere in the chain. A software agent that persists across sessions and accumulates context, a sensor operating on a constrained compute budget, a vehicle making decisions under millisecond latency requirements, and an AI provider whose model certifications change over time each require different identity attribute profiles: different lifecycle properties, different certification categories, different authority models, different constraints on verification latency and computational overhead.
These certifications and classifications must be carried inside the identity credential itself, not in external policy systems or configuration databases consulted at verification time. Consider model certification. Governments are already moving toward certifying LLMs before they can be released for public use, to prevent bad actors from using uncertified models to cause harm. It is reasonable to expect that classified scenarios will require a specific class of LLMs certified to operate in those environments: models evaluated and approved by an independent authority for use in national security, critical infrastructure, or defense workflows. That certification must travel with the model's identity. If the certification lives in a separate policy system, one misconfigured policy rule or one stale policy database means a model certified only for consumer use is accepted into a classified workflow, or a model that lost its certification continues operating because the policy system was not updated. The consequences of that single configuration error are catastrophic in proportion to the classification level of the workflow. The same logic applies across every actor type. An open-source LLM with open weights, a commercial API-served model, and a government-certified model each carry different certification levels and different constraints on which workflows, data sources, and counterpart agents they are authorized to interact with. Those properties must be embedded in the identity credential as independently verifiable attributes, issued by the certifying authority and checkable by any counterparty at the point of interaction, without calling out to an external system that may be stale, misconfigured, or unavailable. The same requirement extends to agents (authorized workflow types and delegation constraints), data (provenance, jurisdiction, classification level), sensors (calibration certification, operational envelope), and every other participant. When the certification is inside the identity, verification is atomic: present the credential, check the attributes, accept or reject. When the certification is external, verification depends on the availability, freshness, and correctness of a separate system, and every dependency is a failure mode.
A single flat identity specification that defines one attribute set for all actor types will either be too narrow (covering software agents while leaving robotic systems and IoT sensors without adequate identity properties) or too generic (defining the lowest common denominator while losing the type-specific governance attributes that make the identity useful for a SAFE review). The identity framework needs a common credential infrastructure that supports type-specific attribute profiles, where the entity type is a first-class property of the identity, set at issuance and enforced at every interaction. An agent credential, a sensor credential, a vehicle credential, and a data-source credential share the same verification infrastructure and the same cryptographic trust model, while carrying different governance attributes appropriate to their type.
All of these actor types must be accounted for in the identity architecture from the beginning. An identity framework that launches covering software agents and models but defers robots, IoT sensors, autonomous vehicles, AI providers, and data sources to future versions will require protocol addendums when those actor types are eventually included. Those addendums disrupt implementations already built against the earlier specification, force versioning complexity on adopters, and create coverage gaps during the transition where incidents involving uncovered actor types cannot be fully reviewed. Standards that start narrow and widen incrementally impose real costs on every implementer each time the scope expands. Starting with the full range of actor types is cheaper than retrofitting.
Current identity systems were each designed for a specific scope, and none of them answers the questions a SAFE review asks.
X.509 certificates authenticate endpoints and bind a public key to a named identity. They do not carry governance scope, task-category certification, or behavioral constraints. A certificate tells you which agent you are talking to, not whether that agent is certified for the workflow it is performing.
SPIFFE/SPIRE provides workload identity within compute clusters. It is scoped to infrastructure orchestration, not to autonomous agents that persist beyond a single workload execution, operate across organizational boundaries, or carry their own authority.
OAuth 2.0 and OpenID Connect provide delegated authorization on behalf of a human principal. They assume a human who granted consent. Autonomous agents acting on their own authority, or delegating to other agents across organizations, fall outside this model.
API keys authenticate service-to-service calls. They carry no identity properties, no certification status, no governance constraints. They are shared secrets, not verifiable credentials.
SAML federates authentication across enterprise identity providers. It is session-based and human-centric. It does not support persistent agent identity, agent-to-agent verification, or governance-scope attributes that travel with the agent across federation boundaries.
Decentralized Identifiers (DIDs) and Verifiable Credentials (VCs) come closest in architecture: self-sovereign identifiers with independently issued, offline-verifiable claims. Three structural limitations remain for SAFE's requirements. Verification infrastructure is fragmented across DID methods (did:web, did:key, did:ion), with no universal verification path that both parties in a cross-organizational incident already operate. Revocation is not uniformly immediate: when a compromised agent must be decertified during an active incident, propagation must happen in seconds, and DID revocation mechanisms vary by method. Adoption is limited: every organization already operates certificate-based verification infrastructure as part of its standard network stack, while DID/VC requires new infrastructure before an actor's identity can be verified. Beyond these infrastructure gaps, the DID/VC ecosystem lacks a governance-aware credential profile for AI agents: standardized claims for task-category certification, workflow-type authorization, delegation-chain constraints, classification levels, and revocation tied to governance events rather than calendar expiry.
None of these systems was designed to answer the questions SAFE's review framework asks: was this specific model certified for this category of work? Was this data source authorized for use in this jurisdiction and workflow type? Was this agent permitted to delegate to that agent, and under what constraints?
These are identity questions that carry governance scope. The identity credential itself needs to encode what the actor is certified to do, what workflow types it is authorized to participate in, and what constraints govern its interactions with other actors. Authentication alone (proving the actor is who it claims to be) is necessary but insufficient. The identity must also carry verifiable, independently issued properties that a counterparty or reviewer can check without trusting the organization that deployed the actor.
Workflow-level identity requirements
Different workflow types impose different identity requirements. SAFE's scope includes all of them, and each type exposes a different gap in current identity infrastructure.
Agent-to-agent delegation. When one agent invokes another agent across an organizational boundary, the receiving agent needs to verify the calling agent's identity, its authority to request the specific action, and whether that authority was legitimately delegated from the original principal. In a multi-hop delegation chain (agent A delegates to agent B, which delegates to agent C), each hop must verify that authority has not escalated beyond what was originally granted. No current identity system provides delegation-chain verification with non-escalation semantics across organizational boundaries.
Multi-agent coordination. When multiple agents work toward a shared objective (research synthesis, distributed analysis, coordinated operations), each agent needs to verify that every other participating agent is certified for the relevant workflow type and operating under compatible governance constraints. An agent that lacks certification for the task, or that operates under governance policies incompatible with the coordination requirements, must be excluded before it can contribute. Current identity systems have no mechanism for agents to verify each other's governance scope as a precondition for cooperation.
Classified and restricted workflows. Workflows involving sensitive data, critical infrastructure, or restricted operations require identity credentials that encode clearance or certification levels. An agent certified for general commercial workflows must be structurally prevented from participating in a workflow requiring higher clearance, regardless of whether it has network access to the relevant systems. The identity credential must encode the restriction, and the governance infrastructure must enforce it at every interaction. Current identity systems do not carry classification-level attributes that other actors can verify and that governance infrastructure can enforce.
Data as an actor. The SAFE supply-chain review question ("Did a cloud, evaluation, data or tooling partner invalidate assumed controls?") treats data provenance as a review concern. Data sources in an AI agent workflow carry their own identity requirements: provenance (where did this data originate?), jurisdictional constraints (is this data authorized for use in this jurisdiction?), classification level (is this data cleared for this workflow type?), and freshness or validity period (is this data still current and authorized?). These are identity properties of the data itself, verifiable by any actor that consumes it. If data lacks verifiable identity credentials, a SAFE reviewer cannot answer the supply-chain review question from the evidence alone.
Model certification. The SAFE review framework asks whether the model recognized scope boundaries and stop conditions. A stronger infrastructure question is whether the model was independently certified for the specific category of work it was performing, and whether that certification was valid and verifiable at the time of the incident. Model certification is an identity property: the model's credential should carry its certification status, the certifying authority, the task categories it is certified for, and the conditions under which the certification can be revoked. Current identity systems do not support model-level certification credentials that governance infrastructure and counterparties can verify at runtime.
What this means for SAFE
The SAFE framework cannot fully answer its own review questions without identity infrastructure that covers all actor types (agents, models, tools, data) and encodes governance scope (what each actor is certified to do, under what constraints, in what workflow types) as verifiable, independently issued properties of the identity credential itself.
Specifying the identity requirements at the infrastructure level, even without mandating specific implementations, would clarify what "preserved identities" must actually contain for a SAFE review to be conclusive, and would surface the gap between what current identity systems provide and what SAFE's review questions require.
A detailed treatment of how identity, cooperation, governance, and settlement layers can provide this infrastructure is available at https://scarpprotocol.com/, with a companion paper at https://doi.org/10.5281/zenodo.21927017.
Victor Davidenko, independent researcher