AI security answers your buyer
can actually review.

This is the first AI-specific question, and it’s the right one. Can something that looks like ordinary input — a support ticket, an uploaded PDF, a page in your RAG index — carry instructions the model then follows?

What I usually hear

“We tried some jailbreaks.” · “We ran a scanner.” · “We have guardrails.” · “Nothing’s blown up in production.”

None of that is wrong, and none of it is enough. A handful of prompts isn’t coverage. A scanner result isn’t proof of behaviour — garak will mark a “hit” the moment its target string shows up in the output, including when the model quoted it while refusing. A guardrail is intent, not outcome. And production has never had someone deliberately attacking it.

What lands with a reviewer“Here are the entry points we tested, in these workflows, with these inputs. This is what the model saw, what it retrieved, and how it responded — and here’s how many times out of N it reproduced. These held, these failed, these we didn’t test.”

This one is less about the model and more about where it sits. The usual answer leans on controls that already exist.

What I usually hear

“Access control.” · “SOC 2.” · “The backend enforces permissions.” · “The model only sees authorised data.”

All useful, but it’s not the question. The question is whether those controls hold when the AI path is the way in. Can a user get the model to fetch another tenant’s record? Can a poisoned document pull restricted data into context? Can the assistant be talked into surfacing internal notes or its own system prompt? A SOC 2 report shows a control exists — it doesn’t show how that control behaves with an LLM in the loop.

What lands with a reviewer“We tried to cross the tenant boundary through the assistant — direct prompts, instructions hidden in retrieved content, and the tool path. Here’s what entered context, what came back to the user, and where enforcement held or didn’t.”

The moment the system can do more than talk — query data, call an API, change a record — this matters. The answers sound calm.

What I usually hear

“The agent only has approved tools.” · “The backend checks permissions.” · “Sensitive actions need approval.”

The gap hides in the verbs. There’s a real difference between the model suggesting an action, the model emitting a tool call, the backend executing it, and something actually changing state — and most answers blur all four into one. A standard pen test checks the app; it rarely asks whether the model can be talked into a tool call outside the user’s scope.

What lands with a reviewerThe whole chain, in order: input · who the user is · model output · tool selected · arguments · the authorisation decision · what executed · what the user saw. Anything short of that asks the buyer to trust the architecture diagram instead of the logs.

This is where teams find they have logs but not evidence.

What I usually hear

“It’s in Datadog.” · “We can reconstruct it.” · “We store prompts and responses.”

Probably true — but a reviewer doesn’t want fragments from five systems. They want one chain per issue: the input, the instructions in play, what was retrieved, what was called, what got allowed or blocked, what came out, whether it reproduced, whether it was fixed. When those pieces aren’t joined up, even a solid system reads as immature.

What lands with a reviewerThat chain, assembled per finding — not “available somewhere in the logs.”

Here the answers get thin.

What I usually hear

“We patched it.” · “We updated the prompt.” · “We added a guardrail.” · “That’s an old issue.”

What’s missing is proof. A prompt fix can hold for one phrasing and fail on the next. A guardrail can close one route and miss another. The only answer that counts: here’s the same attack, re-run after the change, now failing.

What lands with a reviewerSeparate four things people tend to merge: what failed, what you changed, what you re-tested, and what you’re calling resolved.

This is the one experienced buyers actually weigh. The weak move is to sound total.

What I usually hear

“We tested everything.” · “Fully covered.” · “Best practice.”

It does the opposite of reassure. Nobody believes full coverage; they believe clear limits.

What lands with a reviewer“These workflows and roles were in scope. These data paths were covered. These rely on policy, not testing. These are partial. These weren’t assessed. These are out of scope.” Stated limits read as control. Blanket confidence reads as a bluff.