The CISO's Framework for AI Defense-in-Depth

Your board asks one question about every new AI initiative: "Is it secure?" Most CISOs answer with a shrug dressed up as confidence: a checklist borrowed from cloud security, a vendor questionnaire, maybe a line item that says "model risk: under review." None of it maps cleanly to what's actually running in production, because the architecture underneath AI systems doesn't look like the architecture your existing frameworks were built for.

I spent over a decade running security programs before AI adoption accelerated past anything our existing controls were designed for. The pattern I kept seeing: organizations bolting AI onto infrastructure that was never evaluated for it, then asking security teams to retroactively bless something they had no hand in designing. The fix isn't a new framework from scratch. It's translating defense-in-depth (a model security teams already trust) into the specific layers an AI system actually has.

Why "we reviewed the vendor" isn't a security program

Most AI security reviews stop at the vendor contract: data processing agreements, SOC 2 reports, maybe a pen test summary. That's necessary, but it answers the wrong question. The vendor's security posture tells you whether the model provider is trustworthy. It tells you nothing about whether your integration (the prompts you send, the outputs you trust, the systems you let those outputs touch) introduces risk on your side of the boundary.

AI systems fail differently than the applications your frameworks were built around. A compromised API key is bad in any system. A compromised AI system can also be tricked into leaking the data it was given, taking actions its output wasn't supposed to authorize, or quietly degrading in ways that don't trigger any alert because nothing "broke." The system just started being wrong. Defense-in-depth still works as a model. It just needs different layers.

The 5-layer model

Here's the version I use with clients, mapped to where the real risk sits in a typical AI deployment.

• Layer 1: Input. Every prompt, document, or user message that reaches the model is untrusted input until proven otherwise, the same way a web form is. The question for this layer isn't "do we have input validation." It's "what happens if someone puts attack instructions inside the content we're feeding the model, instead of inside a form field." Prompt injection lives here, and it's the layer most teams haven't mapped at all.
• Layer 2: Transport and storage. This one is the most familiar: encryption in transit, encryption at rest, key management. The AI-specific wrinkle is what gets logged. Prompts and completions often contain more sensitive material than teams expect, because users paste things into chat interfaces they'd never put in a structured form. Audit your logging pipeline for AI traffic the same way you'd audit it for a new payments system.
• Layer 3: Access and rate control. Who can call the model, how often, and at what cost. This layer is where runaway spend and abuse converge: a single compromised credential or a poorly-bounded automation can both rack up bills and generate volume that masks malicious use. Rate limiting and per-identity quotas function less as a budget control and more as a detection mechanism.
• Layer 4: Execution and output handling. This is the layer that doesn't exist in most pre-AI threat models, and it's the one I'd prioritize first if you only fix one thing. Model output is not safe by default. If your system takes a model's response and uses it to call another API, write to a database, or render it in a browser, you have to treat that output exactly like you'd treat user input. Functionally, it is. Untrusted reasoning produces untrusted instructions, even when the model is well-behaved by design.
• Layer 5: External dependencies. The model API, the vector database, the third-party tools an agent is allowed to call. Each one is a vendor relationship and a blast-radius question. If a tool-calling agent can hit an internal URL, you've reintroduced SSRF risk through a brand-new door, and most network security tooling wasn't built to see it.

Mapping this to frameworks you already report against

None of this requires inventing new compliance language. It crosswalks directly.

• NIST AI RMF: Layers 1 and 4 map to the "Map" and "Measure" functions; ongoing monitoring of output behavior maps to "Manage."
• OWASP Top 10: Layer 1 covers injection-class risks; Layer 4 covers the equivalent of insecure deserialization, applied to model output instead of serialized objects; Layer 5 covers SSRF and vulnerable dependencies.
• ISO 27001 / SOC 2: Layers 2 and 3 slot into existing access-control and data-protection clauses with minimal rewriting. You're extending controls you already have, not building new ones.

The point of the crosswalk isn't paperwork. It's that you don't need your board to approve an entirely new governance model. You need them to approve extending the one you already have in five specific places.

What to do with this Monday morning

Don't try to instrument all five layers at once. Pick the AI system with the highest exposure (the one touching customer data or taking automated action) and ask five questions, one per layer:

1. What happens if the input contains instructions instead of data?
2. What's logged, and would we be comfortable if that log leaked?
3. Who can call this, how often, and would we notice abuse?
4. What does our system do with the model's output before a human sees it?
5. What can our tools or agents reach, and have we verified that boundary ourselves rather than trusting the vendor's word?

If you can't answer all five with confidence, you've found your next quarter's priority list, and you didn't need a new framework to get there.

Where this gets concrete

I built TopFlow, an open-source AI workflow framework, specifically to implement this model in running code rather than slide decks: input validation, SSRF-safe execution, rate limiting, and output handling all exist as working TypeScript, not policy documents. If you want to see Layer 4 and Layer 5 controls firsthand, the technical writeup is on topflow.dev, including the parts that are honest about what the controls don't cover.

If you're further along and want a second set of eyes on how this maps to your specific architecture, that's the conversation I have with clients every week. Book a consultation and bring your hardest "what about" question.