Topic starter
25/06/2026 5:10 pm
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.
Editorial analysis by NHI Mgmt Group, based on content published by Akeyless: “From Alerts to Autopilot: Building AI‑Native AppSec”.
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.
Q: Why do dashboard-heavy AppSec programmes struggle to change behaviour?
A: Dashboards inform people, but they do not assign work.
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.
Practitioner guidance
- 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.
Bottom line: Most AppSec failure modes here come from controls that are accurate in isolation but misaligned with how developers actually ship code.
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
👉 Read Akeyless's analysis of AI-native AppSec and developer velocity →
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
25/06/2026 5:41 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: AI-native AppSec shifts from dashboards to developer velocity