The New Security Debt Is in the Workflow
Security debt in agent-assisted coding is the subject here: not a vague fear that AI writes bad code, but the accumulation of security-relevant weaknesses in autonomous-agent pull requests and in the workflow that carries them toward integration. This opening asks where that debt enters and why ordinary review can miss it. By the end, you should be able to distinguish a security smell from a confirmed vulnerability and see the trust and authority boundaries that determine whether a small weakness remains visible or becomes an operational problem.
The change matters because a coding agent is no longer only a suggestion box. An autonomous agent can take a high-level task, decide on intermediate steps, edit files, run tools, and prepare a pull request with limited human intervention. That flexibility creates value precisely where traditional software is most explicit: in deciding what to do next. It also changes the security question. We are no longer asking only whether a programmer or a model produced a correct line. We are asking what the system was allowed to read, what it was allowed to change, which instructions shaped its actions, and what review stood between the change and execution.
The object of concern is not just generated code
A security smell is a structural pattern that indicates a possible security risk. A hard-coded credential, an unpinned dependency reference, or an overly broad execution permission may deserve immediate attention, but the presence of such a pattern is not by itself proof that an attacker can exploit the system. Exploitability depends on context: whether a credential is live, whether a dependency can be replaced, whether a build environment is reachable, or whether a privileged action is actually exposed. Keeping this distinction is not academic caution. It prevents a measured warning from being inflated into an incident while still treating the warning as a reason to act.
The supplied empirical study examines this warning layer in a specific place: added lines in agent-generated pull requests that touch high-risk kinds of files. These include build and continuous-integration definitions, container files, infrastructure configuration, secret-bearing files, shell scripts, and notebooks. The study excludes several other classes of files and does not attempt to judge the entire security health of a repository. Its subject is therefore narrower, and more useful, than the phrase “AI security” suggests: what security-relevant structure enters the paths that an autonomous coding workflow changes?
That wording also keeps responsibility in view. “Agent-generated pull request” describes a workflow, not necessarily a line-by-line account of who supplied every value. A person may provide credentials, approve a change, alter a generated file, or decide how much of a diff to inspect. The agent may choose tools, assemble a change, or expose a human-created value to a path where it can be committed. Review bots and maintainers add another layer. The security property belongs to the chain, even when authorship can later be assigned to one commit identity.
This is why the useful unit of analysis is a boundary. The first boundary is between content and control: a repository file, issue, documentation page, or tool result may be data, but an agent may interpret text from it while deciding what to do. The second is between capability and authority: an agent that can edit a repository may also be able to run code, use credentials, or change deployment configuration. The third is between production speed and review capacity: a diff can arrive faster or grow larger than a person can examine carefully. The fourth is between a probabilistic decision and a deterministic consequence: a model may propose an action, but a build system, cloud account, or integration process can execute it with real authority.
The workflow can be viewed at a high level:
The diagram is intentionally simple. It does not claim that every workflow has the same components or that every smell follows the same route. It shows the crossings that matter. A weakness can enter when a change is made, remain hidden when review treats the diff as routine, or become consequential when an integrated file controls a build or runtime. Untrusted content can also influence the agent before any line is written. Security debt is therefore not stored in one place; it accumulates wherever the chain transfers trust without a sufficiently strong check.
The first signal: a fast workflow leaves a measurable trace
The empirical study makes that thesis concrete without claiming to measure every possible failure. It uses the AIDev dataset of pull requests from five coding agents. After filtering for the selected high-risk paths and considering only added lines, the researchers had 16,370 file changes across 4,064 pull requests. The language-model judge returned usable labels for 16,112 file changes spanning 4,022 pull requests. The difference matters: not every item produced a parseable result, so the headline percentages describe the valid analysis set, not the original corpus in full.
Within those valid labels, 3,807 file changes were flagged with at least one smell, a file-level rate of 23.6%. At the pull-request level, 1,563 of 4,022 requests contained at least one smell, or 38.9%. These denominators answer different questions. The file-level rate asks how often a retained changed file was flagged. The pull-request rate asks how often a request contained at least one flagged file. A single request can contain several dirty files and several smells, which is why the study also reports 8,701 distinct smells after deduplication.
The distribution is sharply uneven. Supply-chain-integrity findings—patterns such as mutable action or image references and unpinned global installs—accounted for 7,160 smells, or 82.3% of the total. Over-privilege execution accounted for 835, while secrets identity accounted for 294. The remaining categories covered hardening and misconfiguration, permissive network exposure, and cleartext transport. The large supply-chain share tells us where debt accumulates by volume: build and execution inputs are repeatedly given a degree of trust that makes future behavior depend on something that may change.
Severity tells a different story. Of the 8,701 findings, 6,292 were labeled major, 2,156 minor, and 253 critical. Two hundred and fifty-two of the 253 critical findings—99.6%—belonged to the secrets-identity category. That does not mean credentials were the most common smell. It means that a smaller category occupied almost all of the study’s critical tail. “Common” and “dangerous” are different axes, and a sensible security program needs both. It must reduce the broad accumulation of configuration debt while giving especially strong preventive treatment to identity material.
The study also reports that the proportion of flagged pull requests rose with the amount of code changed, from 16.2% for requests changing one to nine lines to 53.6% for requests changing at least 1,000 lines. This is an association, not proof that size alone creates a smell. Larger requests may involve more files, more systems, more task complexity, or more opportunities for a reviewer to miss an important change. The practical point is narrower: when autonomous workflows increase the volume or breadth of change, review capacity becomes part of the security boundary.
The same caution applies to differences among agents and programming languages. The reported rates vary across the five agents and across repository languages, but the study does not establish that one product or language is intrinsically secure or insecure. Task mix, repository selection, file mix, configuration, and user behavior may all contribute. The numbers are signals for investigation and triage, not a leaderboard.
Where the debt can cross a boundary
The most important shift in perspective is from “the model made a mistake” to “the workflow allowed a mistake to acquire authority.” A model can produce a suspicious dependency reference, but a build system decides whether to fetch and execute it. A person can place a credential in a change, but the repository and review process decide whether it is detected before integration. An agent can encounter untrusted text, but tool permissions and argument checks decide whether that text can influence a sensitive action. Each example has a different immediate cause, yet the same architectural question: what crossed the boundary, and who or what was supposed to stop it?
The broader security analysis of AI agents helps explain why these crossings multiply. Agents often need access to files, databases, credentials, APIs, or code execution to be useful. Sensitive information can move through tool results, workspace files, memory, webhooks, connectors, or browser automation. An integrity failure may be an unwanted file or configuration change, an installation, or an external transaction. Availability can also be affected when a long-running task stalls, retries repeatedly, consumes excessive resources, or propagates a component failure through a chain of subagents. These are general agent-system pathways, not incidents measured in the pull-request study, but they show why the security posture of a coding workflow cannot be inferred from the generated diff alone.
The human boundary deserves equal attention. In an agent-assisted process, the person is not simply a final approval button. They may supply context, choose permissions, handle a secret, interpret a review result, or decide that a large diff is safe enough to merge. The empirical study’s deeper secret analysis asks exactly this kind of question rather than assuming that every flagged value came from the model. At the same time, the evidence does not justify blaming human carelessness or declaring the model uninvolved. It points to a shared workflow in which speed, delegation, tooling, and review visibility interact.
This framing changes what “trust” should mean. Trusting an agent should not mean believing that its next action will always be safe. It should mean giving the agent a bounded ability to act while preserving checks that do not depend on its own interpretation. Trusting a pull request should not mean trusting its author label. It should mean knowing which high-impact paths changed, what authority those paths control, what was checked, and what happens if a check fails. Trusting a review bot should not mean treating an unreported issue as absent, especially when the detector itself can miss findings.
The central judgment of this series follows from those distinctions. Security debt in agent-assisted coding is best understood as a control-boundary problem with measurable code-level symptoms. The empirical evidence shows a substantial scoped smell burden, a strong concentration in supply-chain paths, a critical tail dominated by credentials, and a relationship between larger changes and higher flagging rates. The broader agent analysis explains why tools, external content, shared state, delegation, and hosting can increase the number and consequence of those crossings. Neither source supports the claim that every agent change is unsafe, nor the claim that ordinary review is enough.
Before deciding which safeguards to adopt, we need to be precise about the object being measured: which files entered the study, how smells were counted, what the severity labels mean, and where the detector and dataset leave uncertainty. That measurement discipline is the next step in understanding where security debt accumulates—and in avoiding a new debt of our own, created by treating an alarming percentage as more certain than the evidence allows.