Securing AI-Generated Code: The DevSecOps Controls That Matter When Agents Write Your Software

The cost of writing code fell. The cost of trusting it did not.

A capable model now turns a sentence into a working function, a full component, or a small application in seconds, for pennies. That shift has been good for velocity. It has also quietly moved the hard part of software delivery downstream, into the work that happens after the code exists: running it safely, proving it works, deciding who is allowed to ship it, and keeping a record of what happened. The platforms most teams already use have reorganised themselves around exactly those problems. GitHub built a control layer to coordinate fleets of agents inside the pull request workflow. Vercel wraps generated code in isolated microVMs and real deployment gates. Replit drives a self-testing loop to catch code that looks finished but breaks the moment a user touches it.

Read those moves together and a pattern shows up. Generation became cheap, so the value, and the risk, moved into the engineering that surrounds it. For a security team, that reframing matters more than any individual product announcement. When a human writes a line of code, dozens of small controls fire without anyone thinking about them: peer review, the author's judgement, an audit trail that ties a change to a person. When an agent writes and runs that same code, several of those controls quietly stop applying. We have walked into engagements where an AI assistant had merge rights, a long-lived cloud token, and no logging that distinguished its commits from a developer's. Nobody decided that on purpose. It accumulated one convenient default at a time.

The public incident pattern is already familiar: credentials pasted straight into prompts, private data pushed to the public internet, a production database dropped by an agent acting on an ambiguous instruction, and in more than one case an audit trail left empty. None of that is exotic. It is the predictable result of treating machine-generated code as if a trusted colleague had written it. This article lays out the controls we put in place so that AI-assisted development stays inside the same risk tolerance a bank or a telecom operator already lives with, mapped to the standards those organisations are audited against.

Treat every line an agent writes as untrusted until proven otherwise

The single most useful mental shift is to stop thinking of agent output as "our code that needs review" and start thinking of it as "third-party code of unknown quality that happens to arrive very fast." That framing changes where you spend effort. You still review, but you also contain.

Containment starts with where the code runs. Vercel's choice to execute generated code inside a Firecracker microVM is the right instinct, and it generalises well beyond one vendor. Code an AI wrote is, by definition, code you have not yet read. Running it needs a boundary strong enough to hold a mistake, whether that mistake is a hallucinated shell command, a runaway loop, or a deliberate payload injected through a poisoned dependency. In our own build pipelines we hold to a few rules that have earned their place:

• Ephemeral, single-use execution environments. Every agent task starts from a clean workspace and is destroyed afterwards, the way GitHub's cloud agent runs each task in a throwaway Linux environment. A compromised run cannot poison the next one because there is no next one on the same host.
• Strong kernel-level isolation for untrusted execution. Firecracker microVMs and gVisor both give you a far harder boundary than a shared container on a shared kernel. For anything touching customer data or a production network path, that boundary is not optional.
• Egress control by default. An agent sandbox should reach the package registry and the model endpoint it needs, and nothing else. Default-deny outbound rules are the difference between "an agent tried to exfiltrate a secret" being a blocked log line and being a breach notification.
• No standing production credentials in the build path. The sandbox gets short-lived, narrowly scoped tokens minted at run time, never a copy of the keys that can drop a database.

These are the same isolation principles CIS Benchmarks and the CIS Controls have pushed for years, applied to a workload that did not exist when most build pipelines were designed. The tooling is new. The control objective is old.

Governance belongs in version control, not in a wiki nobody reads

One detail in GitHub's design is worth copying regardless of which vendor you use: governance expressed as version-controlled configuration. Rules that used to live in a team's collective memory, the preferred logger, the required testing style, the libraries that are off-limits, get written into files the agent must honour, and administrators get a control plane with security policies, audit logging, and model-access controls in one place.

For a regulated client, that is the mechanism that makes agentic development auditable at all. If your governance is a Confluence page, an auditor has no way to prove it was enforced on any given change. If it is a checked-in policy file plus an immutable log, you can show the control operating on the exact commit in question. That is the evidence ISO/IEC 27001:2022 expects for access control (Annex A 5.15, 8.2, 8.3) and secure development (8.25 through 8.28), and it is what a NIST Cybersecurity Framework 2.0 assessment looks for under the Govern and Protect functions.

Three governance controls carry most of the weight in practice. First, least privilege for the agent identity itself: an agent is a non-human principal and should hold its own scoped credential, not borrow a developer's. Second, a hard human gate on anything that reaches production. An agent may open a pull request; a person, or a policy engine with a named owner, approves the merge. Keeping that quality gate human is what preserves separation of duties, a control PCI-DSS and every financial regulator we work with treat as non-negotiable. Third, logging that attributes every action to the specific agent, model version, and prompt that produced it. When something goes wrong at 2 a.m., "which agent, running which model, acting on whose instruction" is the first question, and an empty audit trail is how a contained incident becomes an unbounded one.

MCP made tool access easy, which is exactly why it needs governing

Every one of these platforms now speaks the Model Context Protocol, and for good reason. Before MCP, wiring several AI applications to several external tools meant a custom integration for each pairing, and the count grew fast. MCP replaces that with one standard: a tool provider builds a single server, and any compliant agent can use it. A server can expose actions the model calls, data it reads, and reusable prompt templates.

The engineering win is real. So is the security consequence, and it is easy to miss in the excitement. A shared entry point concentrates risk. When many agents reach many tools through one protocol, the question of which servers an agent may connect to, and at what permission level, stops being a footnote and becomes a central access-control decision. An MCP server that can query a database, move money through a payments API, or open a network socket is a privileged component. Treat it like one.

The controls we insist on before an MCP server goes anywhere near a real system: an explicit allow-list of approved servers, so an agent cannot reach an arbitrary endpoint someone enabled with a single click; per-server credential scoping, so a compromised or misbehaving server holds the minimum it needs and nothing more; short-lived tokens over standing secrets, ideally brokered through OIDC federation or a secrets manager such as HashiCorp Vault rather than pasted into a config; and monitoring of tool calls the same way you monitor API traffic, because that is what they are. Stripe's own agent tooling is a good example of the design done carefully, with credentials scoped so an agent can set up a payment flow without holding keys that could drain an account. The lesson is that the safe version of this is possible, but it is a design choice, not a default.

The supply chain is where AI-generated code quietly bites

Ask an agent for code and it will confidently reach for dependencies. Some of those packages are fine. Some are outdated and carry known CVEs. And some do not exist at all, until an attacker notices the model keeps inventing the same plausible package name and registers it with a malicious payload inside. That last pattern has a name now, slopsquatting, and it is a direct consequence of models hallucinating imports. A human might catch an unfamiliar package. An autonomous loop installing its own dependencies at machine speed will not.

So the software supply chain controls that were already best practice become mandatory when an agent is doing the importing. The ones we implement:

• Generate an SBOM for every build. A CycloneDX or SPDX software bill of materials tells you exactly what shipped, which is the precondition for responding to the next Log4Shell in hours instead of weeks.
• Pin and verify dependencies. Lockfiles, hash pinning, and an internal proxy registry stop an agent from silently pulling a new or swapped package. New dependencies go through review, not straight into main.
• Sign and attest what you build. Sigstore for signing and the SLSA framework for provenance let you prove an artefact came from your pipeline and was not tampered with in transit. in-toto attestations tie the chain together.
• Scan continuously. Software composition analysis for known-vulnerable dependencies, static analysis for the generated code itself, and secret scanning on every commit, because agents leak credentials into code as readily as junior developers do, sometimes more so.

Secret management deserves its own line. The recurring failure mode, credentials pasted into a prompt or hard-coded into generated config, is defeated by never letting a long-lived secret be pasteable in the first place. Centralise secrets in a vault, inject them at runtime, rotate aggressively, and run automated detection that fails the build when a key appears in a diff. This is unglamorous plumbing. It also prevents the specific incidents that make the news.

Verification is a security control, and it has limits

Replit's bet on verification, an agent that generates, runs, tests, and repairs in a loop until tests pass, is genuinely valuable, and it targets a real problem: the feature that looks complete on screen and fails the instant it is used. Automated verification that drives a real browser and checks behaviour the way a user would catches a whole class of defects a static review misses.

Used well, that loop is also a security asset, because a test suite that exercises real behaviour will surface some broken authorisation checks and unhandled inputs. But it is a floor, not a ceiling. Passing tests prove the paths you tested behave as expected. They say nothing about the injection flaw on a path nobody wrote a test for, or the logic error that only appears under a race condition. We treat agent self-verification as one layer, sitting underneath independent security testing, threat modelling for anything handling sensitive data, and periodic penetration testing. The more autonomy you grant an agent, the more weight rests on verification being right, and the more you need a second, independent set of eyes that the agent does not control.

Where each platform bet leaves the enterprise

The three platforms each solved a different piece of the problem. None of them removes the security work an organisation still owns. This is roughly how the responsibilities divide, and where you still have to act:

Platform betWhat it gives youWhat you still own

Orchestration (control layer over many agents)

A governed workflow, audit logging, model-access controls inside pull requests

Defining the policies, scoping agent identities, reviewing the logs, owning the merge gate

Production path (isolated microVMs, deploy gates)

Strong isolation for untrusted code and a real deployment process

Egress rules, secret injection, production credential hygiene, change approval

Verification (self-testing loop)

Automated functional checks and longer autonomous runs

Independent security testing, threat modelling, penetration testing, coverage of untested paths

Interoperability (MCP)

One protocol for any agent to reach any tool

Server allow-listing, credential scoping, tool-call monitoring, permission design

The shared theme reads straight down the right-hand column. The platform owns the surface. You own the policy, the identities, the secrets, and the evidence. That division is stable across whichever vendor a team picks, which is why we anchor client programmes to the control objectives rather than to a product.

A practical checklist for securing agentic development

If you are introducing AI coding agents into a regulated or security-sensitive environment, this is the order we work through with clients:

1. Inventory where agents already run and what they can touch. Most teams underestimate this; start with the credentials and merge rights already granted.
2. Give every agent its own scoped, non-human identity with least privilege. Remove any borrowed developer credentials and any standing production keys from the build path.
3. Run agent-generated code in ephemeral, strongly isolated sandboxes with default-deny egress.
4. Express governance as version-controlled policy plus an immutable, agent-attributed audit log.
5. Keep a human, or a named-owner policy engine, on every path to production. Preserve separation of duties.
6. Allow-list MCP servers, scope their credentials, prefer short-lived tokens, and monitor tool calls like API traffic.
7. Enforce supply chain controls: SBOM per build, pinned and proxied dependencies, signing and provenance, continuous SCA and secret scanning.
8. Layer independent security testing and threat modelling on top of agent self-verification. Do not let the agent grade its own homework alone.
9. Map every one of the above to your framework of record, whether that is NIST CSF 2.0, ISO/IEC 27001:2022, PCI-DSS, or CIS Controls, so the control is auditable, not just present.

How Aydahwa Enterprise Can Help

We have spent 25 years building and securing infrastructure for organisations that cannot afford to guess, across banking, telecom, and critical national infrastructure, where an empty audit trail is a finding and a leaked credential is an incident. Bringing AI coding agents into that kind of environment is not a reason to lower the bar. It is a reason to apply the controls you already trust to a workload that moves faster than the people watching it.

Our team holds credentials including ISO 27001, PCI-DSS, SOC 2, NIST CSF, CIS Benchmarks, and Microsoft Cybersecurity Architect Expert, and we design DevSecOps pipelines that let engineering keep the velocity AI provides without handing away the governance an auditor expects. If you are rolling out coding agents, standing up MCP servers, or trying to work out what your current pipeline actually exposes, we can help you map the risk and put the controls in place.

Start with our cybersecurity services for a DevSecOps and application-security review, or our cloud security and migration practice if the workloads live in the cloud. Managed and ongoing support runs through IT support and managed services. To gauge where you stand today, run the free cybersecurity self-assessment and work through the cybersecurity readiness checklist. When you are ready to talk specifics, contact us and we will scope it with you.