AI risk management is strained by shadow AI and fragmented controls

At a glance

What this is: This infographic summarises 2026 AI security findings showing that agentic AI, AI-generated vulnerabilities, and tool fragmentation are already shaping enterprise risk decisions.

Why it matters: It matters to IAM practitioners because AI systems increasingly behave like governed identities and tool users, so visibility, authorisation, and lifecycle controls must extend into development and runtime.

By the numbers:

• 66% report extensive AI use in software development.
• 78% have deployed or are piloting agentic AI systems.
• 70% report AI-generated vulnerabilities in production.
• 81% say fragmented security tools make risk prioritisation harder.

👉 Read ArmorCode's State of AI Risk Management 2026 infographic

Context

AI risk management is becoming an operational control problem, not just a model-governance problem. When agentic AI enters software development and production workflows, organisations must understand who or what is making decisions, what tools those systems can reach, and how security teams will distinguish normal AI behaviour from risky automation. That creates a direct governance overlap with identity, privilege, and lifecycle control.

The article’s numbers point to a familiar pattern in a new form: adoption is rising faster than the control plane around it. For IAM and security teams, the real issue is not whether AI is present, but whether access, monitoring, and accountability scale with it. That is especially true where AI systems interact with secrets, code, deployment pipelines, and production data.

This is an AI security problem first, but it has a genuine identity angle because agentic systems often act through credentials, tokens, and delegated permissions. The starting position is typical for fast-moving AI adoption programmes and atypical only in how clearly the governance gap is now visible.

Key questions

Q: How should security teams govern agentic AI that can execute IAM tasks?

A: Start by treating the agent as an NHI with bounded authority, explicit ownership, and revocation procedures. Require human approval for high-risk actions, log every decision path, and enforce least privilege at the workflow level. If the agent cannot be audited or rolled back, it is not yet ready for autonomous IAM execution.

Q: Why do AI-discovered vulnerabilities create governance pressure for security teams?

A: Because discovery speed changes the workload profile. Teams must now validate findings, prioritise by business impact, and coordinate patching across technical and identity controls at a much faster pace. If asset inventories, privileged access maps, or exception processes are weak, the discovery pipeline simply magnifies those gaps.

Q: What do security teams get wrong about Shadow AI?

A: They often treat Shadow AI as an approval problem for software, when it is usually also an identity problem. The hidden risk can be an undocumented token, an over-permissioned service account, or an autonomous agent with unreviewed reach. Inventory the identity layer before you decide the tool is the issue.

Q: How can organisations tell whether their AI security model is actually working?

A: They should test whether the control stack can explain who acted, what data was touched, and what purpose the action served. If those three signals cannot be correlated in one incident view, the model is likely monitoring access without governing behaviour. That is a visibility gap, not a complete AI security posture.

Technical breakdown

Agentic AI in software development and production

Agentic AI systems do more than generate text or code suggestions. They can select actions, call tools, and move through workflows with a level of runtime discretion that creates a governance problem similar to identity access management. In development environments, that means a model may interact with source code, CI/CD pipelines, test data, or ticketing systems through delegated credentials. The security challenge is not just model output quality. It is whether the surrounding controls can describe and constrain what the system is allowed to do.

Practical implication: treat agentic AI as a governed runtime actor and map every tool connection to an owner, purpose, and approval boundary.

AI-generated vulnerabilities and code trust boundaries

AI-generated vulnerabilities in production usually reflect weak trust boundaries around generated code, not just poor prompting. Code assistants and autonomous coding flows can introduce unsafe patterns, insecure dependencies, or misconfigured infrastructure into release pipelines at speed. Once that code is accepted into a build or deployment path, traditional review processes can miss the root cause because the output looks like ordinary software change. Security teams need to understand the provenance of generated artefacts and where human review is still required.

Practical implication: add provenance, review gates, and policy checks before AI-generated code reaches a deployable branch.

Security tool fragmentation and prioritisation failure

Fragmented security tools make AI risk harder to govern because each control view sees only part of the attack surface. One tool may detect exposed code, another may monitor cloud runtime, and a third may track identity events, but none of them on their own can explain whether an AI workflow is overreaching. This is where control design fails: the organisation collects alerts faster than it can decide which ones represent AI-specific exposure. The result is prioritisation fatigue.

Practical implication: consolidate AI-related telemetry into a single triage model that links identity, code, and runtime signals.

Threat narrative

Attacker objective: The attacker objective is to use AI-enabled workflows to introduce, amplify, or conceal exploitable weaknesses inside production systems and software delivery pipelines.

1. Entry occurs when AI is embedded into development or workflow tools and granted access to code, data, or automation interfaces through delegated credentials or API tokens.
2. Escalation happens when the system generates insecure code, interacts with sensitive resources beyond intended scope, or chains tools in ways the security team did not model.
3. Impact follows when vulnerable code reaches production or when fragmented controls prevent teams from identifying which AI activity introduced the risk.

NHI Mgmt Group analysis

AI governance debt is now an operational security problem. The article’s findings show that adoption, experimentation, and production use are advancing faster than the governance layer around them. That means security teams are inheriting risk from development practices that were never designed for AI-mediated action. The practical conclusion is that AI oversight must move from policy language to runtime control.

Agentic AI needs identity boundaries, not just model guardrails. When an AI system can call tools, touch code, or trigger deployment steps, the real question becomes what identity it is using and how that identity is limited. This is where NHIMG’s identity lens matters: credentials, delegated permissions, and auditability become the control points that determine whether AI remains inside its intended task boundary. Practitioners should treat AI access like any other privileged workflow.

Fragmentation is the new prioritisation failure. The article shows that organisations are struggling not because they lack alerts, but because they cannot connect AI-generated risk across code, runtime, and identity telemetry. That creates a named concept worth tracking: AI risk prioritisation drag: the delay between detecting AI-related exposure and proving which control failed. Security leaders should assume this drag will increase unless they rationalise telemetry and ownership.

Shadow AI is a governance discovery problem before it is a threat problem. Untracked AI usage creates unknown control paths, and unknown control paths always expand the blast radius of identity mistakes. The security programme implication is clear. Discovery, inventory, and ownership assignment for AI systems should be treated as foundational controls rather than optional hygiene.

The control model must follow the workflow, not the vendor category. Agentic AI in software development links AI governance, IAM, PAM, and secure SDLC practices into one operating model. Organisations that keep these functions separated will continue to miss the combined risk. The practitioner takeaway is to align AI oversight with identity, code, and deployment governance as a single control problem.

What this signals

AI governance debt: the longer organisations allow AI workflows to expand without ownership and identity boundaries, the harder it becomes to reconstruct which action caused a vulnerability or control failure. That is why discovery and lifecycle management should now sit alongside AI policy as programme-level controls, not follow them.

For identity and security teams, the next step is to connect AI telemetry to the same governance model used for service accounts and API tokens. The practical reference point is the NIST AI Risk Management Framework, while the control challenge is to make sure access review, logging, and revocation apply to AI systems that can act at runtime.

This topic also widens the gap between visibility and control. A system can appear monitored yet still behave outside the intended permission boundary if its credentials, tools, and workflow ownership are not tracked together. Practitioners should prepare for a phase where AI governance is judged by traceability, not by policy volume.

For practitioners

• Establish an agent inventory Build a complete register of AI systems, agents, and workflow automations that can access code, data, or production tools. Include owner, purpose, permissions, and the credentials or tokens each system uses so unmanaged access does not become shadow AI.
• Bind AI workflows to scoped identities Issue separate credentials for each AI workflow and restrict them to the minimum tools, repositories, and environments required for the task. Avoid shared service accounts that make it impossible to attribute or revoke access cleanly.
• Add provenance checks for generated code Require review and policy enforcement before AI-generated code or configuration reaches production branches. Capture source, prompt context where appropriate, and reviewer approval so security teams can trace how risky artefacts entered the pipeline.
• Unify AI security telemetry Correlate identity events, code scanning results, cloud runtime signals, and workflow logs in one triage path. This gives security teams a way to prioritise AI risk by impact rather than by whichever tool raised the latest alert.

Key takeaways

• AI adoption is already inside the software delivery chain, which means security teams are now governing machine-mediated actions, not just model outputs.
• The reported 70% production vulnerability figure shows that AI risk has crossed from experimentation into operational exposure.
• The control response is to unify identity, code, and runtime governance so AI workflows remain observable, scoped, and revocable.

Key terms

• Agentic AI: Autonomous AI systems capable of planning, deciding, and taking actions — including calling APIs, writing code, and orchestrating other agents — with minimal human oversight. Agentic AI introduces new NHI risks as agents must authenticate to external services.
• Shadow AI: AI agents, copilots, or connected tools operating without full visibility or governance from security teams. Shadow AI becomes an identity problem when those systems authenticate with unmanaged tokens, service accounts, or OAuth apps that can reach production resources.
• AI risk prioritisation drag: AI risk prioritisation drag is the delay between detecting AI-related exposure and determining which control failure created it. It usually appears when identity, code, cloud, and runtime signals are split across separate tools, making it difficult to assign ownership or choose the right remediation path.

What's in the full report

ArmorCode's full infographic covers the operational detail this post intentionally leaves for the source:

• Breakdown of how organisations are using AI in development, pilot, and production environments.
• The underlying survey data behind the agentic AI and vulnerability findings.
• Related visual segments on risk prioritisation and tool fragmentation.
• The report context that links these results back to broader AI security management practices.

👉 ArmorCode's full infographic shows the underlying survey findings and visual breakdowns behind the AI risk data.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, identity lifecycle, and secrets management. It is designed for practitioners who need to connect identity controls to broader security operations and AI-enabled workflows.