TL;DR: Akeyless argues that most AppSec programs fail when dashboards create noise faster than developers can act, and describes an AI-driven control layer that moves from the IDE to pull requests and remediation while only gating newly introduced risk. The security model shifts from alert volume to context-aware enforcement that preserves flow and reduces friction.
At a glance
What this is: This is Akeyless's analysis of AI-native AppSec, centred on moving security decisions into the developer workflow and gating only newly introduced risk.
Why it matters: IAM, IGA, PAM and application security teams should care because developer-speed enforcement changes how controls are embedded, how exceptions are handled, and how remediation is prioritised.
👉 Read Akeyless's analysis of AI-native AppSec and developer velocity
Context
Most application security programmes struggle when they are built around dashboard consumption instead of developer workflow. In practice, that means teams receive more findings than they can meaningfully triage, while the development path stays disconnected from the control model.
In this article, Akeyless frames the problem as a velocity issue, not a visibility issue. The core identity-security question is how to place enforcement where code is written, reviewed, and remediated without turning AppSec into a bottleneck.
The article is about application security for developers, but the governance lesson extends to identity-adjacent controls too: controls fail when they are evaluated after the work has already moved on. That makes workflow placement as important as policy precision.
Key questions
Q: How should security teams manage application risk in fast-moving development environments?
A: Security teams should move from periodic review to continuous assessment inside the delivery pipeline. That means testing code, dependencies, containers, and runtime behaviour as part of normal build and release flow, then prioritising the findings that are reachable, exploitable, and tied to critical business services.
Q: Why do dashboard-heavy AppSec programmes struggle to change behaviour?
A: Dashboards inform people, but they do not assign work. When security signals sit outside the delivery workflow, teams see more noise and less action. Behaviour changes when the finding is tied to a named owner, a clear fix path, and the context needed to act without re-triage.
Q: What signs show that AppSec gates are failing in practice?
A: The clearest signs are repeated build failures for legacy issues, developers bypassing security workflows, and remediation tickets piling up without reducing exposure. When the same findings keep blocking unrelated work, the gate is no longer distinguishing new risk from old debt. That is a control design problem, not a developer discipline problem.
Q: What should teams do when AI tools propose security fixes?
A: Require every generated fix to remain reviewable, traceable, and tied to the original finding. AI can accelerate remediation, but it should not erase the approval boundary or hide the reasoning behind a code change. The goal is faster correction, not autonomous release authority.
Technical breakdown
Cursor-time guardrails inside the authoring workflow
Cursor-time controls move security from post-commit inspection into the writing environment, where insecure patterns and risky dependencies can be surfaced before they harden into review friction. In this model, the system analyses code structure as it is written, flags secrets hygiene issues, and surfaces verified package risk before a pull request exists. The technical point is not just earlier detection. It is lower-cost intervention at the point of creation, when a developer can still refactor naturally. That changes the economics of AppSec by reducing noise before it enters review queues.
Practical implication: Place lightweight checks as close as possible to authoring so obvious defects never reach the review pipeline.
Delta-based pull request gating
Delta gating means the control evaluates what changed in the current pull request rather than re-failing developers for pre-existing backlog risk. That is a materially different control logic from blanket scanning, because it compares the current environment snapshot with the proposed change set and only blocks newly introduced high or critical issues. This preserves trust in the gate and makes pass or fail outcomes explainable. It also aligns with least surprise for developers, who should not be penalised for legacy debt they did not create.
Practical implication: Gate only newly introduced risk so security checks remain credible and developers do not route around them.
AI-assisted remediation without bypassing review
The remediation layer described here uses AI agents to propose fixes, generate patch candidates, and calculate safer upgrade paths, while keeping the human approval step intact. That matters because the system is not replacing review with automation. It is compressing the time between detection and fix while preserving explicit change control. In practical terms, this turns AppSec from a pure detection problem into a governed fix-generation workflow, where the output is a ready-to-merge change rather than another ticket in a queue.
Practical implication: Use AI to draft remediations and upgrades, but require approval before any security fix is merged or deployed.
Threat narrative
Attacker objective: The attacker aims to exploit application flaws, vulnerable dependencies, or weak configuration paths that survived the development and review process.
- Entry occurs when insecure code patterns, vulnerable dependencies, or weak configuration choices are introduced during development and escape early scrutiny.
- Escalation happens when the same issue is repeatedly surfaced as noise rather than removed, so review fatigue and backlog debt accumulate around the defect.
- Impact follows when the vulnerable change reaches production without contextual gating, leaving the application exposed to abuse that should have been stopped at source.
Breaches seen in the wild
- Firebase misconfiguration exposure 2024: Missing Firebase security rules on 916 websites exposed 125 million user records and 19.87 million plaintext passwords; a quarter were fixed.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Velocity-aware AppSec is becoming a governance requirement, not a developer convenience. Security controls that cannot keep pace with how engineers actually ship code will be bypassed in practice, even when they look complete on paper. The decisive issue is not the number of findings but whether the control inserts itself at the right point in the workflow. Practitioners should treat developer velocity as part of control design.
Alert factory AppSec fails because it confuses observability with enforcement. A dashboard can show risk, but it does not reduce risk unless it changes the decision path before the change is merged. That distinction matters for identity and access teams as well, because policy only governs behaviour when it is embedded where decisions are made. The practitioner conclusion is that controls must be actionable at the point of change.
Context-aware gating is the better control pattern than blanket blocking. The article’s delta-based approach is useful because it separates legacy exposure from newly introduced risk, which is how developer trust is preserved. That is a governance lesson for any programme trying to balance security with throughput. Teams should reduce noise first, or enforcement will lose legitimacy.
Secure authoring is the new control plane for application risk. When insecure patterns are caught in the IDE, the organisation gains earlier intervention and lower remediation cost than waiting for PR review or runtime detection. That shifts security from inspection after the fact to guided creation before the defect exists. Practitioners should design controls around authoring, not only around scanning.
Developer trust is now a measurable security control input. If a security gate repeatedly fails clean code because of old debt, the gate itself becomes a source of operational friction and workarounds. That means fairness in gating is not a soft benefit, it is part of control effectiveness. Identity and application security leaders should measure whether controls preserve developer confidence as well as policy coverage.
From our research library:
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to the State of Secrets in AppSec.
- Read next: NHI Lifecycle Management Guide
What this signals
Context-aware enforcement is the real shift in AI-native AppSec. Teams that keep measuring security by alert volume will miss the operational change here: the control has to understand whether a finding is newly introduced, already known, or irrelevant to the current change. That makes workflow placement and evidence quality more important than raw detection breadth.
Developer velocity changes the effective boundary of control design. If a control only works after code has already left the IDE, it is too late to feel fair and too early to feel useful. In practice, security programmes should move toward authoring-time guidance, PR-time validation, and approval-gated remediation as one continuous loop.
For practitioners
- Implement delta-based PR gating Block only newly introduced high or critical risk in pull requests, and keep pre-existing backlog items visible without making them merge blockers.
- Move security checks into authoring tools Surface insecure patterns, risky dependencies, and secrets hygiene issues inside the IDE so developers can fix them before code reaches review.
- Require human approval for AI-generated fixes Let AI draft remediation patches and upgrade paths, but keep developer approval as the control that authorises the final change.
- Measure gate fairness and noise Track how often a control fails builds for issues introduced before the current change, then tune the policy until legacy debt no longer dominates merge friction.
Key takeaways
- Most AppSec failure modes here come from controls that are accurate in isolation but misaligned with how developers actually ship code.
- The article points to a control model that reduces friction by separating new risk from legacy debt and by moving fixes closer to authoring.
- For practitioners, the main lesson is to design enforcement around workflow timing, because trust and usability determine whether security gates are followed.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while OWASP SAMM, NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API10 — Unsafe Consumption of APIs | The article discusses supply chain validation and code path risk in modern application delivery. |
| Recommendation — Review upstream dependencies and API consumption paths for trust assumptions before merging code. | ||
| OWASP SAMM | Software Security Verification — Software Security Verification | The article is fundamentally about embedding security checks into the development workflow. |
| Recommendation — Embed security verification into authoring and pull request stages so defects are found before release. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article checks whether configuration and permissions align with least-privilege expectations. |
| Recommendation — Verify that code and infrastructure changes preserve approved permissions and authorisations. | ||
| NIST SP 800-53 Rev 5 | CM-3 — Configuration Change Control | The PR gate and remediation flow are change-control problems at their core. |
| Recommendation — Apply change control to security fixes so only reviewed and approved changes reach production. | ||
Key terms
- Delta gating: Delta gating is a control method that evaluates only what a developer changed, rather than re-scanning or blocking on every existing issue in a codebase. It helps separate inherited technical debt from newly introduced risk so security enforcement stays relevant to the current change.
- Secure authoring: Secure authoring places guardrails inside the IDE or editing environment so risky code patterns are addressed before they become review friction. For application security, it shifts control earlier in the lifecycle and reduces the cost of remediation.
- Context-aware Enforcement: Context-aware enforcement is policy that changes based on live conditions such as data sensitivity, environment, or task type. For AI agents, it is the difference between a static permission grant and a control that adapts to what the agent is trying to do right now.
- Autopilot remediation: Autopilot remediation is an AI-assisted fix workflow that proposes patches, upgrade paths, or hardened configurations while keeping approval and oversight intact. It speeds recovery without removing human accountability from the final change decision.
What's in the full article
Akeyless's full article covers the operational detail this post intentionally leaves for the source:
- Cursor-time guardrails that flag insecure patterns and secrets hygiene issues inside the IDE
- The PR validation sequence across logic, supply chain, environment, and provenance checks
- The remediation workflow where AI agents draft fixes, upgrade paths, and hardened configuration files
- How the control layer connects with external security tools while preserving developer approval
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 24, 2026.
Updated on October 7, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org