Agentic AI Is Shipping Code. Who Owns The Risk?

Andrea Scaduto is co-founder and CEO of SecureFlag, a secure coding training platform.

gettyNot long ago, much of the discussion in software engineering circles was about whether developers should use AI to write code. Now, the focus is on agentic AI and agents that run commands with minimal human direction.

Gartner put agentic AI at the top of its 2026 cybersecurity trends, warning that the technology is creating new attack surfaces as employees and developers adopt it, and that no-code platforms and vibe coding are speeding up the spread of unmanaged agents, unsecured code and potential compliance violations.​​

Before AI agents, development gave organizations a fairly clear path to accountability. A developer makes the change, a reviewer checks it and the service team owns what reaches production.

The chain is now more complicated when an AI agent takes a feature request and turns it into code for a developer to review. For example, a product manager provides the instructions, the agent generates the change and the developer approves it. If that change exposes customer data, who owns the decision to ship it?

The most practical answer, I’d argue, is the person who approves the merge. Agent-written code becomes the organization’s code once a developer approves it, so that approval can’t be a formality. If the person signing off can’t explain what a change does and why it’s safe, it shouldn’t be deployed.

Customers won’t accept “the AI wrote it” as an explanation, and neither will auditors or regulators. The EU’s Cyber Resilience Act makes this clear by placing responsibility on the organizations that put products on the market.​

It’s certainly beneficial that teams can now produce more software faster, but they don’t automatically gain the capacity to assess it all. More output also means more changes to approve, and less time to give each one proper attention.

Research from The Consortium for Information & Software Quality estimated that the cost of poor software quality in the U.S. was approximately $2.41 trillion in 2022, with accumulated technical debt tracked separately at around $1.52 trillion. As teams produce more code, even a low rate of flawed code can create more technical debt than they can keep up with.

Some of that debt is also security debt, as security vulnerabilities found in production can become entry points for attackers and cost more to fix in the long run.​

​Any approach to governing agentic AI has to start with knowing where it is being used. Gartner’s research mentioned above recommends identifying both sanctioned and unsanctioned AI agents, establishing controls for each and preparing incident response plans for agent-related risks.

It’s harder than it sounds, as agents work in integrated development environment extensions, command-line tools, CI/CD pipelines and business-user platforms. Calling them all “AI coding assistants” can obscure how differently they operate. An agent that proposes a change for review has a very different level of access and autonomy from one that can modify a repository or deploy code. These differences should determine how each agent is governed.

For each agent, security and engineering leaders should know who uses it and what it is allowed to do. ​

Agents should have only the permissions they need, with human approval reserved for higher-risk actions, such as merging changes to protected branches or modifying authentication and sensitive data.

Routine changes can use the same security checks as human-authored code, with agent-generated changes clearly identified so teams can see where they came from. Some of these checks have limits, though. In my experience, scanners are effective at finding known patterns but much less reliable when a vulnerability depends on business logic or application context.

As co-founder and director of SecureFlag, a company that provides hands-on developer security training, I’m particularly interested in how developers build the skills to work securely with AI agents and review the code they produce. This focus informs my views on agentic AI, though I recognize that training is only one part of governing how these agents are used.​​​

It’s developers who need to find the issues scanners miss, but general awareness training doesn’t necessarily equip them to do so. Instead, Gartner recommends adaptive programs that include AI-specific tasks, and I’ve found hands-on practice in real development environments can help to build the skills to do this.​​

​Organizations can only take responsibility for agents if they know whether the controls around them are working and developers have the skills they need.

The most useful measures come from the code itself, such as comparing vulnerability rates in agent-authored and human-authored changes, and tracking that difference to see if risk goes down. Remediation time and recurring vulnerability classes can also show where problems continue to occur.

It’s also worth tracking how often teams catch problems in agent-authored changes before merge. A rising catch rate could mean controls are working better or agents are producing more problematic code, and it’s important to know which. These measures give a better view of how the organization is managing the risks of agentic development.​

Securing agentic development has two sides. The agent itself needs to be secured, with limits on what it can access and change. The software it produces also needs to be secure, which depends on someone understanding what the agent was asked to do and whether the result matches that intent.

Developers are at the center of both. In many organizations today, agents operate with some of the same access as the developer using them, meaning developers often influence what agents can access without making a deliberate choice. They are also accountable for the changes they approve.

Leadership is responsible for the conditions around that work, including setting boundaries for what agents can access and making sure developers have the skills to configure agents securely and review what they produce. The organization carries the risk either way.

As agents take on more of the development process, organizations need to define where human responsibility lies. Waiting for an incident to establish those boundaries is a costly way to find out.​

Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?