Seven questions security teams ask before approving an AI coding agent
Developers want coding agents; security teams have to sign off. These are the seven questions that decide it — and what a good answer sounds like.
In most engineering organizations, the question is no longer whether developers will use AI coding agents. It's which one security will approve. When we talk to teams evaluating them, the same seven questions come up — and the answers separate an agent you can govern from one you can only hope behaves.
Why this conversation is happening now
Coding assistants used to suggest code. Coding agents act: they run commands, query databases, call internal tools and open pull requests. That moves the risk from what the model says to what the agent does — and that's squarely a security team's problem. These questions are how good security teams get to a decision quickly.
1. When the agent acts, where is the decision made?
Ask what happens when an agent runs a write against a production database. Is it allowed or refused before it runs, and by what? A good answer names a component that holds the authority and decides at the moment of the action. “We log everything” is an answer to a different question.
2. Can a developer change the policy on their own machine?
Many controls are settings files on the developer's laptop. They're useful for defaults, but whoever controls the machine controls the rules. Ask which controls are enforced somewhere the developer can't edit — and which ones only work if nobody changes a file.
3. Where do the credentials live?
If database passwords and API tokens sit on the developer's machine, the agent can always reach those systems directly, whatever the policy says. The strongest answer is that credentials for shared systems never reach the laptop at all.
4. Where do the agent and the models run?
“Self-hosted” can mean many things. Ask where the agent's planning loop runs, where inference runs, and what has to be reachable outside your network for any of it to work. For regulated teams, the answer that matters is whether everything can run inside your own boundary.
5. What happens when a tool changes after you approved it?
Agents increasingly reach tools through MCP servers, which change like any other dependency. Ask whether an approval is tied to a specific tool definition, and what happens when that definition changes upstream.
6. Is the audit trail evidence, or just a log?
Ask what's recorded — admin logins, or the agent's actual actions and the decisions made about them — and whether the record is tamper-evident. An audit trail is only useful in an incident if you can trust it hasn't been altered.
7. How fine-grained is access?
Turning a tool on or off for everyone is rarely enough. Ask whether access can be granted per person, per system and per level — read, write, admin — and whether the agent can ask for more in the flow of work instead of developers finding a way around it.
Using these questions
None of these questions favours one vendor's marketing; they favour architectures where the decision, the credentials and the evidence live somewhere the agent can't reach. That's the design we chose for Kryex: governed actions are authorized on Kryex Server before they run, credentials stay on the server, the shell policy is locked on each device, and every decision is written to a hash-chained audit log.
If you're building your own evaluation, the AI coding agent governance checklist and where AI agent policy is enforced go deeper on each point.
