Is AI-Generated Code Safe? 5 Safeguards to Check Before You Sign Off

Question 14 on the security questionnaire

The vendor security questionnaire lands on a Monday. It runs to 60 questions, and the security team wants it back before Thursday's steering committee.

The short answer: AI-written code is as safe as the process around it. That process is visible, so you can check it. Five safeguards tell you whether it exists: narrow agent permissions, a senior engineer who reviews and merges every change, enforced coding standards, a human gate before release, and a full audit trail. 

Why "we use AI responsibly" won't pass review

That reply fails for a simple reason. 

A control has three parts a reviewer can check: an owner, a trigger that makes it run every time, and evidence that it ran. "Human oversight throughout" has none of them. There's no named person, no fixed point in the process where oversight must happen, and no record to inspect.

Responsibility doesn't move to the tool either. The Australian Signals Directorate's Secure by Design guidance asks technology manufacturers "to assume utmost responsibility for the security of their products and services". So the useful question isn't whether a vendor uses AI, but whether their process would catch a bad change, and whether they can prove it. 

Five safeguards to ask about

Each safeguard below is something you can ask for and verify. NIST's Secure Software Development Framework (SP 800-218) was written partly for this conversation: it says purchasers can use its common vocabulary "to foster communications with suppliers in acquisition processes". 

1. Narrow agent permissions

Each AI agent has one job and only the access that job needs.

2. A senior engineer reviews and merges every pull request

A named, accountable person reads each change before it joins the codebase.

• What it looks like: branch protection that blocks any merge without an approving review, from a reviewer senior enough to reject it.

• What good looks like: changes kept small enough to read properly, and a reviewer who isn't also the person who prompted the change.

3. Coding standards and templated scaffolding

The written rules and starting templates every piece of code must follow, whoever or whatever wrote it. 

• What it looks like: a written standard, templates for common patterns such as logging and error handling, and automated checks that fail the build when code breaks the rules.

• What good looks like: agents start from approved patterns instead of inventing their own, so sensitive code paths look the same across the codebase.

4. A human gate before release

A deliberate stop where a person decides whether a change goes live.

• What it looks like: a release step no tool can clear on its own, with a named approver and a recorded decision.

• What good looks like: the gate sits after testing and before release, and the approver can see what changed and what was tested.

5. A full audit trail

A record linking every change to its request, its author, its review and its release.

• What it looks like: from any change in production,you can trace back to the ticket, the pull request and the approver.

• What good looks like: the trail shows whether an agent or a person drafted each change, which is exactly what question 14 asks.

The questions to put in writing

Ask for one real example of each, from a current project with client details removed. A vendor with these controls can show them. A vendor without them will describe them.

Then make the answers part of the contract. Attach the vendor's written replies to the statement of work, so the safeguards become obligations rather than sales-stage descriptions. If the team or tooling changes mid-project, ask for updated answers in writing instead of assuming the old ones still hold. 

What the process looks like in practice

Here's how we run this at EB Pearls. Our Agentic Development Life Cycle (ADLC) has three parts working together.

What drives effort and cost

Safe AI-assisted delivery isn't the cheapest way to produce code. The saving comes from fewer hand-offs, not from skipped review. Five things move the effort most: