Shadow AI Risk in Ungoverned Engineering Teams

Shadow AI in engineering teams isn't the same problem as shadow IT, and treating it that way is how organizations end up exposed. Shadow AI, as defined in the Cloud Security Alliance's 2026 findings, covers any model, tool, API, agent, or integration running without formal registration, risk assessment, policy governance, or security monitoring. Shadow IT looked like unauthorized SaaS subscriptions and rogue Dropbox folders, things a CASB tool could flag and procurement could shut down. Shadow AI, when it's engineers doing the shadowing, looks like production code.

That distinction matters because engineers don't just use unapproved tools. They build with them. An unauthorized Slack account is a nuisance. An unauthorized model wired into a CI/CD pipeline, processing customer data on its way to a database, is a different category of risk entirely, and it's one that most governance programs were never built to catch.

The scale backs this up. Per Reco's 2025 State of Shadow AI Report, cited in the CSA's 2026 findings, the vast majority of AI tools running inside enterprise environments sit outside IT's control, and the average organization has 269 shadow AI applications for every 1,000 employees. That number almost certainly understates things, since it counts installed apps, not the custom integrations engineers wire together themselves that never show up as an "app" at all. The scale is one problem. The harder question asks why the mechanisms that worked for cloud and SaaS haven't worked here, which starts with understanding how this stuff actually gets into engineering environments in the first place.

How ungoverned AI embeds itself in engineering workflows

Entry points for engineers look nothing like entry points for the rest of the business. A marketing team signing up for an unapproved analytics tool is a contained event. An engineer wiring an unapproved model into a live service is not.

Some of the most common paths in:

• Code assistants like GitHub Copilot or Cursor, run on personal accounts against corporate codebases, meaning the model sees proprietary source code, internal architecture, and business logic it was never cleared to see.
• Open-source models pulled straight from Hugging Face and dropped into production services with no security review at all.
• Third-party AI APIs wired into internal tools using personal or team API keys, often sitting in plaintext inside .env files or hardcoded into scripts.
• AI browser extensions that quietly intercept clipboard content and code snippets during normal development work.
• AI features baked into everyday SaaS tools (IDEs, monitoring dashboards, project trackers) that switch on without IT ever finding out.
• Agentic frameworks, MCP servers especially, connecting language models to corporate databases, Slack, GitHub, and internal APIs, all configured outside any formal review.
• Fine-tuned models trained on proprietary code or customer data, built without ever looping in privacy or compliance.

Once these things exist, they tend to stay. There's no process that tracks where an agent came from or forces its retirement, so agents built by employees who've since left the company can keep running, unmonitored, with no process forcing their retirement. API keys scattered across repos and CI/CD configs rarely get audited or rotated. And because these are things developers built themselves rather than "installed," they never register with the CASB tools or endpoint monitoring that security teams already have running.

There's a supply chain angle here too, and it's not small. JFrog's 2025 Software Supply Chain Report found a 6.5-fold jump in malicious models on Hugging Face within a single year, with more than a million new models added to that platform in 2024 alone. Every engineer pulling a model without verifying it first is exposed to that risk directly, in proportion to how little oversight exists around the pull.

What the attack surface looks like when ungoverned AI is embedded in production

Once these integrations exist, what can actually go wrong? Start with the most obvious: data walks out the door through the AI interface itself. Feed proprietary code, internal architecture docs, or customer records into an external model, and that data leaves organizational control the moment it's sent. Most consumer-facing AI tools have historically used submitted inputs to improve their own models. Policies differ by provider, but assuming retention by default is the only safe posture. Research into shadow AI behavior has found that a majority of shadow AI users admit to entering sensitive company data into unauthorized platforms, and among engineers, that data is often literal source code, internal API schemas, or customer records, not just a stray sentence in a chat window.

Agentic AI raises the stakes further. An agent spun up outside IT review can end up with far more access than its job requires, because the whole idea of least-privilege access breaks down structurally when nobody's reviewing the provisioning. Agents can leave behind persistent access points too: scheduled tasks, webhook registrations, database connections that keep running long after the person who built them has moved on. And there's a risk here with no real parallel in old-school shadow IT: prompt injection, where adversarial instructions buried in a document or a web page or a database record can hijack an agent's behavior mid-task. The CSA's 2026 report found that 65% of organizations experienced an AI agent security incident in the past year, and those incidents carried real business impact across the organizations that reported them.

Even setting aside training data exposure, sending PII, PCI, or PHI to an unapproved external model for inference is itself a disclosure event under GDPR, HIPAA, and CCPA. The processing alone creates the exposure, regardless of what happens downstream.

Underneath all of this sits a structural gap: nobody owns the whole lifecycle. Per the CSA's 2026 report, when no single function is responsible for an AI deployment from provisioning through monitoring through retirement, every one of those phases becomes its own opening. Cloud infrastructure got a shared responsibility model that everyone more or less understands. AI systems haven't gotten the same treatment yet, and the multi-vendor AI stack that results is one nobody can fully audit.

The financial and regulatory cost of letting shadow AI run ungoverned

The cost of all this is measurable. IBM's 2024 Cost of a Data Breach Report put the average breach at $4.88 million, a 10% jump year over year and the highest figure IBM has ever recorded. Per IBM's 2025 report, organizations with high levels of shadow AI paid $670,000 more per breach than organizations with minimal unauthorized AI use.

That premium says something specific: shadow AI breaches aren't a small markup on a normal breach. They're structurally more expensive, most likely because figuring out what an ungoverned model actually did with data it was never supposed to touch takes far more work than tracing a conventional intrusion. And the safety net is thin. Only 24% of organizations, per IBM's 2024 report, have put AI-specific data loss prevention controls in place. The gap between how exposed organizations are and how protected they are is wide. It's a canyon.

Regulation closes in from another direction entirely. The EU AI Act took effect August 1, 2024, with bans on prohibited practices kicking in February 2, 2025, and obligations for general-purpose models landing August 2, 2025. Full obligations for high-risk systems under Annex III, originally set for August 2026, got pushed to December 2, 2027 under the EU AI Omnibus. But here's the catch: a mandatory AI system inventory is a prerequisite for risk classification and conformity assessment under that law, and an organization can't inventory a system it doesn't know exists.

GDPR compounds the exposure. Cumulative fines under the regulation have topped €5.88 billion since 2018, and Article 5's storage limitation principle requires personal data be kept no longer than necessary. Send PII to an AI provider that retains prompts by default, and that principle is violated on contact. Frameworks like ISO/IEC 42001 and the NIST AI Risk Management Framework both start from the same premise: an organization has to govern its AI assets as a baseline capability before any of the more advanced controls mean anything.

Gartner projects shadow AI will cost enterprises more than $40 billion by 2027 in unplanned remediation, compliance penalties, and lost productivity, and per Gartner's 2025 research, organizations without AI governance spend 2.5 times more on incident remediation than those with real controls in place. The financial argument for governance isn't really in dispute. Policy, training, and acceptable use agreements, the tools most organizations reach for first, don't actually work when the people routing around them are the ones who write the code.

Why policy-only governance fails specifically for engineering teams

Confidence and capability have split apart. Per Delinea's 2025 report on machine identity security, 93% of organizations say they're confident in how they secure machine identities. Only 58% have comprehensive automated controls actually in place, and just 61% claim full visibility into their machine identities for monitoring. That gap between what organizations believe and what they can actually demonstrate is the whole problem in miniature.

Policy coverage looks decent on paper and thin in practice. Delinea's 2025 data shows 89% of organizations have some policy or control restricting AI access to sensitive data, but only 52% call their controls comprehensive. Only 57% have an acceptable use policy for AI tools at all, still the most basic control available, and still not universal. Access controls for AI agents and models sit at 55%. AI activity logging and auditing: also 55%. Identity governance for AI entities specifically: 48%.

For engineers, the failure mode is structural. They're the ones writing the integration code, so if governance depends on each developer remembering to follow policy, it won't hold. Different engineers make different calls, and those calls get baked into code that outlives whoever wrote it. Per Delinea's 2025 findings, 44% of organizations with AI in use report business units deploying AI without ever looping in IT or security, and in engineering, "deploying AI" often means modifying a live production system.

Bans make this worse, not better. Research consistently shows that nearly half of employees keep using personal AI accounts even after their company bans them outright, which just pushes the behavior further from view instead of stopping it. And per a 2025 survey of 461 security professionals, 83% of organizations lack automated AI controls altogether. The gap exists even though people know the risk exists. It's that there's no enforcement infrastructure standing behind the policy.

That's the accountability vacuum in a sentence: when no function owns the full lifecycle of an AI deployment, a policy is just a stated intention with nothing behind it. The orphaned agent, the API key nobody rotated, the fine-tuned model quietly running on a deprecated endpoint, each one is a policy failure that infrastructure controls would have caught structurally, without anyone needing to remember anything.

What infrastructure-layer AI governance requires in practice

Governance has to start with an inventory, full stop. Security teams can't govern what they can't see, and right now, most models, agents, and API integrations get provisioned with zero discovery process attached. The EU AI Act's risk classification requirements run into the same wall: a mandatory AI inventory is the prerequisite for conformity assessment, meaning the compliance mandate and the security mandate point at exactly the same starting line.

For engineering environments specifically, that inventory needs to cover deployed models, API keys and what each one is scoped to touch, agent registrations, MCP server configurations, fine-tuned model artifacts, and the provider accounts and credentials tied to all of it.

An LLM gateway is the piece that turns inventory into actual control. Picture it as a reverse proxy sitting between applications and model providers: instead of every team hand-rolling its own integration with its own scattered API keys, every request flows through one layer where routing, authentication, policy enforcement, and logging happen the same way, every time. The real difference between infrastructure governance and policy-dependent governance lies here. Policy enforcement happens automatically on every request, without depending on a developer to write that logic into their own application code.

A gateway layer, done right, opens up a set of capabilities that policy alone can't touch: redacting PII before a prompt ever reaches a provider, setting spend limits per team or per key, logging every request in one place instead of scattered across a dozen tools, routing around a provider outage automatically, and enforcing role-based access to specific models. Observability matters more here than it sounds. Bolt-on monitoring tools tend to produce fragmented traces that are a nightmare to debug across systems, while observability built natively into the gateway closes the gap between what was actually sent and what got logged. The industry is already moving this direction: growth trend analysis reported by TrueFoundry and others covering Gartner's research projects 70% of software engineering teams building multimodel applications will use an AI gateway by 2028, up from around 25% in 2025.

Identity has to extend to machines, not just people. Delinea's 2025 report recommends treating AI agents as identities subject to the same authentication, authorization, and monitoring that human users go through. Practically, that means an agent gets access only to the specific data sources and endpoints its job requires, not whatever the developer who built it happened to have access to. And lifecycle governance, provisioning, monitoring, and mandatory retirement, needs to be built into the system itself, so cleaning up an orphaned agent isn't dependent on someone remembering to do it months later.

Supply chain review for models can't be skipped either. Given the 6.5-fold rise in malicious models on Hugging Face in a single year documented by JFrog in 2025, pulling a model and running it straight into production without a formal review isn't a shortcut, it's a gamble. A model artifact registry with hash verification and provenance tracking, kept separate from the general build pipeline, closes that gap.

Behavioral monitoring rounds it out. Usage baselines, set per team, per key, per model, let anomalies get flagged when volume, data patterns, or provider routing shift in ways that don't fit the normal pattern. That calibration matters more for AI workloads than it would for conventional software, since AI spend swings by 40% or more month over month as a matter of course, with a median swing around 58%, per Ramp's July 2026 data. Baselines built for ordinary SaaS spend will miss that entirely.

Evaluating gateway options for teams moving from ungoverned to governed AI

Choosing a gateway comes down to a build-versus-buy call, and the tradeoffs are concrete. A team can build its own proxy layer in-house, or adopt one of the AI gateway products built specifically for this job. Each path carries real costs and real risks that deserve to be named clearly.

Building in-house gives full control over the architecture and no vendor dependency, but it means the engineering team now owns every future protocol change, every new provider integration, and every security patch, indefinitely. That's a real cost, and it tends to grow faster than teams expect once more providers and use cases get added.

Buying a purpose-built gateway trades some of that flexibility for speed and for a team already focused on keeping up with fast-moving provider APIs and security requirements. The evaluation questions that actually separate a strong option from a weak one:

• Does it support the model providers already in use, along with reasonable failover if one goes down?
• Does PII redaction happen before a prompt leaves the gateway, or only after the fact?
• Can access controls scope down to individual teams, individual keys, and individual endpoints, not just a blanket allow-or-deny switch?
• Is the audit log detailed enough to reconstruct what was sent to which provider and when, without stitching data together from three separate tools?
• Does spend monitoring account for the kind of swing typical of AI workloads, rather than flagging normal usage as an anomaly?

None of this replaces the inventory work or the identity governance work described above. A gateway is the control plane that makes those things enforceable at scale, not a substitute for doing them. Organizations still running policy-only governance for their engineering teams are, in effect, betting that discipline will hold up under pressure across every developer, every sprint, indefinitely. The data on breach costs, regulatory exposure, and agent incident rates says that bet doesn't pay off.