The situation
The review nobody prepared for.
Engineering has a plan: AI coding agents for six teams by the end of the quarter. The pilot went well, the engineers want it, and the budget is approved. Then the request reaches security.
The review comes back with questions nobody on the engineering side had prepared for. Where does the code go? Whose credentials do the agents use? Who approved that change? Each answer takes a week to find, and some can't be found at all. The rollout slips by a quarter.
None of the questions are unreasonable. They're what any security team asks of any new system that touches code. Knowing them in advance is most of the work.
The questions
Twelve questions, in four groups.
Security teams want to know four things: where data goes, who has access, what stays under control, and what can be proved afterwards. For each question: why it's asked, what a good answer looks like from any vendor, and ours.
Data
Where your code and data go.
Where does our code go?
- Why they ask
- Every AI coding tool sends code somewhere to be read, and that path is the first thing security wants mapped.
- A good answer
- A named list of every place code travels, each one a provider you've already approved.
- Wakalix's answer
- Wakalix never runs the model. AI runs on your engineers' machines, so code only reaches the AI provider you approved.
Is our code used to train models?
- Why they ask
- Code is intellectual property, and some providers' terms allow training on what they receive.
- A good answer
- The training terms of every provider in the path, checked and on file.
- Wakalix's answer
- That's between you and the AI provider you approved. Wakalix never runs the model, and adds no provider of its own.
What stops secrets or customer data leaking through agent work?
- Why they ask
- Agents write quickly, and a credential or a customer record in their output can land in a repository before anyone looks.
- A good answer
- A check for credentials and personal data that runs on agent output before the work is accepted.
- Wakalix's answer
- Guardrails check agent output for credentials and personal data before it's accepted.
Access
Who can do what, and for how long.
Whose credentials do agents use?
- Why they ask
- A shared account used by every agent is one leaked key away from access to everything.
- A good answer
- Each agent acts with the access of the person it works for, and no more.
- Wakalix's answer
- Agents use each engineer's own access, so there's no shared credential to leak.
Who decides which agent may work on which repository?
- Why they ask
- Not every agent should touch every codebase. Least privilege applies to agents as much as to people.
- A good answer
- Rules per agent and per repository, set by the organisation, not by whoever installed the tool.
- Wakalix's answer
- Roles and access decide who may use which agent, against which repository.
What happens when someone leaves?
- Why they ask
- Offboarding is where access quietly outlives employment, and AI tools add new places for it to hide.
- A good answer
- Access that follows your identity provider, so removing a person removes everything they could run.
- Wakalix's answer
- Single sign-on with your identity provider, so access ends the moment IT removes someone.
Control
What stays in human hands.
Can an agent change our code without a person?
- Why they ask
- Unreviewed changes are how defects and backdoors reach production, whoever or whatever wrote them.
- A good answer
- No agent change reaches your code until a named person has reviewed and accepted it.
- Wakalix's answer
- Every agent change is reviewed and accepted by a person before it reaches your code, and a plan runs only after a person approves it.
What if an agent reads a malicious instruction?
- Why they ask
- Prompt injection hides instructions in files, tickets or web pages that an agent reads and then follows.
- A good answer
- Controls that don't rely on the model spotting the trick: constrained outputs, and a person between the agent and your code.
- Wakalix's answer
- Typed outputs and human approval mean an injected instruction can't quietly ship.
Are our rules enforced, or only written in a prompt?
- Why they ask
- A rule that lives only in a prompt is followed when the model remembers it. That isn't a control.
- A good answer
- The rules that matter are enforced by the system, and it's clear which ones rely on judgement.
- Wakalix's answer
- Most rules are built into how work moves, so they can't be skipped. The rest are held outside the model.
Evidence
What you can prove afterwards.
Can we prove who asked for a change, which agent made it and who approved it?
- Why they ask
- When something goes wrong, or an auditor asks, “the AI did it” isn't an answer.
- A good answer
- A record for every change: who asked, which agent and version did the work, and who approved it.
- Wakalix's answer
- Every agent action is attributable: the agent version, who asked for it and who approved it.
Can we tell which version of an agent did the work, and roll it back?
- Why they ask
- A change to an agent's instructions changes everything it produces afterwards.
- A good answer
- Agents released like software: versioned, pinned, every change recorded, and a way back.
- Wakalix's answer
- Agents are released, pinned and rolled back, and every change is recorded.
Are new agent versions tested before release?
- Why they ask
- An untested agent version is an untested change to every piece of work it touches.
- A good answer
- Each version passes defined test cases before anyone can use it.
- Wakalix's answer
- Every new version runs against test cases, and a version that can't pass its own evaluation isn't published.
Try this on your organisation
Can you answer them today?
Go through the twelve for the AI tools you use now, and mark each one Yes, Partly or No. You'll get a brief that lists the gaps, ready to paste into a ticket. Nothing you choose leaves this page.
A “Partly” counts as a gap. Security teams sign off on answers, not intentions.
With Wakalix
Answers that come from how the work moves.
In Wakalix, most of the twelve are answered by the system rather than a policy document. Every agent change is reviewed and accepted by a person, most rules are built into how work moves, and every agent action is attributable.
Need the detail in writing for your security team? Request our security pack →