The Compliance Guide to AI-Written Code

The governance gap

The clearest public record of how fast AI took over code production comes from Google's own statements: a quarter of new code in October 2024, well over 30% by April 2025, about half by late 2025 (written by coding agents and reviewed by engineers), and 75% by April 2026.¹ Microsoft's Satya Nadella put his company's share at 20 to 30% back in April 2025.²

Figure 01 — the governance gapAdoption vs policy

The share of code written by AI climbs steeply while policy coverage stays flat, and the widening gap between them fills with ungoverned change. Illustrative, not to scale.

The pattern extends well beyond Big Tech. In Checkmarx's survey of 1,500+ security and development leaders, 34% of organizations report that more than 60% of their code is AI-generated.³ For a large share of the industry, AI generation is already the default way code gets written.

Policy coverage has not kept pace

Three independent surveys converge on the same finding: adoption is running roughly three times ahead of policy, and every percentage point of AI-generated code that ships without governance adds exposure. The rest of this guide covers how to close that gap with controls that hold at agent output volume, rather than by slowing adoption down.

What AI-generated code does in production

A governance policy is only as good as its model of the risk. The research base from 2023 to 2026 is unusually consistent about what AI-generated code does when nobody is checking.

It carries more security defects

Veracode tested 100+ models against 80 curated coding tasks: 45% of AI-generated code introduced security vulnerabilities, with an 86% failure rate on cross-site scripting. Newer and larger models wrote more capable code without writing more secure code, and Veracode's Spring 2026 update, now covering 150+ models, puts it plainly: two years of model releases moved the security pass rate from roughly 55% to roughly 55%.⁶ CodeRabbit's analysis of 470 real open-source pull requests found AI-co-authored PRs carried roughly 1.7x more issues than human-only ones, and were 2.74x more likely to introduce XSS.⁷ Sonar's lab study makes the sharpest version of the point: when one leading model improved its benchmark pass rate by 6.3%, its high-severity bug rate rose 93%.⁸

It inflates developer confidence

Practitioners sense this: DORA's 2025 research found 30% of developers report little to no trust in AI-generated code, even as 90% use AI at work.¹¹ The result is an uneasy equilibrium where output volume grows, formal controls lag, and individual judgment carries the difference.

Staging does not catch it

In a 2026 survey of 200 senior SRE and DevOps leaders at large enterprises, 43% of AI-generated code required manual debugging in production after passing QA and staging tests, and not one respondent said they were very confident that AI code behaves correctly once deployed.¹² Pre-production gates were designed for code written by someone with a mental model of the system. AI code satisfies the tests it can see and fails on the intent it cannot.

When it reaches production systems

Why "review everything harder" fails

The instinctive response to all of the above is to add human review, but the capacity for that does not exist. Telemetry from 8.1 million pull requests shows AI-generated PRs already wait 4.6x longer for first review, and their acceptance rate is 32.7% versus 84.4% for manual PRs.¹⁴ Review capacity is the scarcest resource in an AI-accelerated organization. A governance model that spends it uniformly, on every change regardless of risk, guarantees both a bottleneck and reviewer fatigue on exactly the changes that deserve attention.

The alternative is to spend review where risk lives and remove entire risk categories structurally. Sections 03 through 05 cover that alternative: cutting off secrets exposure, setting autonomy by change class, and writing the policy that encodes both.

The secrets problem

Of everything AI tools change about security posture, credentials exposure is the most measurable, and the numbers are moving the wrong way. GitGuardian's 2026 telemetry across public GitHub is the reference dataset.¹⁵

AI-service credentials themselves grew 81% year over year as teams wired up model providers and agent frameworks, and eight of the ten fastest-growing leak detectors were tied to AI services.¹⁵ The mechanism is mundane: AI tools read whatever the repository and their configuration give them, and they reproduce patterns they see. If credentials are reachable, they end up in generated code, in commits, and in context sent to third parties.

The exposure map

Across all four rows, scanning and training reduce how often leaks happen, and only removing credentials from the places AI can read eliminates the class. Section 07 covers how to do that removal.

How much autonomy should agents have?

The question now facing engineering organizations is what an agent may do without a human in the loop, and the answer should depend on what is being changed rather than on which team is asking. Five levels cover the practical range:

Most organizations today run everything at level 2 and exhaust their reviewers, or let individual teams drift to level 4 without deciding to; both are policy failures. The workable pattern is an autonomy ceiling per change class:

The cautionary tale for skipping this exercise: 33% of infrastructure teams say they would apply AI-generated HCL directly to production without any review.¹⁶ That is level 5 autonomy on the highest-blast-radius change class, adopted by default rather than by decision. DORA's finding frames the payoff of doing it deliberately: AI amplifies the system around it, and the organizations that profit are the ones whose control systems were designed for it.¹¹

Writing the policy

The 18% of organizations with a policy did not get there by writing long documents. A workable AI development policy fits in a few pages and answers seven questions; everything else is implementation detail. DORA's 2025 guidance for leaders starts in the same place, with "clarify and socialize your AI policies" as its first recommendation.¹¹

Starter rules that hold up in practice

• Every AI-assisted change is labeled as such in commit or PR metadata. Attribution is the precondition for every other control on this list.
• AI tools never hold production credentials, enforced through architecture rather than through instructions to the tool (section 07).
• Autonomy ceilings attach to change classes, not to teams or tools. A new agent inherits the existing ceilings.
• Treat review capacity as a budget. If agent output exceeds what humans can meaningfully review, lower the autonomy ceiling or raise the automated gates rather than letting review quality silently degrade.
• Every agent action has a named human owner, so accountability for any change traces to a person.
• Incident postmortems record whether AI was involved in the change and in the diagnosis. The ceilings move based on that record.

SOC 2, ISO 27001, and the EU AI Act

Engineering leaders keep asking what their auditors expect for AI-generated code, and as of mid-2026 there is no authoritative standard to point them to. Schellman, one of the largest SOC 2 audit firms, wrote in April 2026 that "we have nothing authoritative to cite from the AICPA at this time." NIST's secure-development guidance for AI (SP 800-218A) governs building AI systems, not code written by AI, and its agent-focused control overlays are still drafts.¹⁷ In the absence of a standard, auditors will judge how convincingly your existing controls extend to AI-assisted changes.

The regulatory clock

Most engineering organizations are deployers of AI systems rather than providers, which keeps their direct obligations modest. For coding tools specifically, the Commission's draft Article 50 guidelines (May 2026) exempt generated source code from the AI-content marking obligation, while natural-language output from the same tools, such as documentation, remains in scope. It is draft guidance, but it is the first regulatory line drawn through AI-generated code.¹⁸ The near-term exposure is indirect: data protection law already applies when AI tools read production credentials and regulated data, and customers' security questionnaires are already asking AI-governance questions that the 18% can answer and the 82% cannot.

What your auditor will ask

• Can you identify which production changes were AI-generated or AI-assisted?
• Who approved each change, and does the approval depth match your stated policy?
• What could the AI read at the time it produced the change? Could it access credentials or regulated data?
• How do you detect, attribute, and roll back a defective AI-assisted change?
• Does your incident process record AI involvement, and is there evidence the findings feed back into policy?

Every question maps to a control principle that predates AI: change management, least privilege, auditability, and incident response. The organizations that answer these questions well are the ones whose architecture makes the answers true by default, which is the subject of the next section.

Governance by construction

Every control in this guide comes in two versions: one that depends on human attention, and one the architecture enforces. At the output volume agents produce, only the second kind holds. Policies, training, and scanning reduce the frequency of failures, while removing the failure surface eliminates the class.

This is the model Encore implements: infrastructure semantics live in the application code as typed declarations, the platform provisions and operates the resources, and credentials and infrastructure state never enter the repository. AI tools, including agents, work in the one place they measurably perform well, application code, inside guardrails that do not depend on human attention. The compliance conversation changes accordingly: "the AI never had access to production credentials" becomes an argument an auditor can verify by construction rather than a promise backed by training records.

Getting started

Answer each question yes or no. Where the noes cluster matters more than how many there are.

About Encore

Encore is a development platform for the AI era, built for a world where AI multiplies software delivery 10–100x rather than making each developer slightly faster. Developers and AI agents declare the infrastructure they need — databases, queues, buckets, cron jobs — directly in ordinary TypeScript or Go, and Encore provisions it in your own AWS or GCP account.

The same application model runs locally, in preview environments, and in production, so changes are validated against real infrastructure before they reach the production loop. There is no separate Terraform layer for anyone, human or agent, to write and keep in sync.

01import { api, SQLDatabase, Topic, Bucket } from "encore.dev";
02 
03// declare what you need, Encore provisions it
04const db = new SQLDatabase("orders");
05const events = new Topic<OrderEvent>("orders");
06const receipts = new Bucket("receipts");
07 
08export const create = api({ method: "POST" }, async (o) => { ... });

$ git push encore
✔ Building application graph
✔ Provisioning Postgres (RDS) · Pub/Sub (SNS+SQS) · Object Storage (S3)
✔ Deploying 6 services to your AWS account (ECS Fargate)
✔ Wiring distributed tracing + metrics
 
→ Live at https://staging-orders-r2qa.encr.app· 42s
→ Dashboard at https://app.encore.dev/orders

Why this matters for this guide

• The secrets problem (section 03): credentials and infrastructure state live in the platform, outside the repository and outside AI reach, so the tools that write the code never see production secrets.
• Governance by construction (section 07): typed resources and least-privilege defaults mean unsafe configuration fails at compile time rather than in an audit.
• SOC 2, ISO 27001, and the EU AI Act (section 06): an automatic audit trail and "the AI never had access to production credentials" is the strongest control argument available.
• How much autonomy (section 04): the platform, not the reviewer, enforces what an agent can change — so autonomy scales without widening the blast radius.