The five questions your security team will ask about your AI agent

The approval meeting is not the problem

Most AI pilots stall before production, and most teams blame the security review. The review is not the problem. The problem is that the pilot was built without the information the review requires.

Security teams ask five questions before approving any new system. An AI agent is a new system. Preparing for those questions is not bureaucratic overhead — it is how you build the thing correctly in the first place.

Question one: what can this identity reach?

Every AI agent calls APIs, reads databases, writes to storage. The first question is not "does it work?" — it is "if this agent's credentials were stolen, what would an attacker reach?"

Most pilot agents are built on developer credentials or overly broad service accounts. The agent can reach everything the developer can reach. That is not a security posture — it is an attack surface.

The answer your security team needs: a named identity with documented, scoped permissions, written as policy-as-code, checked into a repository. If your agent calls five APIs, its policy should permit five API actions, no more.

Question two: what does it do when it fails?

LLMs fail in ways that are different from traditional software. They produce plausible-sounding wrong answers, they can be prompted into unexpected behaviour, and they do not throw a stack trace when they go sideways.

Security teams want to know what happens at the boundary. If the model produces an output that triggers a downstream write, what validates that output before it executes? If the agent calls a tool and the tool returns an error, does the agent try again, escalate, or silently continue?

Guardrails are not optional polish on an agent. They are the thing that makes an agent approvable.

Question three: is there an audit trail?

"We can look at the logs" is not an audit trail. An audit trail answers: on this date, this agent was called with these inputs, it produced these intermediate steps, it called these external services with these parameters, and it produced this output. All of it is structured, all of it is queryable, and all of it is retained for a defined period.

Most pilot agents log to a developer's console. That is not the same thing.

Question four: who is accountable?

Autonomous systems make decisions. Decisions can be wrong. Your security team wants a named human who owns the agent's behaviour — someone who reviews anomaly reports, who makes the call to take it offline, and who is on call if it does something unexpected at 2am.

If the answer is "the team," the team is the problem. A named person, a documented escalation path, and a defined review cadence.

Question five: how do we turn it off?

This one is usually forgotten until it becomes urgent. Your security team will ask for a documented, tested procedure to disable the agent without taking the surrounding system down with it. A kill switch. A circuit breaker. A way to remove its permissions without a production incident.

If you cannot answer this question cleanly, you have not thought about the failure modes.

Build for the review, not around it

None of these questions are unreasonable. All of them are answerable if you build with them in mind from the start. The teams that sail through security reviews did not do less work — they did different work, earlier, and they documented it.

If you are building an agent and you want to run through these questions before your review, our Gen AI consulting engagement starts with exactly this checklist and hands you the evidence pack at the end.