A DEF CON 34 talk on NIST’s new AI Risk Management Framework profile for critical infrastructure, grounded in a real December 2025 incident — plus a direct ask from the presenter about how to get involved.
I mentioned this talk at the end of my DEF CON 34 recap and said it deserved its own post. Here’s why: it’s the one session from three days of AI security content that connected most directly to the world outside a laptop — traffic signals, ambulances, 911 lines. Everything else I saw was about systems getting exploited. This was about what happens after that, when the system in question controls something physical.
The Talk
“Inference in the Infrastructure: Developing NIST AI RMF Resources for Resilient AI in Critical Systems,” presented by Raymond Sheh (NIST, also affiliated with Johns Hopkins) and Martin Stanley (NIST), in the Policy@DEF CON track.
NIST already has an AI Risk Management Framework — the Govern/Map/Measure/Manage model most people working in AI governance have at least glanced at. What Sheh and Stanley presented is an extension of that framework into a sector-specific “Trustworthy AI in Critical Infrastructure Profile.” It’s not finished. A discussion draft is out now, and it’s explicitly open for public input — which matters more than it sounds like it should, because most of us never see a federal framework before it’s already final.
The Incident That Grounded the Talk
Frameworks are easy to nod along to and hard to actually feel. This talk didn’t stay abstract for long, because it opened with something that had happened five days before Christmas.
On December 20, 2025, San Francisco had a DDoS-style disruption that combined with a substation fire and took out roughly 30% of the city’s traffic signals. An ambulance was delayed 40 minutes. 911 callers were left on hold for 8 minutes — during active fires. And in the middle of all of it, roughly 830 autonomous vehicles and remote-operator systems were active in the mix, navigating a city where a third of the traffic signals had just gone dark.
I want to sit with that number for a second, because it’s the part that stuck with me longest: 830 AI-driven systems, operating in real time, in a city that had just lost a chunk of its basic traffic infrastructure. Nobody designed those systems to fail gracefully into “a third of the signals in your operating area are gone.” That’s not a hypothetical edge case. That’s Tuesday, apparently.
Sheh and Stanley’s framing for why this belongs in an AI risk framework, and not just a general infrastructure-resilience one, was a single line I keep coming back to: exploit or error, the blast radius looks the same. Whether that substation fire and DDoS combination was somebody’s deliberate attack or a cascading accident doesn’t change what an ambulance driver or a 911 dispatcher experienced that night. You have to plan for both. A framework that only accounts for malicious actors is planning for half the problem.
The Framework, and Practice 12
The Critical Infrastructure Profile is built around a set of concrete practices — 12 drafted so far, with an eventual 20-30 planned. The ones already on paper cover things like identity and access management specifically for AI agents (not just the humans operating them), AI-aware incident analysis and response procedures, and multi-tiered logging and audit capability built for how AI systems actually fail, not just how traditional software fails.
The one I keep coming back to is Practice 12: validate AI-generated code, configurations, or procedures with a risk-tiered review before they reach production. Not a blanket “have a human check it” rule — a review sized to how much damage a wrong answer could actually do. A low-stakes internal script gets a light touch. A configuration change that touches a traffic-signal controller or a 911 routing system gets something a lot heavier, before it ever goes live.
That’s not a new idea to anyone who’s worked in change management. What’s new is applying it specifically to AI-generated output, where the failure mode isn’t “an engineer made a typo” — it’s “the model produced something confident, plausible, and wrong, and nobody caught it because it looked like normal output.” Risk-tiered review is the same discipline I already lean on for any deliverable that touches something client-facing or financial. Seeing it written into a federal framework, sized specifically for infrastructure, was a useful confirmation that the instinct scales.
Talking With Raymond Sheh
I actually met Raymond Sheh a couple days before this talk even happened — a chance conversation at the conference, kicked off by a t-shirt my husband was wearing. We talked for a while, and it was enough of a connection that he followed up afterward by email, which is the part of this post I actually want you to act on.
What came through in that conversation, and in the framework itself, is that NIST isn’t trying to hand down a finished rulebook here. They’re building this in public, on purpose, because a framework for AI in critical infrastructure that gets written entirely by people who’ve never had to operate a traffic system, a utility, or an emergency dispatch line isn’t going to hold up. The discussion draft being open right now is the actual invitation, not a formality before the real decisions get made somewhere else.
What He Asked Me to Pass Along
Here’s the direct ask from Raymond’s follow-up email, because I think it’s better in his words than mine:
“please also consider joining our community of interest so we can make sure you get the latest updates and so we can keep accurate statistics. Please do also feel free to send the discussion draft on to your colleagues and also encourage them to sign up for our community of interest.”
So, two concrete things, straight from the source:
- Join the NIST Community of Interest for the Trustworthy AI in Critical Infrastructure Profile — it’s how you get the updates as the draft evolves, and it’s also literally how NIST tracks who’s paying attention to this work.
- Pass the discussion draft along to colleagues who work anywhere near infrastructure, AI governance, or incident response — and encourage them to join the Community of Interest too, not just read the draft once and move on.
If you’re a PM, a governance lead, or anyone adjacent to a system that touches the physical world — utilities, transit, emergency services, even a supply chain with AI-driven routing — this is the rare case where a federal framework is still soft enough that your input has somewhere real to go. Start at NIST’s program page for the Concept Note: AI RMF Profile for Trustworthy AI in Critical Infrastructure, read the discussion draft, and if any of it applies to your work, join the Community of Interest and send it to someone who should see it too.
Related Posts
- Three Days at DEF CON: What AI Security Looks Like From the Attacker’s Side — the full recap this post was split out of
- The GATE Framework: AI Governance for PMOs — a structured way to think about AI governance decisions before they become incidents
A framework that’s still open for comment is worth more of your time than one that’s already finished — this is the window where your input still changes something.