If You Can't Threat Model It, You Can't Secure It
The T.E.S.T. Standard for AI Security Reviews
By Teri Green-Manson
I have watched smart security teams fall into the same trap: a GenAI feature shows up late in the delivery cycle, someone says, ‘AI is high risk,’ and the conversation turns into a debate instead of a decision.
Here’s the problem. ‘High risk’ isn’t a finding. It’s a feeling.
If you want to ship AI safely and keep credibility with engineering, you need something sturdier than vibes: a repeatable way to name the harm, map the path to impact, and define what ‘secure enough to ship’ means.
I have sat on both sides of the table: I am a CIO/CISO today, and I came up as an engineer. That is why I’m allergic to theory. I want something teams can use in the sprint, not just defend in the review.
Threat Model the Workflow, Not the Model
The model isn’t the product. The workflow is.
A model in isolation can hallucinate all day and not hurt anyone. Risk shows up when the model is connected to sensitive data, retrieval systems, tools and actions, and the logging/analytics layer where prompts and outputs quietly live forever.
So instead of asking ‘Is the model safe?’ ask a better question: What can this AI touch, what can it change, what does it retain, and what is it allowed to treat as true?
The T.E.S.T. Standard
When teams get stuck, I bring them back to four questions. I developed T.E.S.T. to standardize AI security reviews across teams, so we can move from opinions to evidence, and from ‘AI is risky’ to ‘here’s what we’re going to do about it.’
T.E.S.T. At A Glance
T — Touch: What can the AI access?
E — Execute: What can the AI do?
S — Store: What gets retained?
T — Trust: What does the AI treat as true?
If a team cannot answer these questions clearly, the feature is not ready for production. Not because AI is scary, but because the workflow isn’t defined well enough to secure.
T is for Touch
What can the AI access?
Touch is your blast radius. It’s not just ‘data.’ It’s the systems, sources, and context the model can reach, plus what it can pull into prompts through retrieval.
Start by naming the crown jewels in plain language. Not ‘PII,’ but ‘student records,’ ‘health notes,’ ’employee investigations,’ ‘incident timelines,’ ‘keys and secrets,’ ‘internal IP ranges,’ ‘M&A decks.’ If you can’t name it, you can’t protect it.
Touch is where teams accidentally approve the breach.
E is for Execute
What can the AI do?
Execute is where AI turns from ‘assistant’ into ‘actor.’ If the AI can send an email, close a ticket, page on-call, reset a password, push code, or trigger a workflow, you’re no longer threat modeling a chat interface. You’re threat modeling an automation pipeline.
News flash: a content filter is not a guardrail. It’s one layer.
S is for Store
What gets retained?
Store is the risk that sneaks up on teams because it looks like ‘observability.’ Prompts, responses, retrieved context, tool outputs, and error traces often end up in logging systems, analytics tools, tickets, or vendor dashboards. That’s not just telemetry. That’s a new data lake.
If you can’t answer where prompts and outputs go, you can’t claim you understand the risk.
T is for Trust
What does the AI treat as true?
Trust is the most misunderstood part of AI security. If your system treats retrieved documents as trustworthy, treats user input as instructions, or treats model output as authoritative, you’ve built a system that can be manipulated with words.
User input is untrusted. Retrieved content is untrusted. Model output is untrusted. The only ‘trusted’ layer is what you can validate through controls.
How to Operationalize T.E.S.T.
If you want T.E.S.T. to work as a standard, it can’t live in someone’s head. It must show up in the process.
In practice, every AI feature should include a short T.E.S.T. section in the security review template: what the system touches, what it can execute, what it stores, and what it is allowed to trust. If any answer is unknown, the review pauses until the workflow is clarified.
That single requirement does two things: it makes risk visible early, and it gives engineering a clear target: define the workflow, reduce the blast radius, prove the controls.
A Practical Way to Apply T.E.S.T.
- Start with a one-sentence promise. If you can’t explain the feature in one sentence, you can’t secure it. That sentence becomes your scope boundary.
- Draw a one-page AI data-flow map: inputs, context sources, where the model runs, what gets logged, what the user sees, and whether the AI can take actions through tools. If you can’t fit the flow on one page, you’re still designing, not securing.
- Turn T.E.S.T. into abuse cases. You don’t need 60 scenarios; you need the ones that matter. Broad Touch drives exfiltration. Enabled Execute drives tool abuse. Uncontrolled Store drives logging leakage. Vague Trust drives prompt injection.
- Convert scenarios into testable controls. Treat user input and retrieved content as untrusted. Separate system instructions from user content. Sanitize documents used for retrieval. Redact sensitive fields before they reach the model. Allowlist tool calls with tight parameter constraints.
Example: SOC Copilot
Say you’re building an internal SOC Copilot that summarizes alerts and pulls context from tickets and a knowledge base.
T.E.S.T. makes the risk obvious:
Touch: incident notes, customer identifiers, internal IP ranges, runbooks.
Execute: creating tickets, assigning owners, notifying on-call.
Store: prompts and outputs in analytics (unless disabled).
Trust: retrieved documents treated as true (dangerous).
Controls: Sanitize retrieved documents. Redact identifiers before retrieval. Allowlist tool calls with approval for paging. Disable prompt logging by default.
That’s not theoretical. That’s shippable.
Final Thought
The teams that stand out don’t say ‘AI is risky.’ They say, clearly and calmly: here’s the harm scenario, here’s the path to impact, here’s the control, and here’s how we’ll test it.
About The Author
Teri Green-Manson is an award-winning CIO and CISO, crowned Cybersecurity Leader of the Year 2025 by Women Tech Network and named to the CISO Connect C100 Class of 2026. Rising through the ranks as an engineer, she developed the T.E.S.T. standard, an evidence-based framework that helps security teams evaluate AI features with rigor, moving from opinion to proof, so organizations can deploy AI safely without slowing innovation.
