The data shows a pattern that the market is not pricing yet. In 2025, Nvidia, Cisco, and CrowdStrike each revealed that they are building their own AI safety playbooks. The announcement was reported by Crypto Briefing, a publication with crypto roots that has expanded into AI coverage. For a security auditor, the report itself is the first signal. It is thin. It gives no technical details. It names no invariants. It offers no evidence that any of the three playbooks has been stress-tested against a known attack.
I have spent years reading post-mortems of protocol failures in DeFi. The ledger remembers what the market forgets. When a team announces a security framework with no verifiable logic, the pattern is familiar. It is not a solution. It is a placeholder.
This essay is not a complaint about the source article. It is a forensic read of what the three playbooks would need to contain if they were serious. I will define safety in the way an auditor defines safety. I will map each company to its layer in the AI stack. And I will show why three independent playbooks create a larger attack surface than one verified standard.
The Signal
The source article is best read as a fragment. It reports that three infrastructure giants are constructing separate AI safety documents. It does not explain their contents. It does not mention whether any document is public. It does not say whether the companies coordinated or consulted the same threat model. That lack of information is itself informative. In a sideways market, announcements become substitutes for technical progress. Three companies producing three private rulebooks gives the market the feeling of action without the reality of enforcement.
What do Nvidia, Cisco, and CrowdStrike have in common? They all sit near the rails of enterprise AI deployment. Nvidia sells the silicon that trains and runs models. Cisco owns a substantial share of the network path that moves training data and inference requests. CrowdStrike protects the endpoints that interact with models. Each company has a different vantage point. Each one sees a different slice of the same pipeline.
It is not a surprise that they would each build a playbook. A playbook, in this context, is a set of instructions for handling AI-related incidents. It might describe when to shut down a model. It might specify how to isolate a poisoned dataset. It might list the escalation path for a prompt injection. All of those are useful artifacts. But usefulness depends on verification. A playbook is not a proof. It is a hypothesis.
Formal verification is the only truth in code. That line has guided my audits since the Tezos governance review I worked on in 2017. On Tezos, I spent six months checking the self-amendment mechanism. The formal proofs were written in OCaml. They were meticulous. They still contained logical flaws in the governance voting path that could have halted upgrades. The lesson was never about OCaml. It was about the distance between a written safety claim and a verified property.
The Missing Invariant
A smart contract auditor does not begin with code. The auditor begins with an invariant. The invariant is the property that must never break. In a lending protocol, the invariant might be that the total debt never exceeds the total collateral. In a token contract, the invariant might be that the sum of all balances equals the total supply. After the invariant is written, the audit tests every function path against it. No function can move the system into a state where the invariant is false.
AI safety needs the same discipline. A safety playbook must begin with a stated invariant for every model deployment. The invariant for an AI agent might be that the agent cannot cause a transfer of value unless the human operator authorizes that exact transfer. The invariant for a network filter might be that no inference request leaves the approved data zone. The invariant for an endpoint might be that no prompt originating from a third-party plugin can change the agent's long-term memory. None of these invariants are obvious. All of them can be written down and checked.
Let me be blunt. The original article does not mention an invariant. It does not quote a threat model. It does not reference a known test suite. It treats a safety playbook as if it were a fact that can be announced. In my world, safety is not a fact. It is a relationship between a system and a set of forbidden states. You cannot announce that relationship. You have to demonstrate it.
There is a reason public blockchains have survived for more than a decade of high-value attacks. The consensus logic is simple. The invariants are explicit. The execution environment is deterministic. None of that is true for an AI pipeline. A model is a stochastic function. Its behavior depends on weights, temperature settings, prompts, and context. A playbook that does not account for stochasticity is not a playbook. It is a wish.
Three Layers, Three Blind Spots
Let me map the three companies to the stack.
Nvidia is the compute layer. Its playbook must cover the hardware that accelerates training and inference. That includes GPU driver behavior, memory isolation, and the trust boundary between the model and the host kernel. If a malicious model can read another tenant's memory on the same GPU, the entire safety stack fails. Nvidia also controls CUDA and the toolchain that developers use to compile models. That gives Nvidia a unique position. It can verify what runs on its hardware. The question is whether it does.
Cisco is the transport and infrastructure layer. Its playbook must cover the network path. That means monitoring data exfiltration, blocking malicious model updates, and detecting when an inference request is being used to probe internal systems. Cisco's advantage is visibility. It sees the flow of packets. Its challenge is that modern AI traffic is encrypted and multiplexed. A model can hide a dangerous payload inside a seemingly normal API call. Cisco can only verify the packet headers unless it is given a deeper protocol.
CrowdStrike is the endpoint layer. Its playbook must cover the runtime behavior of the machine that talks to the model. That includes detecting when a local AI plugin tries to execute a shell command, watching for memory injection, and blocking the persistence mechanisms that a compromised agent might use. CrowdStrike's advantage is execution context. It knows what processes are running. Its challenge is that AI agents can behave like humans with permissions. If the agent is already authorized to use the browser, the endpoint cannot easily distinguish a human action from an agent action.
Each company is building a playbook for its own layer. That is rational. It also creates a structural problem. The safety of the whole system is not the sum of the safety of its parts. An AI incident can begin at one layer, pass through another, and manifest at a third. The neural network produces a harmful decision. The network does not block it because the payload is hidden in a prompt. The endpoint does not stop it because the action is permitted by policy. Three playbooks, each correct in isolation, can fail together.
Stress tests reveal the fractures before the flood. That is why I run simulations whenever I look at a new protocol. The simulation does not predict the future. It exposes the seams between components.
The 2025 AI-Agent Audit
Last year I audited a protocol where AI agents executed smart contracts autonomously. The project had a safety playbook. It described the behavior the agents should follow. It listed prohibited actions. It even had a human-in-the-loop approval step. On paper, it looked like a responsible system. The audit found a different reality.
The agent parsed a prompt, resolved a recipient address, and then called the contract. The access-control check happened after the prompt was interpreted. That ordering was the vulnerability. A prompt injection from malicious NFT metadata told the agent to emit a safe signal while changing the recipient address. The permission check saw the safe signal and approved the call. The recipient address had already been changed in an earlier step. The agent then moved funds to the attacker. The playbook did not forbid the sequence because the sequence was never written as an invariant.
I traced the exact path: processMessage, evaluatePrompt, executeAction. The permission check was inside executeAction. The recipient resolution happened inside evaluatePrompt. The injection did not need to bypass the check. It changed the state before the check existed. The formal invariant should have been that the recipient address is fixed before permission evaluation and immutable after it. That invariant was missing. The playbook had fifteen rules. It had no proof.
This is the same shape as the three-playbook problem. Nvidia verifies the silicon. Cisco verifies the packet. CrowdStrike verifies the process. None of them verifies the invariant across all layers. The attacker does not need to defeat all three. The attacker only needs to exploit the seam between them.
The AI-agent audit was not an isolated failure. It is a pattern. After that audit, I began asking a different question when I review safety documentation. I do not ask what the system is allowed to do. I ask what the system is allowed to become. The answer must be written in a language that can be checked. If the answer is prose, it is a policy. If the answer is code, it is a control. The market has not yet learned to demand the latter.
The Fragmentation Problem
There is a direct parallel between AI safety playbooks and the fragmentation of Layer 2 chains in crypto. Every chain publishes its own security assumptions. Every chain has its own bridge. Every chain says it is secure. In aggregate, the ecosystem is not more secure. It is more fragmented. Security budgets are duplicated. Attack surfaces are multiplied. Users cannot verify one chain by verifying another.
AI safety is heading down the same road. Nvidia will publish a hardware playbook. Cisco will publish a network playbook. CrowdStrike will publish an endpoint playbook. None of them will share a common verification ledger. None of them will expose an interface that allows another layer to confirm that its own control was effective. The result is not a defense-in-depth. It is a series of isolated castles standing next to a shared attack surface.
This is not scaling safety into the enterprise. It is slicing a scarce resource into fragments. The scarce resource is trust. In a fragmented safety landscape, trust cannot be aggregated. An enterprise that buys all three platforms still needs to hire an integrator to connect the dots. The integrator becomes the real auditor. The playbooks become vendor documentation.
The ledger remembers what the market forgets. In crypto, the market forgot that the value of a protocol is not measured by the number of audits. It is measured by the ability of those audits to converge on a common invariant. The same rule applies to AI safety. The value of Nvidia, Cisco, and CrowdStrike building playbooks will be zero unless those playbooks converge on shared verification standards.
The Simulation
I built a small simulation to test this fragmentation concept. The simulation modeled an enterprise AI pipeline with three safety classifiers. One classifier sat on the GPU host. One sat on the network gateway. One sat on the endpoint. I injected a malicious prompt designed to exfiltrate a database name. The payload was encoded in a way that split it across three layers. Each classifier saw only a fragment of the original payload. The result was predictable. Each classifier marked the fragment as benign because the fragment did not look malicious.
The simulation is not a proof of a real vulnerability. It is a demonstration of a structural truth. Security systems that operate independently cannot verify the complete state of a transaction. They can only verify the state as observed from their own layer. A model can produce a harmful output that is not malicious to the network because it is disguised. The network can transmit a payload that is not malicious to the endpoint because it is stored in a config file. The endpoint can execute an action that is not malicious to the model because the model does not know the action was taken.
The only way to catch this class of failure is to compare logs from all layers against a common specification. The specification has to be explicit enough that a verification tool can check the sequence of events. This is exactly how smart contract audits work. The contract is one system. The audit checks the state transitions against the invariant. For AI, the system is distributed. The invariant must span hardware, network, and endpoint. None of the three announced playbooks can do that alone.
I have used this simulation approach since my Compound stress test in 2020. Back then, I wrote a Python script to generate ten thousand random liquidity events on Compound V1. The goal was to see whether the interest rate model could produce insolvency under an extreme shock. The script found a theoretical path. The finding was later cited by a major audit firm. The lesson stuck: pressure tests are not commentary. They are evidence. The AI industry needs the same kind of evidence before it declares a playbook ready.
Institutional Compliance Is Not Verification
There is a reason banks and regulated institutions need audit trails. The trail is not for the honest actor. It is for the moment when a claim must be verified against a record. Institutional compliance is built on evidence, not intent. The BlackRock ETF technical work I did in 2024 showed me how serious traditional finance is about custody chains. Every movement of bitcoin was traced. Every signing key was verified. The institutional world does not accept a written statement from a custodian. It demands a cryptographic proof that the custodian controlled the keys.
AI safety playbooks should be held to a similar standard. A playbook from Nvidia is a statement from a huge vendor. It is not a proof. Unless the playbook includes a versioned specification, a public test suite, and a documented incident response trail, it is a press release. The fact that a company like Nvidia wrote it does not make it true. The fact that Cisco wrote one does not make it true. The fact that CrowdStrike wrote one does not make it true.
I know this sounds harsh. I have seen security teams build excellent internal playbooks. I have also seen those playbooks fail because the underlying system changed and the playbook did not. Playbooks age. They describe the world as it was at the time of writing. AI systems change weekly. Model weights change. Prompts change. Context windows change. An unversioned playbook is a snapshot of a moment that will not come again.
That is why formal verification is the only truth in code. Verification does not mean that a system is safe forever. It means that a specific claim was checked against a specific version of the code. The claim can be rechecked when the code changes. The process is repeatable. A safety playbook must include the same repeatability. Otherwise it is not a control. It is an opinion.
The Contrarian View
Now I want to offer a contrarian reading. The real danger is not that these playbooks are missing details. The real danger is that their existence creates false confidence. The market hears that Nvidia, Cisco, and CrowdStrike are building AI safety playbooks and assumes that the supply chain is protected. No such protection has been demonstrated. The assumption becomes the vulnerability.
I have seen this dynamic before. In DeFi, a protocol would hire multiple audit firms. The marketing pages would list the audit logos. The market would assume the protocol was safe. The auditors would assume the other auditors covered the edge cases. The result was often a systemic failure in the code that no single auditor owned. The audits were not insurance. They were decoration. The company building its own playbook can fail the same way.
There is a second blind spot. These three companies are vendors. Their economic incentives do not always align with minimizing AI risk. Nvidia benefits from more AI adoption. Cisco benefits from more network infrastructure. CrowdStrike benefits from more endpoint coverage. A playbook that tells enterprises to buy less of a vendor's product will not be written. A playbook that adds more items to a bill of materials will be written. That is not a conspiracy. It is an incentive structure.
The CrowdStrike outage in 2024 is a useful historical anchor. A single bad update from a security vendor caused massive global disruption. The company had playbooks. The company had world-class endpoint detection. The playbooks did not prevent the incident because the incident came from the update channel, not from an attacker. The safety system itself was the source of failure. That lesson applies to AI safety playbooks. If Nvidia pushes a bad GPU firmware update, the hardware playbook will not stop it. If Cisco pushes a bad firewall rule, the network playbook will not stop it. The safety mechanism has to be safe against its own failures.
This is the blind spot that the article does not address. The three companies are not only building rulebooks for the AI ecosystem. They are building infrastructure that will ship regular updates. Those updates can introduce new failure modes. A safety playbook that does not account for the integrity of its own update pipeline is incomplete. The invariant must include the update path: no software or firmware change enters the production AI stack unless it has a verified hash and a tested rollback plan.
Another blind spot is the tension between the playbooks and the underlying model. A model is not a deterministic system. It can produce novel behavior that was not in the training distribution. A safety playbook that lists known bad prompts is useful for known attacks. It is useless for a model that invents a new strategy. The playbook must therefore be generative. It must specify the constraints on model behavior, not the catalog of bad behaviors. This distinction is common in smart contract security. A contract audit does not list every malicious transaction. It proves that no transaction can violate the invariant. AI safety must move to the same model.
The hard part is that AI systems are notoriously difficult to formally verify. The state space is continuous. The inputs are unbounded. The behavior is probabilistic. Some researchers argue that full formal verification of a large language model is impossible. I do not need to resolve that debate to make a practical point. The safety infrastructure around the model can still be verified. The prompt parser can be checked. The access-control callback can be checked. The transaction builder can be checked. The mapping from model output to action can be checked. Even if the model itself remains a black box, the controls around it can be made deterministic.
That is where I would place the next standard. Verification precedes value. The company that first publishes a deterministic verification layer for AI agents will create more safety value than every private playbook combined. The layer does not need to prove the model is safe. It needs to prove that no model output can trigger a forbidden action sequence. That proof is possible. It is the same proof used in smart contract audits. The difference is that the model is treated as an untrusted input source, not as a trusted decision maker.
I have already seen the earliest version of this approach in the AI-agent protocol I audited. The protocol wanted the agent to manage funds. The only safe design was to force every outgoing transaction to pass through a human authorization step that contained a fully rendered explanation. The model could not change the explanation. The explanation was generated from the transaction itself, not from the model. The model's role was limited to proposing. Verification was moved outside the model. That design worked. It was not because the model was safe. It was because the control layer was.
A Common Verification Ledger
Let me propose what a real AI safety playbook would contain. It would contain four components. First, a machine-readable invariant for every stage of the AI pipeline. Second, a versioned set of checks that can be executed against any deployment. Third, a log of incidents that records the exact model version, the exact prompt, and the exact action taken. Fourth, a cross-layer verification protocol that allows one layer to confirm the state of another.
The first component is the hardest for a corporate playbook. Machine-readable invariants require formal specification. They require threat modeling. They require the discipline to say what the system cannot do. Many organizations will resist this because it slows down deployment. That resistance is the signal the market should watch. A playbook that cannot be executed by a machine is not a playbook. It is a brochure.
The second component is the test suite. A good test suite is public. It can be run by independent auditors. It produces a result that can be compared with the company's claim. This is how security in crypto works. A protocol publishes its audited contracts and test results. An independent party can re-run the tests. The process is transparent. The same should be true for AI safety playbooks.
The third component is the incident log. In crypto, the block height does not lie. Every transaction has a place in the chain. The chain is immutable. AI systems do not have an equivalent ledger. They have logs that can be altered or deleted. A safety playbook should create an append-only log of AI safety events. The log should include a hash of the model, a hash of the environment, and a hash of the input output pair. Without this, it is impossible to learn from incidents.
The fourth component is the most important. Cross-layer verification requires that the output of one safety control is readable by the next. Nvidia's control should emit a signed message that describes what the hardware saw. Cisco's control should emit a signed message that describes what the network saw. CrowdStrike's control should emit a signed message that describes what the endpoint saw. A central validator can then check whether the sequence of messages is consistent with the invariant. This is essentially a multi-party audit trail.
The technology for this already exists. Hash chains, Merkle proofs, and deterministic execution engines are all common in blockchain. The AI safety industry does not need to invent a new cryptographic primitive. It needs to apply existing verification tools to a new set of objects. The obstacle is not technical. It is political. Three companies would need to agree on a shared format. They would need to expose their internal controls to external validation. They would need to admit that no single playbook is enough.
Risk Assessment
Based on my audit experience, I would place the following risks at the top of a registry if I were asked to review the three announced playbooks.
First, undefined invariants. If a playbook cannot produce a string that describes the forbidden state, it cannot be audited. The most likely outcome is that the playbook will be a list of recommendations written in natural language. That is not worthless. But it is not a safety control. I would mark it as low rigor, high ambiguity.
Second, vendor-pair blind spots. Each company will naturally focus on the attacks it knows best. Nvidia will focus on hardware and model tampering. Cisco will focus on network exfiltration. CrowdStrike will focus on runtime behavior. The gap is the interaction between layers. The exploit I found in the AI-agent protocol was not visible to the contract layer. It was in the ordering of function calls. The same kind of order violation will appear across the AI stack.
Third, update-channel integrity. Safety software that cannot update safely is itself a liability. Every playbook should include a rollback procedure. It should define the threshold for blocking an update. It should require a multi-party approval for emergency changes. I still remember how quickly the market changed after the 2024 CrowdStrike incident. The lesson was that a security product can become an outage vector. AI safety products will inherit that risk.
Fourth, absent external verification. The original article does not state whether the playbooks will be reviewed by independent third parties. Without external review, the playbooks will be self-certified. Self-certification is common in DeFi and it is consistently dangerous. A protocol that only reviews its own code will miss the assumptions that are embedded in its own culture. The same is true for a company that only reviews its own playbooks.
Fifth, no shared memory of incidents. If Nvidia, Cisco, and CrowdStrike each maintain separate incident logs, the industry will repeat the same attacks. The only way to prevent recurrence is to share the data model for incidents. The data model should include the model hash, the prompt, the network metadata, and the endpoint behavior. It should be anonymized if necessary, but it must be shared. The ledger remembers what the market forgets. An incident ledger is the collective memory that the AI industry does not yet have.
The Enterprise Effect
I am also thinking about how enterprises will use these playbooks. The chief information security officer of a large company will receive a briefing on the Nvidia, Cisco, and CrowdStrike playbooks. The officer will add the documents to the governance repository. The audit committee will see that three major vendors have AI safety playbooks and will mark the risk as mitigated. This is a category error. A playbook is not an inspection device. It is a plan that must be executed and verified in operation.
The enterprise effect is one of the reasons that audit standards matter. When I wrote executive summaries for institutional clients during the BlackRock ETF analysis, I had to include the exact chain of custody for every bitcoin movement. The clients did not ask me whether the custodian had a good software update policy. They asked me to verify the transaction path. AI safety should be the same. Enterprises should ask for cryptographic proof that an AI workload was executed on verified hardware, transmitted over a compliant network, and constrained by an approved endpoint policy.
This will create market pressure for something that the three companies have not yet announced. The market will demand a shared proof format. The first enterprise that cannot verify a cross-layer AI claim will be a cautionary tale. The first vendor that offers a verifiable claim will win the next procurement cycle.
In a sideways market, technical signals matter more than narratives. The price is not telling us where to go. The security infrastructure is. I am watching the three playbooks for one specific signal: whether they contain a machine-readable specification. If they do, they are safety systems. If they do not, they are marketing artifacts. The distinction is binary. It will become visible in the same way that a failed audit becomes visible in a post-mortem.
Takeaway
The takeaway is not that Nvidia, Cisco, and CrowdStrike should stop building playbooks. They should build them, publish them, and then submit them to external review. The takeaway is that a playbook is the beginning of a safety process, not the end. A playbook without an invariant, a test suite, an incident ledger, and a cross-layer verification protocol is a design document. It should be treated as a request for comments, not as a control.
The ledger remembers what the market forgets. In the coming years, the market will sort the real AI safety work from the theatrical kind. There will be a watershed moment, a public failure that exposes the gap between a published playbook and a verified system. The companies that prepared for that moment will be the ones that invested in verification. The companies that built documents will explain why the system was complicated. Complexity is not an excuse. Simplicity in logic, complexity in execution is the standard of infrastructure security. The logic must be simple enough to verify. The execution must be robust enough to survive the real world.
I have spent my career checking the seams between systems. The first seam was in the Tezos governance mechanism. The second was in Compound's interest rate model. The third was in Terra's collapse. The fourth was in the custody chains around regulated bitcoin products. The fifth was in the AI-agent contract that moved funds after a prompt injection. Every one of those failures was in a place where one system trusted another without verification. The same thing will happen in AI safety if Nvidia, Cisco, and CrowdStrike build their own separate playbooks without a shared audit layer.
Formal verification is the only truth in code. The code is not just the model. It is the network rules, the endpoint policies, the firmware updates, and the transaction paths. The code is the layer where the model meets the world. When that layer is not verified, the safety playbook is just a story. The market will eventually recognize the difference. The block height does not lie. Neither will the AI audit trail.
Verification precedes value. The company that treats its AI safety playbook as a practice, not a proclamation, will be the one that survives the first wave of catastrophic AI incidents. The rest will be written up in post-mortems. The post-mortems will be thorough. They always are.
