By NHI Mgmt Group Editorial TeamDomain: Cyber SecuritySource: StackHawkPublished July 29, 2026

TL;DR: A survey of 250+ AppSec stakeholders found 87% of organisations now use AI coding assistants, while 94% still rely on at least one testing tool and half spend 40% or more of their time triaging findings, according to StackHawk. The real problem is not tool scarcity but the gap between discovery, prioritisation, and business-risk measurement.


At a glance

What this is: This survey says AI-assisted development is now mainstream, but AppSec teams still lack the visibility and risk intelligence needed to keep pace.

Why it matters: For IAM practitioners, the lesson is that security programmes fail when they cannot continuously identify assets, privileges, and exposure across both human and non-human workflows.

By the numbers:

👉 Read StackHawk's 2026 survey findings on AI-era AppSec


Context

AI-assisted development has moved from experimentation to routine operations, which changes the security problem from isolated code review to continuous governance of fast-changing application and identity-adjacent workflows. The first-order issue is not whether teams can scan more, but whether they can see what exists, understand what changed, and decide what matters before risk reaches production.

That challenge intersects with identity because modern development environments depend on service accounts, API keys, tokens, CI/CD access, and cloud permissions to move code and data. When visibility is incomplete, access control decisions are made against an outdated picture of the environment, which is exactly how overexposure and ungoverned machine access accumulate.


Key questions

Q: How should security teams secure AI-assisted development without overwhelming AppSec workflows?

A: Start with continuous discovery, then connect findings to exposure, criticality, and data sensitivity before remediation begins. AI-assisted development increases the pace of change, so the control problem becomes deciding what matters fast enough to act on it. Teams that keep relying on scan volume alone will stay busy without reducing real risk.

Q: Why do visibility gaps create more risk than extra testing tools reduce?

A: Testing tools only evaluate what they can see, and incomplete inventories mean entire applications, APIs, or machine identities may never be assessed. Visibility gaps also weaken access governance because permissions are reviewed against stale assumptions. In practice, missing context creates false confidence while exposure continues to grow.

Q: What do AppSec teams get wrong about triage at scale?

A: They often treat triage as an operational nuisance rather than a governance signal. When teams spend large amounts of time sorting findings, the real issue is usually poor contextual prioritisation, not lack of effort. The fix is to narrow review to findings with meaningful exposure and business impact.

Q: How do application security and NHI governance intersect in AI-era pipelines?

A: Modern delivery pipelines rely on service accounts, tokens, and automated credentials to move code and deploy services. Those identities need lifecycle control, privilege review, and ownership just like human accounts do. If they are unmanaged, AppSec inherits the same standing-access problems that plague broader NHI programmes.


Technical breakdown

Why AI-assisted development expands the attack surface

AI coding assistants increase the rate at which code, dependencies, and application paths are produced. That creates more places for vulnerable logic, exposed APIs, and unsafe default permissions to enter the software lifecycle. The security issue is not simply that AI writes insecure code. It is that teams must now govern a larger and less predictable set of application behaviours, including the credentials and service integrations used to build, test, and deploy them.

Practical implication: security teams need continuous discovery and change-aware controls, not periodic snapshots of the application estate.

Why tool coverage does not equal security intelligence

Most AppSec programmes already run multiple testing tools, but testing volume does not create reliable decision-making. Static analysis, DAST, SCA, and penetration testing each produce findings, yet those findings still need context such as exposure, exploitability, data sensitivity, and business criticality. Without that context, teams optimise for scan counts and alert handling instead of risk reduction. This is why triage becomes the bottleneck even in well-instrumented environments.

Practical implication: prioritisation logic must connect findings to application criticality and identity-controlled exposure before remediation queues are built.

Why visibility is now the core governance control

Visibility is the control that sits underneath every other AppSec decision. If teams cannot reliably enumerate applications, APIs, identities, and runtime dependencies, they cannot measure coverage or prove risk reduction. In practice, many organisations still depend on spreadsheets, quarterly surveys, and partial monitoring, which produces a false sense of completeness. In identity terms, that is the same failure mode seen when access reviews are performed against incomplete entitlement data.

Practical implication: build a continuous asset and identity inventory that can support both application security and access governance decisions.


NHI Mgmt Group analysis

AI-era AppSec is becoming an identity governance problem as much as a testing problem. When AI-assisted development becomes standard, the security question shifts from finding vulnerabilities to governing the credentials, permissions, and access paths that let software move through the pipeline. That means application security, IAM, and PAM are increasingly coupled, especially where CI/CD and cloud build systems rely on persistent machine access. Practitioners should treat software delivery identity as part of the security control plane.

Visibility debt is the defining failure mode in this survey. The article shows that teams can accumulate tools faster than they accumulate understanding. Fragmented asset discovery, incomplete attack-surface inventory, and activity-based metrics create a programme that looks busy but cannot answer whether exposure is shrinking. This is the same governance trap that appears in NHI programmes when service accounts and API keys are tracked inconsistently. Practitioners should treat inventory quality as a primary risk control.

Risk metrics matter more than scan metrics because boards now ask different questions. The survey’s strongest signal is not that organisations lack testing, but that they lack a language for translating testing into business risk. That makes prioritisation frameworks, exposure scoring, and asset criticality essential rather than optional. In governance terms, this is a measurement problem, not a tooling problem. Practitioners should align reporting to risk reduction, not tool output.

Application security in the AI era needs a named concept: triage inflation. Triage inflation is the condition where the volume of findings grows faster than the organisation’s ability to interpret them, causing remediation to slow even as tooling expands. The survey’s 40% triage time figure shows how easily security operations can become self-defeating when intelligence is missing. Practitioners should reduce finding volume only after they improve contextual prioritisation.

Machine identity control is now inseparable from application security control. The article’s discussion of AI-driven development implies more automated pipelines, more service accounts, and more token-based access between systems. Those identities often sit outside traditional review processes even though they can move code, secrets, and data at production speed. That is why NHI governance, secrets management, and application security cannot remain separate programmes. Practitioners should plan for shared ownership of software delivery identities.

What this signals

AppSec leaders should expect visibility to become the gating control for every other programme decision, including identity review for service accounts, tokens, and CI/CD access. Visibility debt is now the practical problem to solve: if the inventory is incomplete, risk reporting, prioritisation, and remediation all inherit the same blind spots. The NIST Cybersecurity Framework 2.0 provides a useful governance anchor here, especially for identifying and protecting assets before moving into detection and response.

The next phase of AI-era security will reward programmes that connect runtime exposure to asset criticality and machine identity ownership, not programmes that produce the most findings. That is where application security and NHI governance begin to converge in practice. When teams can see which identities move code, access secrets, and touch production, they can finally prioritise remediation as a risk decision rather than a queue-management exercise.


For practitioners

  • Build continuous application and API discovery Replace quarterly inventory exercises with continuous discovery that feeds AppSec, cloud, and identity governance reporting. Use it to track applications, APIs, and build-system dependencies as they change, not after the fact.
  • Tie remediation queues to business exposure Score findings using application criticality, data sensitivity, and internet exposure before work enters the backlog. This keeps high-risk issues from being buried under low-value scan output.
  • Reduce triage inflation with contextual prioritisation Limit manual review to findings that cross a defined exposure threshold, and automate suppression for low-signal categories that repeatedly generate noise. The goal is fewer decisions about irrelevant alerts and more decisions about exploitable risk.
  • Govern delivery-plane machine identities as part of AppSec Inventory the service accounts, tokens, and CI/CD credentials that let code move through build and deployment pipelines. Review their privilege scope and lifecycle alongside application security controls.

Key takeaways

  • AI-assisted development is already mainstream, which means AppSec now has to govern change at machine speed rather than review isolated code events.
  • The survey shows that tool abundance does not solve the harder problem of visibility, prioritisation, and business-risk measurement.
  • Teams that connect application security to machine identity governance will be better positioned to reduce exposure without drowning in triage.

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 address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5, NIST AI RMF and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
NIST CSF 2.0GV.OC-1The article centres on governance, visibility, and risk measurement across the app estate.
NIST SP 800-53 Rev 5CM-8Continuous inventory is the control most directly aligned to the visibility gap in this survey.
OWASP Non-Human Identity Top 10NHI-03Machine credentials in pipelines create the same lifecycle risk patterns seen in NHI governance.
NIST AI RMFMAPAI-assisted development changes risk identification and requires mapped context for decisions.
NIST Zero Trust (SP 800-207)AI-era pipelines rely on continuous trust decisions across tooling and service identities.

Use CSF governance and identify functions to connect application inventory, exposure, and board reporting.


Key terms

  • Triage Inflation: The condition where security teams receive findings faster than they can determine which ones matter. In AppSec, it usually signals weak context, poor prioritisation, or incomplete asset understanding, which causes remediation to slow even when tool coverage is high.
  • Visibility Debt: Visibility debt is the accumulated gap between what an organisation thinks it can see and what it can actually govern. In identity and data security, it grows when cloud resources, non-human identities, and data locations outpace discovery, making remediation slower and less accurate.
  • Delivery-Plane Machine Identity: The service accounts, tokens, and automated credentials that let code move through build, test, and deployment systems. These identities are operationally distinct from human users, but they still require ownership, privilege control, lifecycle management, and monitoring because they can alter production risk quickly.

What's in the full report

StackHawk's full report covers the operational detail this post intentionally leaves for the source:

  • The survey breakdown behind the 250+ AppSec stakeholder sample, including respondent seniority and organisational profile.
  • The full priority ranking of 2026 AppSec investments, including where AI security, visibility, and measurement sit relative to other initiatives.
  • The detailed chart set behind tool adoption, triage burden, and board reporting patterns.
  • The associated AppSec Leader's Guide to Survival in the AI Era, which provides the implementation framework behind the findings.

👉 StackHawk's full post covers the survey detail, investment priorities, and risk reporting gaps behind these findings.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course, the industry's only accredited NHI security programme. It is a practical fit for security and identity practitioners who need to govern machine access alongside human identity.
NHIMG Editorial Note
Published by the NHIMG editorial team on August 1, 2026.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org