AI tool security review: getting to yes
Stefan-Iulian Tesoi · · 6 min read
Bring the answers before the questions: what the connection can reach, what it cannot, where the data goes, and what the audit trail records. Assemble them into one page with links to the documents that already say it. Reviews stall on missing information far more often than on genuine objections.
An AI tool security review is usually imagined as an argument to be won. It is closer to a form somebody else has to be able to fill in, and most of the delay is the several weeks it takes to gather what should have arrived on day one.
What does an AI tool security review actually need?
Enough to write down an answer that someone else will read later.
That is the reframe worth making before the first meeting. The reviewer is not deciding whether they personally trust the tool. They are producing a record that has to survive being read by an auditor, an insurer or their own successor, and they cannot produce it from a demo and an impression. Every question they ask is really "what do I write in this box".
It follows that the useful currency is documents rather than reassurance, and that a confident verbal answer is worth less to them than a mediocre written one. It also follows that you can do most of their work in advance, which is the whole trick.
A reviewer who cannot cite a source for an answer has to either refuse or take personal responsibility for it. Most people, asked to do that on a Thursday afternoon, refuse.
What goes in the packet?
One page, four links, and no prose about how transformative the tool is. Every row below is a question a vendor security assessment will ask in some wording, and in most cases the answer is already published somewhere you can point at.
| What they need | Where the answer lives |
|---|---|
| What the integration can reach | The tool reference, with a permission on every call |
| What it cannot do, structurally | The same page, plus the connection docs |
| Where data goes and who else receives it | The vendor's privacy policy and subprocessor list |
| Retention and deletion | The same policy, stated per kind of data |
| Contractual terms and liability | The terms of service, and a DPA if one is needed |
| What is recorded when something changes | The audit trail: attribution, cause, and criteria |
For Laimonade specifically, those are the privacy policy, the terms and connect your coding agent, which covers how the MCP connection is authorised, how the credential works and what it is scoped to. Fourteen subprocessors are named with their purpose and the data each receives, which is the row that most often comes back as a follow-up question when it is missing.
If your reviewer uses a standard questionnaire — the Cloud Security Alliance's Cloud Controls Matrix and its CAIQ are the common ones — ask for it early and answer it directly rather than sending a policy and hoping. A questionnaire returned complete is the shortest path through an AI tool approval process that exists.
Which objections are proxies for something else?
Most of them, and the skill is hearing what is underneath rather than arguing with the sentence.
- "We don't allow AI tools." Usually means there is no process for evaluating one, so the safe answer is no. The unblocking move is offering to be the first case and doing the paperwork, not disputing the policy.
- "Where does the data go?" asked a second time. The first answer was verbal. Send it in writing and the question stops.
- "We'd need a DPA." This is not an objection, it is a requirement with a known shape, and it is usually the fastest item on the list once somebody asks the vendor for one.
- "It's not on the approved list." There is a list, which means there is a route onto it. Ask what puts something on it.
- "What happens when it goes wrong?" A question about the audit trail and about revocation, phrased as anxiety. Answer it with the record and the off switch.
The one that is not a proxy is a data-residency or regulated-content constraint. When backlog items carry patient identifiers, card data or anything with a residency requirement, that is a genuine data-flow decision and no amount of packet-assembly moves it. Those cases are worth naming yourself before the reviewer does, and the honest ones are set out in coding agent security.
How do you scope a pilot a reviewer can approve?
Make it small, reversible and dated. A reviewer can say yes to something that ends by itself far more easily than to something that does not.
- One project, one person's sign-in. Not a shared key: per-person credentials keep attribution intact, which is the thing a reviewer will be asked about afterwards.
- Read-only for the first fortnight. An agent that reads the backlog and writes nothing still answers the question everyone actually has — whether the items are good enough to work from.
- A named end date. "Approved until the 30th, then we review what happened" converts an irreversible decision into a scheduled one.
- A named owner. Somebody whose job it is to revoke the connection if the pilot stops. Connections outlive the projects that justified them when nobody owns them.
- Agreed evidence. What you will bring back: how many items were executed, what the audit trail showed, whether anything unexpected was reached.
Getting AI tools approved at work is mostly this: converting an open-ended request into a bounded experiment with a date on it. What the experiment is for, from the perspective of whoever holds the team, is in Laimonade for engineering leaders.
As for how long it should take: days when the packet is complete and the tool is not novel to the reviewer, two to six weeks when a questionnaire and a DPA are involved, and indefinitely when you arrive with a link to a marketing page. The variance is almost entirely on your side of the table.
Frequently asked questions
What if security says no to all AI tools?
Find out what the blanket is protecting against, because it is rarely the technology. Common answers are an unmanaged adoption that happened before, an inability to answer a board question about data flows, or the absence of any evaluation process. Each has a different response, and only the last one is solved by a better packet — the other two need somebody to own the gap.
Can you pilot without full approval?
Often, if the pilot is small enough to fit an existing exception. Read-only access to one non-sensitive project, on a personal credential, with an end date, is the shape most organisations already have a route for. Ask what that route is called locally rather than asking for an exception in general — the named process is what an approver can act on.
Who should own the relationship with the vendor?
Whoever will be asked about it in a year, which is usually not the person who found the tool. The engineer who set it up moves teams; the connection does not. Name an owner at approval time, write it in the record, and make revocation their responsibility rather than a collective one.
Does a pilot need its own security review?
Usually a lighter one, and it is worth asking rather than assuming. Many organisations distinguish an evaluation from a deployment and have a shorter path for the first. Where they do not, running the full review on a bounded pilot is still faster than running it on an open-ended rollout, because the scope of what you are asking for is smaller.