Why do AI agents create new AppSec risk even when code quality improves?

AI agents reduce manual work, but they also compress decision-making into machine-paced actions that can bypass human review windows. The risk increases when agents can consume untrusted input, select tools, and execute changes in the same workflow. Better code generation does not eliminate delegation risk, access misuse, or supply chain drift.

Why This Matters for Security Teams

AI agents change the AppSec problem from “does the code compile and pass review” to “what authority did the system exercise while making that change.” Better code quality can reduce syntax errors and obvious logic flaws, but it does not remove the security impact of delegated actions, hidden tool calls, or untrusted inputs reaching a privileged workflow. That is why frameworks such as the NIST AI Risk Management Framework matter here: the control question is not only correctness, but also accountability, traceability, and bounded behavior.

For AppSec teams, the real shift is that AI agents often operate across code, tickets, repos, CI pipelines, and cloud tooling in one continuous loop. That creates a larger blast radius than a traditional developer shortcut or automation script. A code review may look cleaner while the underlying action path becomes more dangerous, especially if the agent can accept prompts, retrieve context, and execute changes without a human pause.

In practice, many security teams encounter agent risk only after an automated change has already widened access or introduced an unsafe dependency, rather than through intentional security design.

How It Works in Practice

AI agents create new AppSec risk because they combine three capabilities that are usually separated in mature controls: interpreting input, choosing an action, and executing it. A conventional pipeline might let a developer write code, a reviewer inspect it, and a CI system test it. An agent can collapse those steps into one machine-paced workflow, which means the security boundary moves from code quality to control of authority, context, and tool access. The OWASP Agentic AI Top 10 is useful here because it highlights risks such as tool abuse, prompt injection, unsafe delegation, and overbroad autonomy.

Operationally, the risk shows up in a few common ways:

• An agent reads a malicious issue, prompt, or document and treats it as trusted task context.
• The agent selects a tool or API call that has more privilege than the task requires.
• Generated code is syntactically better, but it still embeds insecure logic, unsafe defaults, or weak authorization checks.
• Automated pull requests pass unit tests while introducing supply chain drift through new dependencies, config changes, or token handling mistakes.

Threat modeling should therefore look beyond code output and examine the full decision chain. The MITRE ATLAS adversarial AI threat matrix and the CSA MAESTRO agentic AI threat modeling framework both support this broader view by focusing on how adversaries manipulate model behavior, context, and orchestration. Security teams should bind agents to least privilege, constrain tool scopes, log every action, and require human approval for changes that affect identity, secrets, deployment, or runtime policy. These controls tend to break down when one agent can chain multiple tools across repositories, ticketing, and production systems because the trust boundary becomes too wide to inspect manually.

Common Variations and Edge Cases

Tighter agent controls often increase friction and reduce automation gains, so organisations have to balance speed against the cost of review, logging, and privilege segmentation. Best practice is evolving, and there is no universal standard for how much autonomy is safe in every environment. The right answer depends on whether the agent is suggesting code, opening pull requests, changing infrastructure, or making production decisions.

Some environments can tolerate limited agent assistance with strong guardrails, while others need strict approval gates because the agent can reach secrets, production accounts, or regulated data. This distinction matters more than model accuracy. A highly accurate agent can still be dangerous if it acts on a poisoned prompt or a compromised repository. Guidance from the NIST AI Risk Management Framework and the NIST Cybersecurity Framework 2.0 points toward governance, asset visibility, and response discipline rather than blind trust in model output. Current guidance also suggests treating agent-written code as one signal in a broader assurance process, not as evidence that the workflow is secure by default.

Agentic systems are especially fragile when they span multiple identities, tokens, and SaaS tools without a clean ownership model. That is where AppSec starts to overlap with NHI governance, because the true risk is often the delegated credential or service account the agent uses to act. Organisations that ignore that intersection usually discover the problem when an apparently minor automation has already touched build systems, secret stores, or release pipelines.

Related resources from NHI Mgmt Group

• Why do AI agents create new risk even when they are short-lived?
• Why do AI coding agents create new IAM risk even when prompt injection is addressed?
• Why do AI agents create new risk in non-human identity management?
• Why do AI agents create new privilege risk for enterprises?