AI coding assistants are not a side experiment anymore. They are becoming part of normal software work: draft a function, explain an API, write a test, refactor a messy block, suggest a migration, generate a policy check, fix a linter error.

That does not automatically make the code unsafe. It does make one old AppSec question much more important: where does the organization decide that code is allowed to become product code?

A lot of teams are tempted to govern AI generated code by policing prompts. That sounds tidy. It is also the wrong center of gravity.

Prompt review is a weak control

Prompt policing appeals to security teams because it feels close to the AI risk. If the model wrote the code, surely the prompt is where governance should live.

Sometimes prompt rules are useful. Do not paste secrets. Do not paste customer data. Do not upload proprietary code into tools that are not approved for that use. Those rules belong in an AI acceptable use policy and in tool configuration where possible. Zero Drama Security has written before about why an AI acceptable use policy needs to control real work, not just ban the obvious things.

But reviewing every prompt is not a serious software security control. Prompts are messy. Developers iterate. They ask partial questions. They use local context. They abandon suggestions. They paste snippets into editors. They rewrite what the assistant gave them. The prompt is often not the thing that ships.

The thing that ships is code.

So the control should sit where code becomes part of the product.

The merge boundary is where authority happens

The merge boundary is the moment a proposed change crosses from private work into the shared codebase. It may be a pull request, merge request, protected branch, release branch, package publication, infrastructure module update, or deployment workflow.

That is where AI generated code should be governed.

Not because every line needs a special AI scarlet letter. Because the merge boundary already carries the authority security cares about. It is where ownership, review, testing, provenance, secrets, dependencies, build behavior, and deployability come together.

If AI generated code can pass through that boundary with less scrutiny than human written code, the organization has made the wrong tradeoff. If AI generated code requires a separate ceremony so heavy that engineers route around it, the organization has also made the wrong tradeoff.

The right tradeoff is boring: treat AI assistance as a source of acceleration, not as a source of accountability.

The human author still owns the change.

What the boundary should prove

A useful merge boundary does not need theatrical AI review. It needs evidence that the change is safe enough to accept.

At minimum, the boundary should answer a few direct questions.

Who owns this change? The answer should be a person or accountable team, not the assistant, not the vendor, not the model. If the code breaks production, introduces a vulnerability, or changes data handling, someone inside the organization owns the decision.

What changed? Reviewers need enough context to understand the behavioral change, not just the diff volume. AI generated code can look plausible while changing edge cases, error handling, authorization paths, logging behavior, or data retention behavior.

What authority does the code receive after merge? A small code change can become powerful once it runs in a pipeline, reads a secret, writes to a database, calls an internal API, or deploys infrastructure. That connects directly to the problem in CI/CD secrets becoming delegated authority. Code review should not pretend the code is harmless just because the diff is short.

What evidence was produced? Tests, scans, review approvals, dependency checks, threat model notes, and release decisions should be durable enough to survive an incident review or customer diligence request. Audit trails are not only for compliance. As ZDS has argued, audit logs are product features when they show who acted, what changed, and why the evidence can be trusted.

Where to be stricter

Not every AI assisted change deserves the same scrutiny. That is where many programs get clumsy. They either wave everything through because the developer is trusted, or they create a universal AI review gate that treats a test helper and an authorization change the same way.

Use risk triggers instead.

Be stricter when the change touches authentication, authorization, session handling, cryptography, secrets, logging, data export, data deletion, tenant isolation, payment logic, workflow approvals, admin capability, agent tool calls, or infrastructure permissions.

Be stricter when the change introduces a new dependency, modifies a build or deployment workflow, changes generated code templates, or creates code that other teams will reuse.

Be stricter when the reviewer cannot explain the code. That sounds basic, but it is one of the cleanest signals. If a developer accepts AI output they do not understand, the problem is not AI. The problem is that code is entering the product without accountable comprehension.

The disclosure question

Should engineers disclose when AI helped write code?

Sometimes, yes. But disclosure should serve a decision, not create a confession ritual.

A lightweight checkbox can help reviewers calibrate. It can also help security understand adoption patterns. But a checkbox that says AI used is not a control by itself. It does not prove the code was reviewed. It does not prove the dependency is safe. It does not prove the tests cover the risky path.

The better question is: what extra review is required when AI assistance intersects with sensitive code?

That keeps the program focused on impact, not moral theater.

What leaders should ask for

Security leaders do not need to ban AI coding assistants to sound serious. They also should not accept vague reassurance that engineering has it handled.

Ask for the operating model.

Which tools are approved for which codebases? What data and code may be sent to them? Where are the settings controlled? What happens at merge? Which branches are protected? Which checks are required? Which changes trigger security review? Who can override a failed check? Where is the evidence stored?

Those questions are not anti developer. They are how fast software teams avoid turning speed into silent risk.

If your organization is trying to turn AI coding use into a workable security architecture decision, Zero Drama Security services can help shape the control model without turning engineering into a permission queue.

AI generated code is still code. It still needs ownership. It still needs review. It still needs evidence.

The assistant can help write it. It cannot own the merge.