In 2026 the question is no longer whether your team ships machine-written code. It does. The question is whether anything in your pipeline can tell the difference, and whether controls designed for human authors still hold when the author produces a thousand lines before lunch and never gets tired, bored, or suspicious.
This is a control list for lean teams: pre-seed and seed startups with one to twenty engineers, no security hire, and an AI coding assistant or agent already wired into the daily loop. It is ordered by what I would implement first. It is not an argument about whether to adopt these tools. That argument is finished.
Most writing on this subject ends at "review AI-generated code carefully." That advice fails on arithmetic. Review capacity is the one input that generation speed does not increase, so the useful controls are the ones that scale without a matching increase in human attention. Where I am giving practitioner judgement rather than citing a source, I have labelled it inline.
Quick context: what the 2026 measurements actually show
The headline number from Veracode's 2026 GenAI Code Security Report is that roughly 44 percent of AI code generation tasks introduced a risky security vulnerability, putting the average security pass rate across tested models at 56 percent. The best performer reached 68 percent. More than half of the models tested sat between 50 and 53 percent. Reasoning models averaged 56 percent against 51 percent for non-reasoning models, and coding-specialised models did not beat general-purpose ones in any meaningful way.
The distribution matters far more than the average, and this is the part most summaries drop. The same report puts the average pass rate for SQL injection at 83 percent and for cryptographic algorithm selection at 87 percent. Cross-site scripting sits at 15 percent. Log injection sits at 12 percent.
That gap is the single most actionable fact in this post. Models have absorbed the vulnerability classes that dominated security training material for fifteen years. They have not absorbed output encoding or log handling, which are contextual: they depend on where the data lands, not where it came from.
Takeaway: your machine-written code does not fail randomly. It fails in a predictable, narrow band. That makes it targetable with tooling rather than with vigilance.
1. Mark AI-generated code at commit time, or you cannot measure anything
Before any control, you need to know which changes came from a model. Without that, every claim you make later about AI code quality in your own repository is a vibe. With it, you can compute change failure rate, revert rate, and post-merge defect density sliced by author type, and you can find out whether the numbers above hold in your codebase or not.
The cheapest mechanism is already in git. A commit trailer, parsed by git interpret-trailers, is a structured key-value line in the commit message that survives rebases and is trivial to query. Most agentic coding tools already write a Co-Authored-By trailer by default. Keep it. Do not strip it in a squash-merge template, which is the usual accidental way teams destroy this signal.
Layer a pull request label on top for the human-visible view, then once a month diff the revert rate between labelled and unlabelled pull requests.
Practitioner opinion: teams that skip this step spend the next year arguing about AI code quality from anecdote. Teams that do it stop arguing within a quarter, because the data settles it either way. It costs about an hour to set up.
Takeaway: provenance first. It is the control that makes every other control on this list measurable.
2. Tune static analysis to the classes models actually fail
Given a 15 percent pass rate on cross-site scripting and 12 percent on log injection, a generic SAST configuration running at default severity is not the right shape. You want depth on a narrow set of CWEs rather than breadth at low confidence, because breadth at low confidence produces the alert volume that gets a scanner switched off in month two.
Concretely: enable and make blocking the rule families covering CWE-79 (cross-site scripting), CWE-117 (improper output neutralisation for logs), CWE-116 (improper encoding), and CWE-611 (XML external entity) in whatever scanner you already run. CodeQL is free for public repositories and included in GitHub Advanced Security for private ones. Semgrep's open-source engine runs anywhere and takes custom rules in a readable YAML syntax, which matters when you need a rule for your own logging wrapper.
Leave the rest of the ruleset non-blocking and route it to a weekly digest. We took the same approach when comparing scanners for container images in Trivy vs Snyk vs Grype: a tuned scanner that runs on every commit beats a comprehensive one that runs never.
Takeaway: match your blocking rules to the measured failure distribution, not to the vendor's default profile.
3. Close the resolver: slopsquatting is a naming attack, not a code attack
The supply-chain risk from AI coding tools is not mainly that they write insecure code. It is that they invent dependency names, and attackers register those names. A Cloud Security Alliance research note summarising a USENIX Security 2025 study reports 2.23 million generated code samples across 16 models, of which 440,445 (19.7 percent) contained at least one hallucinated package name, spanning 205,474 unique fabricated names. Open-source models averaged 21.7 percent, commercial models 5.2 percent.
The number that turns this from noise into an attack is repeatability. When researchers re-ran identical prompts ten times, 43 percent of hallucinated names appeared on every single run. An attacker does not need to guess. They run a few dozen prompts, note the names that recur, and register them.
Four controls close most of this at the resolver, where it is cheap. Commit your lockfile and install with integrity hashes only (npm ci, pip install --require-hashes, poetry install). Turn on a release cooldown: npm's minimumReleaseAge setting, pnpm's equivalent, Yarn's npmMinimalAgeGate, or Bun's minimumReleaseAge, all of which refuse versions published in the last day or week. Disable dependency install scripts by default. And forbid the agent from installing packages autonomously: new dependencies go through a human-approved pull request, always.
Takeaway: the fix is a resolver policy, not a review policy. No human reads a package name closely enough to catch python-requests masquerading as requests at 4 pm on a Friday.
4. Treat the agent's token as the crown jewel
When AI coding agents were attacked in 2026, the target was consistently credentials rather than the model. Microsoft's security team published a detailed analysis of the Claude Code GitHub Action in June 2026 that is worth reading in full. The short version: the Bash tool ran inside a Bubblewrap sandbox with environment variables scrubbed, but the Read tool did not get equivalent treatment, so an injected instruction to read /proc/self/environ exposed the unscrubbed API key and other workflow secrets.
Two structural lessons. First, sandboxing has to be uniform across every tool the agent holds, because the agent will happily route around the hardened one to the soft one. Second, the blast radius of any agent is exactly the set of permissions on its token, and nothing else.
So scope hard. One credential per workflow, never a shared organisation-wide key. Read-only where the job only reads. Short expiry with OIDC federation instead of long-lived static keys, which is the same argument we made for human and machine identities in the IAM Access Analyzer findings post. Monitor provider-side usage for anomalies, because a stolen key usually shows up as traffic from a new location long before it shows up as a bad commit.
Takeaway: assume the agent's token will leak, then ask what an attacker holding it could actually do. Shrink that answer until it is boring.
5. Every issue, comment, and doc your agent reads is untrusted input
The Microsoft analysis describes payloads hidden in HTML comments inside GitHub issues and pull requests. The agent read them as instructions because, to a language model, there is no structural difference between the task you assigned and text it encountered while doing the task. That is the whole problem, and it is LLM01 in the OWASP Top 10 for LLM Applications for a reason.
For a lean team, the practical trust boundary is a list. Untrusted: issue bodies and titles, pull request descriptions, review comments, external documentation the agent fetches, dependency README files, web search results, and anything an MCP connector returns. We covered why the last of those is genuinely dangerous in the MCP server security post. Trusted: your repository's own committed source, your CI configuration, and the task you actually typed.
Microsoft's recommended countermeasure is what they call the Agents Rule of Two: a workflow processing untrusted input should never simultaneously hold access to sensitive systems and the ability to communicate externally. For a startup that means the agent triaging inbound issues is not the agent holding deploy credentials.
Takeaway: name your untrusted surfaces explicitly in the system prompt, and enforce the separation architecturally rather than by asking the model nicely.
6. Deterministic gates beat instructions in a system prompt
A system prompt is a strong preference, not a control. Anything you genuinely need to hold must sit outside the model, in a system that cannot be argued with. This is the single most common design error I see when reviewing early-stage AI pipelines: the team writes "never commit secrets" into the prompt and treats the risk as handled.
The deterministic layer for a code pipeline is unglamorous and already exists. Branch protection with repository rulesets, required status checks that must pass before merge, and a CODEOWNERS file that forces a named human on paths that matter. Secret scanning with push protection, so a leaked key is rejected at the git layer rather than found later. Signed commits if you can manage the key hygiene.
The critical configuration detail: required checks must be required for the agent's identity too. A bot account with admin rights that can bypass branch protection turns your entire gate set into decoration, and this is a genuinely easy mistake to make while debugging a workflow at midnight.
Takeaway: if a control lives only in a prompt, it is documentation. Move it into required checks, rulesets, and file ownership.
7. Sandbox the agent's blast radius, not just its output
Reviewing what the agent wrote is a partial control, because a coding agent also executes. It runs test suites, installs packages, calls APIs, and reads files across your machine or runner. The output review catches bad code; it does not catch a malicious postinstall script that ran during npm install three steps earlier.
The controls here are the standard runner-hardening set, applied to a new consumer. Run agents in ephemeral containers or VMs that are destroyed after each job. Scope filesystem write access to the working directory. Put an egress allowlist on network access, so an exfiltration attempt fails at the firewall rather than at the model's judgement. GitHub's security hardening guide for Actions covers most of the mechanics, and the same reasoning applies to a local agent on a laptop.
This is also where the lesson from the 2026 scanner compromises applies directly: we wrote about hardening CI after the Trivy and KICS incidents, and the structural point is identical. Any tool with credentials inside your pipeline is part of your attack surface, whether it is a scanner or an agent.
Takeaway: the agent is a workload. Give it the isolation you would give any untrusted workload, and no more network than the job needs.
8. The SBOM stops being paperwork on 11 September 2026
If you sell software into the European Union, the Cyber Resilience Act changes your timeline this year. Its vulnerability and incident reporting obligations bind from 11 September 2026, with the essential requirements, including the machine-readable software bill of materials, following on 11 December 2027. The reporting clock is tight: a 24-hour early warning to ENISA and the relevant national CSIRT, a 72-hour full notification, and a 14-day final report once a patch exists for an actively exploited vulnerability.
Here is the connection to AI-generated code that is easy to miss. You cannot meet a 24-hour warning obligation if you do not know what is in your product, and machine-written code expands your dependency surface faster than any manual process tracks it. The SBOM is not the compliance deliverable here; it is the operational prerequisite for answering "are we affected" in hours rather than days.
Generate one per build with Syft, CycloneDX, or your build tool's native support, store it as a release artifact, and diff consecutive SBOMs in CI. An unexplained new transitive dependency is one of the highest-signal, lowest-effort alerts a small team can run.
Takeaway: even outside EU scope, build the SBOM now. It is how you answer the next Log4j-shaped question before your customers ask it.
9. Ration human review by blast radius, not by diff size
The last control is a policy, and it is the one that decides whether the rest survive contact with a shipping deadline. Human review is your scarcest resource, so spend it where automation is weakest and consequences are largest, and stop pretending you will read everything.
Mandatory human review, no exceptions: authentication and authorisation logic, cryptography and key handling, anything touching payment or personal data, infrastructure-as-code, CI/CD configuration, and every new or upgraded dependency. That list maps closely to the code review practice in the NIST Secure Software Development Framework, and it is short enough that a two-person team can actually hold the line.
Everything else: automated gates carry it. Rendering paths and logging get the tuned SAST rules from control 2. Business logic gets tests. Refactors get the type checker. If a change fails none of those and touches nothing on the mandatory list, merging it without a line-by-line human read is a defensible engineering decision, not negligence.
Practitioner opinion: the teams that get hurt are not the ones that automate review. They are the ones that keep a "review everything" policy on paper while quietly rubber-stamping in practice, because that produces neither the coverage nor the honest picture of where the coverage stops.
Takeaway: write down the mandatory-review list. An explicit narrow policy that holds beats a broad one that everyone privately ignores.
Summary: the nine controls at a glance
| # | Control | Stops | Effort |
|---|
| 1 | Commit trailers plus PR labels | Flying blind on AI code quality | 1 hour |
| 2 | SAST tuned to CWE-79, 116, 117, 611 | The classes models measurably fail | Half a day |
| 3 | Lockfiles, hashes, release cooldown, no agent installs | Slopsquatting and hallucinated packages | Half a day |
| 4 | Per-workflow scoped short-lived tokens | Credential theft via the agent | 1 day |
| 5 | Declared trust boundary, Agents Rule of Two | Prompt injection from issues and docs | Design decision |
| 6 | Rulesets, required checks, CODEOWNERS, push protection | Controls that exist only in a prompt | Half a day |
| 7 | Ephemeral runners, scoped filesystem, egress allowlist | Execution-time compromise | 1 to 2 days |
| 8 | SBOM per build, diffed in CI | Not knowing what you ship | Half a day |
| 9 | Written mandatory-review list | Review theatre | 1 hour |
What to do at your stage
Pre-seed, one to five engineers: controls 1, 3, and 4. Provenance marking, a locked resolver with a cooldown, and scoped tokens. Roughly two days of work total, and they close the paths that end in an account takeover rather than a bug. Skip the rest until you have a second engineer who can maintain it.
Seed, five to twenty engineers: add 2, 6, and 9. At this size, enough people are merging that discipline stops scaling and policy has to take over. The tuned SAST rules and the CODEOWNERS file are what let you keep shipping fast without the review queue becoming the bottleneck.
Series A and beyond: add 7 and 8, and start treating agent identities as a managed inventory with owners, rotation schedules, and audit trails, the same way you treat human accounts. If you sell into the EU, the September 2026 reporting obligation makes control 8 a deadline rather than a preference.
If you want a second pair of eyes on this
MatrixGard runs a free 20-minute cloud and pipeline posture review for pre-seed and seed founders. Bring your repository and CI setup and we will walk this list specifically: what your agent's token can reach, whether your resolver is actually locked, and which of the nine controls is worth your next two days. My honest read, no NDA required for the first conversation. Send a note.
Avinash S is the founder of MatrixGard. Fractional DevSecOps for pre-seed and seed startups across India, the GCC, Singapore, the UK, and the US. Almost a decade of building, breaking, and securing cloud infrastructure for fintech, healthtech, and SaaS workloads.
Methodology note. Vulnerability rates and per-class pass rates are taken from Veracode's 2026 GenAI Code Security Report. Package hallucination figures (2.23 million samples, 16 models, 19.7 percent, 43 percent repeatability) come from the USENIX Security 2025 study as summarised in the Cloud Security Alliance research note of April 2026. The agent credential-theft scenario, the sandboxing gap between the Bash and Read tools, and the Agents Rule of Two are attributed to Microsoft's June 2026 security analysis. Cyber Resilience Act dates come from the European Commission's CRA page. Tooling behaviour reflects current vendor documentation for CodeQL, Semgrep, pnpm, and GitHub Actions. Review scoping is informed by the NIST SSDF. Effort estimates, the stage recommendations, and the ordering of controls are practitioner judgement, not vendor or regulatory guidance. Model behaviour, package manager defaults, and regulatory dates change; verify against current sources before building policy on them.
