Correction — editorial date ; actual revision : Earlier versions described TopFlow's controls too broadly. This update distinguishes workflow checks from request-boundary validation, URL guards from complete SSRF prevention, and current execution restrictions from isolation. Rate-limit behavior also depends on deployment configuration. The five-layer model below is a review framework, not evidence that every layer is complete.
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 a model you can use to review where the 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 limits and per-identity quotas can bound some usage; neither a local quota nor a shared limiter is a complete spending cap. Detection requires separate observations and alerts.
- Layer 4: Execution and output handling. This boundary deserves explicit attention in an AI review, especially when output can authorize actions. 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
These are illustrative connections to familiar frameworks, not a complete control mapping or compliance attestation. Verify the applicable framework edition and your organization's evidence requirements.
- 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:
- What happens if the input contains instructions instead of data?
- What's logged, and would we be comfortable if that log leaked?
- Who can call this, how often, and would we notice abuse?
- What does our system do with the model's output before a human sees it?
- 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.
Make the control owner accountable
Turn the five answers into a short decision record: exposed data, accountable owner, evidence checked, residual risk, and the next review date. A vendor's claim that it validates output is not your evidence; save the test that shows your integration rejects an unexpected identifier or an unauthorized destination.
Separate implementation evidence from operating evidence. A parser test shows a boundary can work; production configuration, rate-limit observations, and incident handling show whether it works where you deploy it. Let that distinction drive the approval: a read-only pilot with named limits can be reasonable while automated outward actions remain unapproved.
Where this gets concrete
I built TopFlow, a security-focused visual AI workflow platform with reviewable source code. Its current implementation makes several boundaries concrete, but they have different scopes:
- Input: workflow structure checks exist, but they are not a complete runtime schema for the execution API request. A TypeScript annotation does not validate incoming JSON.
- Outbound requests: the URL guard checks user-supplied absolute HTTP URLs against hostname and literal-IP rules. It does not resolve DNS, so DNS rebinding remains a residual risk. Outbound HTTP follows redirects without re-checking the new destination. Engine-generated internal app routes follow a separate trusted path; this is not complete SSRF prevention.
- Execution: Custom JavaScript and Tool-node code is refused while isolation is being built. Built-in template code still runs, and conditions use a restricted parser. This is containment, not an isolated sandbox.
- Rate control: the execution route uses Upstash when configured and process-local memory otherwise. Memory limits do not form a shared quota across instances; production configuration is not verified here.
The scanner's output path adds finding-ID validation and deterministic factual assembly. Those checks do not establish source coverage, ranking accuracy, or the correctness of optional model commentary. Review the technical writeup on topflow.dev and its linked implementation as evidence, then verify the configuration and residual risks in your own deployment. A control's presence in source code is not a security certification.
If you want a second set of eyes on how this maps to your specific architecture, Book a consultation and bring your hardest "what about" question.