Legacy AppSec controls often assume predictable human workflows and static application boundaries. Agentic development introduces dynamic decisions, broader data reach, and more machine initiated actions, which can bypass controls that were built for code scanning alone. The result is weaker oversight of shadow AI, novel attack paths, and insufficient guardrails around how AI is used in delivery pipelines.
Where Legacy AppSec Assumptions Fail in Agentic Development
Legacy application security controls were built around code review gates, static trust boundaries, and human-initiated workflows. Agentic development changes the control problem: tools can plan, call services, transform prompts into actions, and move data across systems without a developer manually touching every step. That means a scanner can confirm code quality while missing the risk created by what the agent is allowed to do at runtime. For a useful external baseline, see OWASP Agentic AI Top 10.
What breaks first is the assumption that the application boundary is stable. In agentic delivery, the boundary can expand through connectors, retrieval sources, tool calls, and delegated execution. Traditional AppSec checks may still be valuable, but they no longer describe the full attack surface or the full change in authority. The practical consequence is that teams can have a clean pipeline and still ship an agent that overreaches, leaks data, or takes unsafe actions inside approved systems. In practice, many security teams encounter this only after an agent has already been allowed to act beyond the limits that their legacy control model was designed to see.
How Legacy Controls Behave When the Workload Starts Making Decisions
Legacy AppSec usually focuses on code-centric controls: static analysis, dependency review, secrets scanning, approval gates, and vulnerability triage. Those are still useful, but they mainly tell you whether the software artefact looks sound. Agentic development adds a second layer of risk around runtime decision-making, tool use, and context injection. A model can be technically deployed through a compliant pipeline and still be operationally unsafe if it can reach sensitive data, invoke internal tools, or chain actions in ways the control stack never expected.
That is why agentic security needs to ask different questions. Instead of only asking whether the code is patched, teams also need to ask whether the agent can be induced to take the wrong action, whether the tool interface is over-permissive, and whether the agent can expose data through apparently normal business workflows. The difference is not cosmetic. Controls built for deterministic software often fail to express intent, constrain sequence, or separate read access from action authority.
- Static scanning can miss a dangerous combination of prompt, tool permission, and data source access.
- Code review can miss unsafe orchestration logic that appears only when the agent is running.
- Traditional approval gates can be too coarse when the real issue is what the agent may do after deployment.
- Monitoring that watches application errors may not notice policy-breaking but syntactically valid agent behaviour.
The right comparison is not code security versus AI security. It is whether the control set still matches the actual decision and execution model. That is where guidance from the NIST AI Risk Management Framework is useful, because it pushes teams to account for context, governance, and lifecycle effects rather than treating deployment as the end of the security job. Where that guidance breaks down is when organisations try to force every agentic risk into a conventional vulnerability ticket and ignore the policy, authority, and tool-use conditions that made the issue possible.
When “Good AppSec” Still Leaves an Unsafe Agent
Tighter control often increases delivery overhead, requiring organisations to balance speed against the extra review needed for autonomous behaviour. The biggest edge case is where the application is not fully autonomous, but is autonomous enough to create new exposure. In those hybrids, a normal AppSec programme may look mature while the actual business risk sits in orchestration, delegation, and access scope. That is a real operational tradeoff, not a theoretical one.
Another common variation is the use of shadow AI inside delivery pipelines. If teams allow unsanctioned copilots, plugins, or agent wrappers, the weak point may not be the main application at all. It may be the invisible tooling around it, which legacy control sets often treat as productivity software instead of as part of the production attack surface. There is still no full consensus in the industry on where AppSec ends and AI governance begins, but there is growing agreement that agentic systems need explicit authority boundaries and use-case controls, not just code hygiene.
For broader threat context, MITRE ATLAS adversarial AI threat matrix is useful when the concern is how adversaries can shape model behaviour, while CSA MAESTRO agentic AI threat modeling framework helps teams think about trust boundaries, orchestration, and agent-specific failure paths. Where these approaches break down is in organisations that treat agentic change as a minor extension of application delivery rather than as a shift in who or what is making security-relevant decisions.
Risk and Threat Considerations
Legacy AppSec controls create exposure when they assume that software is only executing developer-defined logic. In agentic development, the material risk is that decision-making, data access, and action execution become dynamic, which can undermine segregation of duties, approval assumptions, and least-privilege boundaries.
Failure mechanism: An agent can be given broad tool access, fed untrusted context, or prompted into actions that are syntactically valid but policy-breaking. Traditional controls may inspect artefacts and dependencies while missing runtime abuse, overbroad delegation, or tool-mediated data exfiltration.
Impact: Organisations can lose visibility over shadow AI use, expose sensitive data through legitimate workflows, and allow unsafe actions in production systems without a clear detection or rollback path.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and MITRE ATLAS address the attack surface, NIST AI RMF and CIS Controls v8 set the technical controls, and ISO/IEC 42001:2023 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A1 — Agentic Access Control | Agentic development changes what the system can do at runtime. |
| Recommendation — Constrain agent actions to the minimum tool and data scope needed. | ||
| NIST AI RMF | GOV — Govern | This issue is fundamentally about governance of autonomous AI use. |
| Recommendation — Establish AI governance that defines authority, accountability, and allowed use. | ||
| MITRE ATLAS | ATLAS — Adversarial Threat Matrix | Legacy AppSec fails when adversaries shape agent behaviour and actions. |
| Recommendation — Map prompt and tool abuse paths to detect adversarial manipulation. | ||
| CIS Controls v8 | 6 — Access Control Management | Overbroad access is a core failure mode when agents can act directly. |
| Recommendation — Review and remove excessive access granted to agentic systems. | ||
| ISO/IEC 42001:2023 | A.5 — AI system impact assessment | Agentic development requires structured AI governance and risk oversight. |
| Recommendation — Assess agentic use cases for impact before enabling production access. | ||
Practitioner Guidance
What to prioritise: Treat agent authority, tool scope, and data reach as first-class security objects. If a control only evaluates code, it is incomplete for agentic delivery because the highest-risk behaviour often appears after deployment, not during build time.
What to verify: Confirm which actions the agent can initiate, which data sources it can reach, and whether any approval or human-in-the-loop step is real or only nominal. The key test is whether a compromised prompt, connector, or retrieval source could turn a normal workflow into an unsafe one.
What practitioners underestimate: Teams often overestimate the value of a green AppSec pipeline and underestimate the security effect of orchestration logic. The most important takeaway is that agentic development needs controls that govern behaviour, not just code quality; otherwise the organisation secures the artefact while leaving the actor ungoverned.
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?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 7, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
