The review bottleneck broke first
For most of my career the security model of a software team rested on a quiet assumption: a human wrote each line, and another human read it before it shipped. That assumption is gone. On the teams we work with, agents now draft the majority of routine code, and people who were never in the engineering org — designers, analysts, product managers — open pull requests directly. The recent wave of agent-native tooling, where an assistant lives inside the repository and can branch, edit, and push on request, only accelerates it.
The OWASP GenAI Security Project put numbers to the trend in its 2026 report, State of Agentic AI Security and Governance (v2.01). Of 53 agentic projects it tracks, 28 are coding agents, and the five fastest-growing tools in the survey are all code assistants. That same report notes something less comfortable: the coding agents shipping fastest are also the ones accumulating the most security advisories. One popular assistant carried 22 open advisories at the time of writing. Tools that rewrite your codebase are themselves a growing attack surface.
So the interesting question for a security architect is not whether to allow AI in the pipeline. That decision has usually already been made, often without a policy behind it. IBM data cited in the same OWASP report found only 37% of organisations have any control in place to detect unsanctioned AI use. The real work is redrawing the software development lifecycle so it stays defensible when a machine writes the code and a non-specialist approves it.
What the threat model actually looks like now
The old DevSecOps playbook assumed the developer was a trusted, authenticated human whose intent could be reasoned about. An AI agent breaks that assumption in four practical ways, and each one maps to a control you probably already own but have not pointed at this problem yet.
The agent behaves like an over-permissioned insider
An assistant with repo write access, a CI token, and the ability to call external tools has more standing privilege than most junior engineers. It does not get tired, it does not ask why a task is unusual, and it will follow instructions that arrive from wherever it happens to read them. Cloud Security Alliance researchers documented exactly this with a widely used AI GitHub Action: content in an issue or comment could steer the agent into running attacker-chosen steps inside the CI job. Treat the agent as an identity, give it its own credentials, and scope those credentials to the minimum it needs for the task in front of it. This is least privilege, applied to a non-human actor.
Prompt injection is a supply-chain vector, not a chatbot curiosity
When people first heard about prompt injection they filed it under "amusing ways to make a chatbot misbehave." In a build pipeline it is nothing of the sort. If an agent reads a dependency's README, a linked issue, or a web page as part of doing its job, that text can carry instructions. VentureBeat reported a 2026 case in which three separate coding agents leaked secrets after processing a single injected prompt. OWASP's own tracking puts prompt injection at the top of agentic failure modes seen in production. The lesson is old wine in a new bottle: never let untrusted input reach a privileged interpreter without a boundary between them.
Secrets and blast radius
Agents are prolific readers of your environment. They scan files, expand context, and helpfully suggest configuration. That behaviour turns a hardcoded key or a broad cloud role into a much faster path to compromise than it was when a human had to go looking. We have seen engagements where the fix was not a clever new tool but the boring discipline of moving secrets into a vault, rotating anything that had touched a repo, and cutting a wildcard IAM policy down to the three actions it actually used.
Provenance you can no longer take for granted
When a human authored a commit, the git history told you who to ask. When an agent authors it, "who wrote this" needs a different answer. You want to know which model, which prompt, which tool invocations, and which human sponsored the change. Without that record, incident response gets slow and audit evidence gets thin — and in regulated sectors, thin evidence is its own finding.
A control model that survives contact with production
The shift that matters most is where verification lives. When one person could read every diff, review was the control. At current volume, reading every line does not scale, and pretending otherwise just produces rubber-stamp approvals. The teams handling this well move their assurance to two places: automated guardrails that run on every change without a human in the loop, and human judgement spent on the plan and the risky twenty percent rather than the whole diff. A Monaco engineering write-up framed it well — let machines handle the grunt review so specialists spend their attention where judgement is actually required.
Here is how the specific controls shift when you move from a human-authored lifecycle to an agent-authored one.
ConcernHuman-authored SDLCAI-native SDLC
Primary assurance
Peer review of the diff
Automated policy gates plus human review of the plan and high-risk changes
Identity
Developer's SSO account
A distinct, least-privilege machine identity per agent, separately auditable
Untrusted input
Rarely reaches a build with authority
Reaches the agent constantly; needs isolation and input boundaries
Secrets
Managed, occasionally sloppy
Vaulted and short-lived by default; agents never see long-lived keys
Provenance
git blame
Model, prompt, tools, and sponsoring human recorded per change
Style and standards
Caught in review comments
Encoded as lint and policy-as-code so they fail the build, not a person's afternoon
Supply chain
Dependency scanning
Scanning plus artifact signing and build provenance (SLSA-style attestations)
None of the right-hand column is exotic. Signed artifacts, policy-as-code, vaulted secrets, and scoped identities are all mature practices. What is new is the requirement to apply them consistently to code paths that used to have a human gatekeeper and no longer do.
Encode the guardrails, don't ask people to remember them
A guardrail that depends on a reviewer remembering to check for it is not a control, it is a hope. The most effective pattern we deploy is to turn every recurring review comment into something that runs automatically. If reviewers keep flagging the same insecure pattern, it becomes a lint rule or a semgrep policy. If a change touches authentication, payment handling, or personal data, a policy gate flags it for mandatory human review no matter who — or what — opened the pull request. Secret scanning runs pre-commit and again in CI, because agents will occasionally paste a credential into a file with complete confidence.
The build itself should be sandboxed with the assumption that the agent inside it may be acting on someone else's instructions. That means no ambient cloud credentials in the job, no outbound network access it does not need, and ephemeral tokens that expire when the job does. If a prompt-injection payload does land, the damage it can do should be bounded by what that sandbox was permitted to touch, not by what your production estate would allow a trusted engineer.
Mapping this to the standards you already answer to
Most organisations we advise are not starting from zero on governance. They already hold, or are working toward, recognised frameworks, and the good news is that AI-native development slots into those rather than requiring a parallel regime. NIST published SP 800-218A in 2024, an addendum to the Secure Software Development Framework specifically for generative AI and dual-use models. If you already run your pipeline against SSDF (SP 800-218 v1.1), 800-218A extends the same control families to cover model and agent risk — you are adding practices, not rebuilding.
The mapping is fairly direct. ISO 27001 Annex A controls for access management and secure development apply cleanly to machine identities once you treat an agent as an identity. PCI-DSS requirements around change control and least privilege do not care whether the change came from a person or a model, only that it was authorised, reviewed against defined criteria, and logged. CIS Benchmarks give you the hardened baseline for the runners and containers your agents execute in. For supply-chain integrity, the SLSA framework's build-provenance levels give you a concrete target for signing and attesting artifacts, which is where much of the real-world agent risk actually lands. OWASP's Top 10 for LLM Applications and its agentic security work give your developers a shared vocabulary for the failure modes.
The practical value of naming these frameworks is that it turns an anxious "is our AI use safe?" conversation into a set of testable control statements an auditor and a board can both follow. That is the version of this problem worth solving.
A checklist you can run this quarter
If you want somewhere concrete to start, this is the sequence we tend to run in the first weeks of an engagement. None of it requires a large budget or a new platform.
- Inventory where AI agents already touch your codebase and pipeline, including the unsanctioned uses. You cannot govern what you have not found.
- Give each agent its own machine identity with scoped, short-lived credentials. Kill any shared or long-lived tokens the agents currently use.
- Move all secrets into a managed vault, rotate anything that has been exposed to a repo, and set CI secret scanning to fail the build.
- Sandbox agent and build execution: no ambient production credentials, least-privilege network egress, ephemeral runners.
- Define which change types (auth, payments, personal data, infrastructure-as-code) always require human review, and enforce it with a policy gate rather than a convention.
- Turn your most common review findings into automated lint and policy-as-code so they fail fast and stop consuming reviewer attention.
- Record provenance for agent-authored changes: model, prompt or task, tools invoked, and the sponsoring human.
- Add artifact signing and build-provenance attestations so a tampered or agent-injected build cannot pass unnoticed.
- Map the above to your framework of record (SSDF/800-218A, ISO 27001, PCI-DSS as applicable) and keep the evidence where your next audit will look for it.
Work through that list and you have closed most of the gap between "we let agents write code" and "we can defend how we let agents write code." The remaining work is keeping it current as the tools change, which they will, weekly.
How Aydahwa Enterprise Can Help
We have spent 25 years securing infrastructure and software delivery for organisations that cannot afford to get it wrong — banking, telecom, and critical national infrastructure among them. Bringing AI agents into a regulated pipeline is the same discipline we have always practised: identity, least privilege, isolation, provenance, and evidence, applied to a new kind of actor. Our work is grounded in ISO 27001, PCI-DSS, SOC 2, the NIST Cybersecurity Framework, and CIS Benchmarks, and led by Microsoft Cybersecurity Architect Expert certified practitioners.
If your teams are shipping AI-assisted code faster than your controls have caught up, we can help you close that gap without slowing delivery to a crawl. Start with our free cybersecurity self-assessment to see where you stand, or work through the cybersecurity readiness checklist with your engineering leads. For a DevSecOps review of your pipeline, our cybersecurity services and cloud security and migration teams can assess your agent identities, secrets handling, and build integrity against the standards your auditors use. When you want infrastructure and delivery running the same way day to day, our managed IT support keeps the controls in place rather than letting them decay.
To scope a DevSecOps or AI-pipeline security review for your environment, get in touch with our team.
