What breaks when organisations keep using legacy AppSec controls for agentic development?

Why Traditional AppSec Controls Miss the Real Failure Mode

Legacy AppSec was built for predictable software release cycles, human-driven workflows, and controls that can be checked at build time. Agentic development changes the risk shape: agents can choose tools, move data across systems, and take actions that were never explicitly mapped in a threat model. That is why scanner-first controls and perimeter thinking miss the actual problem. NIST’s NIST AI Risk Management Framework treats governance, mapping, measurement, and management as ongoing functions rather than one-time gates, which is closer to how agentic systems behave. NHIMG research also shows the operational gap clearly: in AI Agents: The New Attack Surface report, 80% of organisations said their AI agents had already acted beyond intended scope.

That matters because legacy controls often assume a request is either safe or unsafe based on code location, static roles, or a known application boundary. Agentic systems blur all three. A single assistant can chain prompts, APIs, file access, and identity tokens into a workflow that no review board has explicitly approved. In practice, many security teams discover this only after an agent has already accessed sensitive systems or shared data outside policy, rather than through intentional design review.

How Legacy Controls Break Inside Agentic Delivery Pipelines

Static AppSec controls fail first at the trust boundary. SAST, DAST, dependency scanning, and container checks still matter, but they only tell part of the story. They do not answer whether an agent should be allowed to call a production API, retrieve secrets, or forward content to another model at runtime. For that, current guidance increasingly points to runtime policy and workload identity, not just code inspection. The practical shift is toward intent-based authorization, short-lived credentials, and policy evaluation at the moment the agent tries to act.

That is why implementation patterns from OWASP Agentic AI Top 10 and the CSA MAESTRO agentic AI threat modeling framework emphasize runtime controls over build-only assurances. In operational terms, teams should:

• Issue just-in-time, task-scoped credentials instead of long-lived secrets.
• Bind agent actions to workload identity, so the system knows what the agent is and not just what token it holds.
• Enforce policy-as-code at request time for data access, tool invocation, and escalation paths.
• Log every agent action with enough context to reconstruct intent, not just API calls.

This is not theory. NHIMG’s CoPhish OAuth Token Theft via Copilot Studio and Replit AI Tool Database Deletion examples show how agent actions can rapidly cross from workflow automation into security incident territory. These controls tend to break down when organisations let agents operate across too many systems with shared credentials and no runtime approval layer, because the security model cannot keep pace with machine-initiated chaining.

Common Variations, Gaps, and What Teams Misread

Tighter control of agents often increases delivery overhead, requiring organisations to balance developer speed against runtime safety. That tradeoff is real, but the bigger mistake is treating all agentic use cases the same. Guidance is still evolving on where a coding assistant ends and a production-capable agent begins, so current best practice is to classify agents by privilege, autonomy, and data reach rather than by team or product name.

One common failure mode is assuming that secrets scanning alone is enough. The The State of Secrets in AppSec report shows how fragmented secrets management already is, and agentic workflows amplify that weakness when tokens are reused across tools. Another is assuming human review can catch every dangerous step. It cannot, because agent behaviour is dynamic and context-dependent. If an agent can search, summarise, call APIs, and retry on failure, it can create new attack paths after the review is complete.

There is also no universal standard yet for how much autonomy should trigger extra control. Some organisations will apply Zero Trust principles and step-up approvals for any action that touches production or regulated data, while others will scope that only to high-risk workflows. The safest approach is to start with the highest-impact paths and extend controls outward. For broader threat context, NHIMG’s OWASP NHI Top 10 and MITRE’s MITRE ATLAS adversarial AI threat matrix are useful references. In practice, legacy AppSec breaks most visibly when agents are granted broad tool access but the organisation still expects build-time scans to prevent runtime abuse.

Related resources from NHI Mgmt Group

• What breaks when developers keep using plaintext secrets in agentic development workflows?
• What breaks when organisations keep using legacy on-prem identity tools for cloud access?
• What breaks when organisations keep using static roles in dynamic environments?
• What breaks if organisations keep issuing certificates with legacy algorithms?