TL;DR: DevSecOps automation has shifted from pipeline scanning to an orchestrated control layer where AI agents triage, prioritise, and remediate findings across code, pipelines, and runtime context, while 81% of organisations still lack visibility into AI use across the SDLC and ADLC, according to Cycode. The governance challenge is no longer how to scan faster, but how to make code-to-cloud decisions with enough identity and context to close risk rather than create alert churn.
At a glance
What this is: Cycode argues that DevSecOps automation is moving from scanner-centric tooling to an agentic control layer that correlates code-to-runtime context and closes risk faster.
Why it matters: For IAM, NHI and broader security teams, the key issue is whether AI-assisted development and automation are governed with enough identity, privilege and context to prevent faster delivery from becoming faster exposure.
By the numbers:
- 81% of organisations lack full visibility into how and where AI is used across the SDLC or the ADLC.
Context
DevSecOps automation is the set of controls and workflows that embed security into software delivery so findings can be acted on as code moves through development, build and deployment. The governance gap now is that AI-generated code, cloud-native stacks and distributed delivery have outpaced manual review and siloed tooling.
Cycode's framing matters because the article is not really about faster scanning. It is about whether security decisions can be made with enough code, pipeline, runtime and identity context to stay effective in the agentic development lifecycle. That is a real control problem, not just a tooling preference.
Key questions
Q: What breaks when DevSecOps automation is still limited to scanner output?
A: Security teams lose the ability to distinguish exploitable risk from background noise, so findings pile up faster than they can be triaged. The result is slower remediation, more developer friction and a growing gap between what is detected and what is actually fixed before release.
Q: Why does code-to-runtime context matter in agentic DevSecOps?
A: Because a finding only becomes actionable when teams know whether it is reachable, exposed and owned in the current environment. Context lets automation prioritise real attack paths instead of raw alerts, which is essential when code and infrastructure change faster than manual review can keep up.
Q: What are the signs that SecOps automation is not working as intended?
A: Common warning signs are slow handoffs, overwhelmed analysts, repeated manual triage, and workflows that fail to adapt when context changes. If automation exists but incidents still move through the queue at human speed, the programme is not delivering value. Strong automation should reduce operational noise, enrich cases consistently, and make response faster and more repeatable.
Q: How should security teams govern AI coding assistants that can execute commands?
A: Treat them as delegated non-human identities with bounded execution authority. Require human approval for destructive commands, keep command scopes narrow, and log every tool action. The key control question is not whether the assistant is helpful, but whether it can be prevented from acting outside intended scope when prompts, context, or rules are manipulated.
Technical breakdown
How DevSecOps automation changes from scanning to orchestration
Traditional DevSecOps tools surface findings. An automation platform correlates those findings across static analysis, software composition analysis, secrets detection, IaC security, CI/CD pipeline security and posture management so the system can decide what is exploitable in context. The important shift is from isolated alerts to orchestrated workflows that use asset criticality, ownership, runtime exposure and code lineage to rank risk. That is why the article treats the platform as a control layer rather than a scanner. Practical implication: teams should evaluate whether their stack can correlate findings into a single risk view before they add more point tools.
Practical implication: assess whether findings are being correlated into one risk view before adding more point tools.
Why code-to-runtime context is the deciding control in agentic DevSecOps
AI coding assistants and AI agents accelerate code creation, but speed alone does not tell you whether a weakness is reachable, exposed or owned. Code-to-runtime context connects source code, infrastructure and identity signals to the live application state, which allows an agent to distinguish noise from a real attack path. Without that linkage, automation just produces faster false positives or remediates the wrong issue. Practical implication: control design should privilege context enrichment and exploitability analysis over raw alert volume reduction.
Practical implication: prioritise context enrichment and exploitability analysis over raw alert volume reduction.
How AI guardrails extend DevSecOps into the development workflow
The article shows that risk is no longer confined to the pipeline. AI guardrails act at prompt submission, file reads and tool calls, which means the security boundary has moved closer to the agent or assistant producing code. This matters because secrets can be introduced or exposed before a traditional scanner ever sees the artifact. In identity terms, the workflow now includes machine actors that need governed access to code, context and tools. Practical implication: security teams should treat AI coding assistants and agentic workflows as controlled identities with scoped access and monitoring.
Practical implication: treat AI coding assistants and agentic workflows as controlled identities with scoped access and monitoring.
Threat narrative
Attacker objective: The attacker objective is to exploit gaps created by rapid, poorly governed AI-assisted development before the vulnerable code or exposed secret is remediated.
- Entry occurs when AI-generated code, AI coding assistants or automation tooling introduce vulnerable patterns, hardcoded secrets or insecure dependencies into the SDLC.
- Credential or context exposure follows when guardrails fail to intercept secrets in prompts, file reads or tool calls, allowing machine actors to interact with sensitive material.
- Escalation happens when isolated scanners and manual triage cannot keep pace, leaving exploitable issues, misconfigurations and pipeline weaknesses unresolved across the delivery chain.
- Impact is faster release of vulnerable software, broader attack surface and more risk carried into runtime before security can intervene.
Breaches seen in the wild
- Nx s1ngularity attack 2025: Attackers stole Nx's npm token via a GitHub Actions flaw and shipped malware that stole 2,349 secrets and abused developers' AI CLIs.
- PyPI secrets exposure 2023: Researchers found 3,938 unique secrets in published PyPI packages, 768 still valid; a new release or yank does not remove them.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Agentic DevSecOps is becoming a control layer, not a tool category. The article describes a shift from isolated scanners to orchestration that evaluates code, pipeline and runtime context together. That is the real governance change: security is moving closer to execution decisions, not just detection. For identity teams, the key question is whether machine actors are being granted and monitored like governed workloads rather than invisible automation.
Context graphing is the named control concept this market now needs. A code-to-runtime context graph is more than a visibility feature because it links identity, asset exposure and ownership into one decision path. Without that linkage, AI-generated code and agent-driven workflows will always outrun manual triage. Practitioners should treat context enrichment as the prerequisite for any credible agentic security workflow.
Secrets management failures are now development-speed failures. The article makes clear that secrets can enter repositories, prompts and tool calls before traditional review catches them. That collapses the old assumption that review happens before exposure. For NHI governance, the practical takeaway is that machine credentials and tokens need issuance-time controls, not just after-the-fact detection.
Visibility gaps across the SDLC are now governance debt. Cycode's cited figure that 81% of organisations lack full visibility into AI use across the SDLC and ADLC points to a structural accountability problem, not a narrow tooling gap. If teams cannot inventory where AI is being used, they cannot govern what those systems can see, touch or change. Practitioners should align SDLC oversight with identity, access and workflow ownership.
Security programs will need to measure exploitability, not alert counts. The article's focus on context-aware prioritisation reflects a broader industry correction away from volume metrics and toward decision quality. That matters because automated workflows can create more findings faster than teams can triage them. The programme objective should be fewer exposed paths to production, not fewer dashboard rows.
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
Agentic control has become the new DevSecOps boundary. The article's most important signal is that security has moved from inspecting artifacts after creation to governing the decision layer that creates and routes them. That creates a direct identity problem for security teams because AI assistants, workflow agents and build automation now behave like machine actors with scoped access and auditable intent.
Code-to-runtime traceability is becoming a baseline expectation. When development speed is driven by AI-generated code, security programmes cannot rely on late-stage validation to recover control. The practical response is to make ownership, exposure and execution context visible before an issue reaches production, especially where secrets and privilege can be introduced programmatically.
Developer behaviour still determines the ceiling of automation. Only 44% of developers are reported to follow security best practices for secrets management, according to the State of Secrets in AppSec. That gap means policy automation alone will not close exposure unless teams also reduce secret leakage opportunities inside the SDLC.
For practitioners
- Map AI-assisted development to governed machine identities Inventory AI coding assistants, autonomous workflow components and build-time automation as separate machine actors, then define what code, prompts, repositories and tools each one can access.
- Correlate findings before routing remediation Use a single risk view that combines SAST, SCA, secrets detection, IaC and pipeline signals with ownership and runtime exposure so teams do not chase isolated alerts.
- Treat secret exposure as a source-control and workflow issue Scan repositories, CI/CD configurations and collaboration paths for hardcoded credentials, API keys and tokens, then revoke or rotate anything discovered as part of the remediation workflow.
- Add guardrails at prompt, file and tool boundaries Block sensitive context from reaching AI assistants unless the use case is approved, logged and scoped, especially where prompts or tool calls can reveal secrets or privileged data.
- Measure exploitability and remediation closure, not alert volume Track how many findings are verified as reachable, how many are closed automatically, and how quickly high-risk issues move from discovery to fix in the delivery pipeline.
Key takeaways
- DevSecOps automation is shifting from alert generation to context-aware risk reduction, and that changes the control model teams need to govern.
- The biggest operational gap is not scan coverage alone but whether code, pipeline and runtime signals can be correlated into a defensible remediation decision.
- Identity, secrets and workflow boundaries now matter inside the software factory because AI-assisted development can create exposure faster than manual review can contain it.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | The article repeatedly focuses on hardcoded credentials, tokens and prompt leakage. |
| NHI-04 — Insecure Authentication | AI-assisted workflows introduce machine access paths that need governed authentication boundaries. | |
| Recommendation — Scan code, CI and AI workflows for leaked secrets and revoke exposed credentials immediately. Apply governed authentication to AI assistants and automation paths that can reach repositories or tools. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The article's risk model centres on stolen secrets and pipeline-driven spread across the SDLC. |
| Recommendation — Map secret exposure and pipeline compromise to credential access and lateral movement detections. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article's governance theme is who and what can access code, tools and sensitive context. |
| Recommendation — Review and minimise entitlements for AI agents, build systems and development workflows. | ||
| CIS Controls v8 | CIS-5 — Account Management | Automation and developer tooling rely on managed accounts, service identities and revocation discipline. |
| Recommendation — Maintain accurate account inventories for CI/CD, developer and machine accounts, and remove stale access fast. | ||
Key terms
- DevSecOps Automation Platform: A DevSecOps automation platform is an integrated control layer that correlates code, dependency, pipeline, and runtime signals to reduce security risk. It goes beyond scanning by prioritising exploitable issues and coordinating remediation across tools and teams.
- Code-to-Runtime Context: The linkage between a code change and the live systems, data flows, ownership, and controls it affects. This context is critical because a fix that is technically correct in source code can still be unsafe or noncompliant once deployed into the real environment.
- Identity Security Posture Management: Identity security posture management is the continuous assessment of identity configuration, privilege, and exposure across an environment. It focuses on drift, overprivilege, and control gaps so teams can see where IAM, PAM, and NHI governance are failing before those gaps become incidents.
- Agentic Development Lifecycle: The Agentic Development Lifecycle is the control pattern for building, approving, deploying, and reviewing AI agents before they reach production. It extends software change discipline into identity governance by requiring traceability for creation, access grants, business purpose, and ongoing oversight.
Deepen your knowledge
NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity and secrets management. It is a useful fit for practitioners who need to connect identity controls to broader software delivery risk.
Published by the NHIMG editorial team on August 20, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org