Topic starter
25/06/2026 5:10 pm
TL;DR: AI-native AppSec works best when enforcement follows developer workflow timing, according to Akeyless's analysis of AppSec controls. Gates that separate newly introduced risk from legacy debt can reduce noise, preserve flow, and make fixes more likely to stick.
Editorial analysis by NHI Mgmt Group, based on content published by Akeyless: “From Alerts to Autopilot: Building AI‑Native AppSec”.
Key questions
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.
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.
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.
Glossary terms: Delta gating, Secure authoring, Context-aware Enforcement, Autopilot remediation
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 →
This topic was modified 7 days ago by NHI Mgmt Group
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