The Silent Majority: Developers Using Agents Without Telling Their Boss

There's a disconnect in the modern enterprise so wide you could drive a compliance team through it.

On one side sit the executives—the CISOs, the CTOs, the VP of Engineering—who report near-total confidence that they know exactly how AI is being used across their organizations. On the other side sit the developers—thousands of them, in every company large enough to have an IT department—who have quietly adopted AI tools their employers never approved, never vetted, and in many cases, don't even know exist.

This isn't a small crack in the wall. It's a structural failure. And the numbers behind it are more alarming than almost anyone in leadership positions realizes.

The Shadow AI Numbers: What the Surveys Actually Reveal

In early 2026, Okta published its "AI Agents at Work" report, one of the most comprehensive studies of enterprise AI adoption to date. The headline finding was reassuring: 90% of executives expressed confidence that they had full visibility into how AI tools were being used within their organizations. 95% were confident that their employees were using AI responsibly.

Those numbers feel safe. Comfortable, even. The kind of numbers that make a CISO sleep well at night.

Then the report dropped the second set of findings.

52% of employees admitted to using unapproved AI tools at work. Not occasionally. Not by accident. Deliberately. They sought out tools, signed up for accounts, and integrated AI assistants into their daily workflows without asking permission, without security review, and without any organizational oversight.

24% said they use unapproved AI tools regularly—meaning this isn't a one-time experiment. It's a habitual pattern embedded in how they work.

The gap between executive confidence (90% think they have visibility) and employee reality (52% using unapproved tools) represents one of the largest blind spots in modern enterprise security. And Okta isn't the only source telling this story.

Research Source	Key Finding
Okta "AI Agents at Work 2026"	52% use unapproved AI tools; 90% of execs think they have visibility
Menlo Security	57% use free-tier AI tools with personal accounts; 68% access through personal accounts
Awareways	73% use unapproved AI tools in some capacity
Lenovo Enterprise AI Report	70% of enterprise AI operates outside IT oversight
Cyberhaven	Endpoint-based AI agent usage grew 509% in 2025

Cyberhaven's number deserves special attention. Endpoint-based AI agent usage grew 509% in a single year. That's not adoption—that's an explosion. And only 16% of those agents were employer-authorized tools. The remaining 84% were tools employees found, installed, and started using on their own.

The picture these numbers paint is unambiguous: the majority of AI tool usage in enterprises is happening in the shadows. IT teams are managing a fleet of maybe 3 to 5 approved tools while the actual workforce runs 14 or more AI tools on average. The approved tools are visible. The rest are invisible until something goes wrong.

The Executive Blindspot: Confidence Without Evidence

The most dangerous sentence in enterprise technology is "we know what our people are using."

Executives aren't lying when they express confidence in their visibility. They genuinely believe they have a clear picture. And the reason they believe it is simple: the tools they know about are being used responsibly. The governance frameworks they built are working for the tools they designed them for. The problem isn't that governance fails—it's that governance was never designed for the reality of how modern developers actually work.

Here's how the blindspot forms, step by step:

Step 1: The approved tool list is created. IT security evaluates two or three AI tools, establishes data handling agreements, configures enterprise accounts, and publishes an approved tool list. This process is thorough, well-intentioned, and completely irrelevant to what happens next.

Step 2: Developers encounter friction. The approved tools don't always do what developers need. Maybe the enterprise tier is slow. Maybe it doesn't support the workflow the developer actually uses. Maybe the developer discovered a better tool through a blog post, a conference talk, or a friend at another company. Maybe the approved tool requires IT ticket approval that takes three days, and the developer has a production bug to fix today.

Step 3: The developer finds a workaround. They sign up for a free-tier account using their personal email. They install a VS Code extension directly. They use a CLI tool that requires no IT involvement. They access an AI model through an API endpoint they set up on their own. None of these actions require approval, and most of them don't even trigger the monitoring tools IT has in place.

Step 4: The workaround becomes a habit. Within days, the unapproved tool is part of the developer's daily workflow. They're faster, more productive, and happier. They're also now transmitting company code to a service that has no data processing agreement with their employer.

Step 5: Nobody notices. IT checks the approved tools' usage dashboards and sees healthy adoption numbers. Everything looks fine. The 14 unapproved tools running across the organization are completely invisible to the governance framework.

This isn't a story about malicious employees. It's a story about competent, motivated people solving problems with the best tools available to them—without understanding the security implications of what they're doing.

The executives' confidence isn't wrong about the intent of their workforce. It's wrong about the behavior. People aren't misusing AI tools. They're using them exactly as intended—for work. The problem is that the organizational infrastructure wasn't built for a world where any developer can provision a new AI capability in thirty seconds with a credit card and a browser tab.

What Developers Are Actually Doing: The Unapproved Toolkit

To understand the scale of shadow AI, you need to understand what developers are actually sending to these unapproved tools. The data here comes from Okta's research and is worth examining closely.

Data Types Being Shared with Unapproved AI Tools

Data Category	% Sharing via Unapproved Tools	Risk Level
Internal messages and emails	54%	High
HR-related information	45%	Critical
Confidential business documents	39%	Critical
Source code	~47% (estimated)	Critical
Customer data	~28% (estimated)	Critical

54% of employees who use unapproved AI tools have shared internal messages and emails with those tools. Internal communications often contain context that, while not classified on its own, reveals strategic thinking, pending decisions, personnel issues, and competitive intelligence. When you paste a Slack thread into an AI tool, you're not just sharing the text—you're sharing the context around it.

45% have shared HR-related information. This includes performance reviews, salary discussions, team restructuring plans, and hiring information. If a developer uses an AI tool to "help draft" a performance review and pastes the previous review as context, that employee's sensitive data is now sitting on a third-party server with no data processing agreement.

39% have shared confidential business documents. Product roadmaps, financial projections, partnership terms, M&A discussions—these are the documents that companies protect with NDAs, access controls, and need-to-know policies. And nearly four in ten employees using unapproved AI tools have shared them with services that have none of those protections.

The issue isn't just what's being shared—it's that there is no audit trail. When a company uses an approved AI tool with enterprise data handling, every interaction is logged, monitored, and auditable. When a developer pastes a confidential document into a free-tier AI tool using their personal account, that interaction is invisible to the organization. The data has left the building, and nobody inside the building knows it happened.

The Convenience Problem: Why Developers Don't Ask Permission

If shadow AI is so risky, why don't developers just ask permission? The answer is rooted in a fundamental mismatch between how enterprises govern technology and how developers actually work.

The Friction Gap

In a typical enterprise, getting approval to use a new AI tool involves:

1. Submitting a request to IT security
2. Security evaluating the tool's data handling practices
3. Legal reviewing the terms of service
4. Procurement negotiating an enterprise agreement
5. IT configuring the enterprise deployment
6. The developer finally getting access

Timeline: 2 to 8 weeks.

Meanwhile, the developer can sign up for a free-tier account of almost any AI tool in under two minutes. The tool is immediately available, immediately useful, and requires zero organizational involvement.

When you frame it this way, shadow AI isn't a behavior problem. It's a systems design problem. Enterprises have created governance processes that assume technology adoption is a deliberate, slow, organizational decision. The reality is that AI tool adoption happens at the speed of a web browser and a free email account.

The Productivity Trap

Here's the part that makes this genuinely difficult to solve: the shadow tools work. Developers using unapproved AI tools are measurably more productive than those restricted to approved tools alone. They're shipping faster, solving problems more quickly, and building better features.

This creates an organizational catch-22. If you crack down on shadow AI, you risk slowing down the very developers whose productivity gains are keeping the company competitive. If you ignore it, you accumulate security risks that compound with every shared document and every copied code snippet.

The right response isn't to choose between security and productivity. It's to build governance frameworks that accommodate the reality of how developers work—fast, independently, and tool-agnostically—while still maintaining the security controls that protect the organization.

Shadow Agents: Not Just Shadow AI

Everything described so far—free-tier tools, unapproved browser extensions, personal API keys—is shadow AI. But there's a newer, more consequential category that most enterprises haven't even conceptualized yet: shadow agents.

What Makes Shadow Agents Different

Shadow AI is about using an unapproved tool. Shadow agents are about using an unapproved tool that takes actions on your behalf—executing commands, reading files, modifying code, and making decisions with real consequences.

Tools like Claude Code, Cursor, and similar agentic coding assistants don't just generate text. They:

• Execute shell commands on the developer's machine
• Read environment files containing API keys, database credentials, and secrets
• Access the full file system of the development environment
• Modify production code across multiple files and repositories
• Connect to external services through the developer's network and credentials

When a developer installs Claude Code or Cursor on their work machine without IT's knowledge, they aren't just using an unapproved chatbot. They're installing a developer-level autonomous agent that can read, write, and execute with the full privileges of that developer's account.

The Privilege Problem

Consider what happens when a developer installs an agentic coding tool on their enterprise workstation:

• The agent can read .env files containing database passwords, API keys, and cloud credentials.
• The agent can access git history, including commits that may contain secrets or sensitive logic.
• The agent can execute arbitrary commands, including commands that upload data to external services.
• The agent can read and modify any file the developer has access to, which in many enterprises includes production databases, internal APIs, and customer data stores.
• The agent's traffic is encrypted, often goes through the developer's personal account, and is invisible to enterprise network monitoring.

This isn't a hypothetical risk. This is the default behavior of these tools. They are designed to be maximally useful, which means they need maximal access. And when they're installed outside the enterprise's governance framework, that maximal access is unmonitored and uncontrolled.

The Scale of the Shadow Agent Problem

Cyberhaven's research found that endpoint-based AI agent usage grew 509% in 2025, and this trajectory has only accelerated in 2026. The vast majority of these agents are running on personal accounts, not enterprise licenses.

Shadow Agent Metric	Value
Growth in endpoint-based AI agents (2025)	509%
Running on personal/non-enterprise accounts	84%
Average AI tools active per enterprise	14
AI tools IT is aware of	3-5
Enterprises with security controls on AI agents equal to humans	34%

That last number is particularly striking. Only 34% of enterprises apply the same security controls to AI agents as they do to human employees. Think about what that means. A human developer logging into your systems goes through identity verification, access controls, activity monitoring, and behavioral analytics. An AI agent running on that same developer's machine, accessing the same systems, bypasses all of those controls when it's installed outside the enterprise stack.

The gap between the 14 tools running and the 3-5 IT knows about represents 9 to 11 fully unmonitored AI capabilities operating within the average enterprise. Some of those are probably harmless. Some of them have access to your most sensitive data. And you have no way of knowing which is which.

The Security Risks Nobody Talks About

The obvious risk of shadow AI is data leakage—sensitive information being sent to third-party services without proper agreements. But the security risks of shadow agents go considerably deeper.

Risk 1: Credential Exposure

When an AI agent reads a .env file to "understand the project context," it ingests every credential in that file. If the agent is running on a personal account, those credentials are now associated with a personal identity rather than a corporate one. If the agent's provider is breached, if the personal account is compromised, or if the agent's data retention policy differs from the enterprise's, those credentials are exposed in ways the security team cannot detect or prevent.

Risk 2: Proprietary Code Exfiltration

AI coding agents work by sending code to cloud-based models for processing. Even when providers claim they don't store or train on user code, the code still transits through their infrastructure. For proprietary algorithms, trade secrets, and competitive advantages embedded in code, this represents an uncontrolled exposure vector. The developer sees it as "getting help with a function." The security team, if they knew, would see it as "sending source code to an unvetted third-party processor."

Risk 3: Supply Chain Attacks

When an AI agent executes shell commands or installs packages as part of its workflow, it creates a new supply chain attack surface. A compromised AI tool could inject malicious dependencies, modify code in subtle ways, or create backdoors that are nearly impossible to detect through standard code review. The developer trusts the agent's output in ways they wouldn't trust output from an unknown source—because the agent is their tool, running on their machine.

Risk 4: Compliance Violations

For enterprises subject to GDPR, HIPAA, SOC 2, ISO 27001, or similar frameworks, shadow AI creates compliance violations that the organization may not discover until an audit or a breach. When employee data, customer data, or regulated data is processed by unapproved tools, the organization's compliance posture is compromised—even if the data was shared with good intentions.

Risk 5: Institutional Knowledge Loss

When developers use personal AI accounts to understand and work with enterprise code, the context and reasoning are captured in the AI tool's conversation history—tied to the developer's personal account, not the organization's. When that developer leaves, the organization loses not just the employee but also the AI-mediated context that helped them understand the codebase.

What Good AI Governance Actually Looks Like

The answer to shadow AI isn't prohibition. Prohibition doesn't work when the barrier to non-compliance is a free email account and thirty seconds of time. The answer is governance that's fast enough, flexible enough, and useful enough that developers choose to use the approved path.

Principle 1: Reduce the Friction Gap

The single most effective thing an enterprise can do to reduce shadow AI is to make the approved path nearly as fast as the shadow path. This means:

• Pre-approved tool catalog with instant access. Developers should be able to enable approved AI tools without a ticket, without a meeting, without a waiting period. If the catalog is comprehensive enough, most developers won't bother with unapproved alternatives.

• Sandboxed evaluation environments. Give developers a way to evaluate new tools against synthetic or de-identified data. If they can test a tool's capabilities without exposing real data, the incentive to use personal accounts drops dramatically.

• Streamlined procurement for AI tools. The procurement process for AI tools needs to be fundamentally different from the process for, say, a new enterprise database. AI tools are lightweight, low-cost, and high-velocity. The governance process should match.

Principle 2: Make the Approved Tools Better Than the Shadow Tools

If developers are using shadow AI because the approved tools are slower, dumber, or less capable, the fix isn't better enforcement—it's better tools. This means:

• Regularly benchmarking approved tools against the market. If Claude Code's enterprise tier is significantly worse than the free tier, developers will use the free tier. Period.

• Allowing model flexibility within approved boundaries. Give developers a menu of approved models and tools rather than a single mandated option. The developer who wants Claude for architecture and Cursor for UI work should be able to do both within the approved framework.

• Investing in custom configurations. The enterprise should build custom prompts, templates, and workflows for its approved tools that make them more useful for the specific codebase and team conventions. An approved tool that's been customized for your environment will always beat a generic shadow tool.

Principle 3: Monitor Without Micromanaging

The goal of monitoring isn't to catch developers doing wrong—it's to understand what's happening so you can govern effectively. This means:

• Network-level visibility into AI tool usage. Not to block, but to know. Understanding which services are receiving data from your environment is a baseline security requirement.

• Endpoint monitoring for AI agent installation. Not to prevent, but to catalog. If you know which agents are running and what they have access to, you can make informed risk decisions.

• Usage analytics on approved tools. Understanding how developers use approved tools helps you optimize the tool selection, configuration, and training.

Principle 4: Educate, Don't Just Mandate

Most developers sharing data with unapproved AI tools aren't being careless—they're being uninformed. They don't understand the data handling practices of the tools they're using, and they don't realize that pasting a Slack thread into a chatbot has security implications. Effective governance includes:

• Practical training on AI data handling. Not "don't use AI tools" but "here's what happens to data when you use these specific tools, and here's how to use them safely."

• Clear, simple guidelines. "Don't paste customer data or credentials into AI tools" is a guideline developers can follow. A 40-page acceptable use policy is a guideline that gets ignored.

• Regular communication about approved alternatives. When IT proactively tells developers "we've added this new tool to the approved list, here's how to use it," it demonstrates that the organization is keeping pace with the tools developers want.

The Indian Enterprise Context: Unique Challenges, Unique Opportunities

India's enterprise landscape has specific characteristics that make the shadow AI problem both more acute and more solvable than in Western markets.

Why Shadow AI Hits Indian Enterprises Harder

1. Scale of the developer workforce. India has over 5.8 million professional developers, and that number is growing rapidly. The sheer scale means that even a small percentage of shadow AI usage represents a large absolute number of unmonitored tools and data flows.

2. IT services model. India's massive IT services sector (TCS, Infosys, Wipro, HCL, and thousands of mid-tier firms) operates on a model where developers work across multiple client environments. A developer at a services firm might use shadow AI tools while working on a client's codebase, exposing that client's data to services the client never approved. This creates a multi-party risk that's unique to the services model.

3. Rapid adoption, slow governance. Indian developers adopt AI tools at rates above the global average (71% daily usage vs. 68% globally, per JetBrains data), but Indian enterprises have formal AI coding policies at rates below the global average (41% vs. 55%). This gap between grassroots adoption and organizational readiness creates exactly the conditions where shadow AI thrives.

4. Cost sensitivity driving free-tier usage. Indian enterprises, particularly mid-market companies and startups, are more likely to use free-tier AI tools rather than enterprise licenses. Free-tier tools typically have weaker data handling, no audit trails, and no enterprise data processing agreements. The economic incentive to use free tools amplifies the security risk.

Why India Is Also Better Positioned to Solve It

The same characteristics that make India's shadow AI problem acute also make it solvable:

1. Young, adaptable workforce. India's developer population skews younger and more technically adaptable. This means governance frameworks can be adopted quickly once they're designed well and communicated clearly.

2. IT services companies as governance laboratories. India's IT services firms already have sophisticated governance frameworks for client data, security, and compliance. Extending these frameworks to cover AI tools is a natural evolution, and the firms that do it first gain a competitive advantage in winning security-conscious global clients.

3. Homegrown AI ecosystem. India is developing its own AI tools and platforms that can be designed with enterprise governance from day one, rather than retrofitting governance onto tools built for Western markets. Companies like MojoStudio that build with both productivity and governance in mind are positioned to serve this need.

4. Regulatory momentum. India's Digital Personal Data Protection Act and emerging AI governance frameworks from NASSCOM and MeitY are creating regulatory pressure that will push enterprises toward formal AI governance. Early movers will have an advantage.

MojoStudio Recommendations: A Practical Governance Framework

At MojoStudio, we work with enterprises navigating the shadow AI challenge every day. Based on our experience building AI-powered development workflows and helping teams adopt coding agents responsibly, here's our practical framework:

For Enterprises: The 30-Day Shadow AI Assessment

Week 1: Discovery

• Deploy network monitoring to identify AI tool traffic (don't block—just observe)
• Survey development teams about AI tools they use, approved and unapproved
• Catalog the gap between IT's known tools and actual usage

Week 2: Risk Prioritization

• Categorize shadow tools by data exposure risk (credentials, source code, customer data, internal communications)
• Identify the highest-risk data flows and the tools enabling them
• Assess which shadow tools could be replaced by approved alternatives

Week 3: Approved Tool Expansion

• Based on discovery findings, expand the approved tool catalog to include the most commonly used shadow tools (in enterprise tiers with proper data handling)
• Configure enterprise accounts with appropriate data isolation and audit logging
• Prepare training materials for developer teams

Week 4: Communication and Migration

• Communicate to development teams: "We've heard you, we've added these tools to the approved list, here's how to migrate your workflow"
• Provide migration support for developers moving from personal to enterprise accounts
• Establish ongoing monitoring and quarterly review cadence

For Development Teams: Secure Agent Usage Guidelines

If you're a developer using coding agents, here's how to protect yourself and your organization:

1. Never paste credentials, API keys, or secrets into any AI tool. Not even approved ones. Use environment variable references, not actual values.

2. Use enterprise accounts for all AI tools used for work. Personal accounts create personal risk and organizational blind spots.

3. Understand your tool's data handling. Know whether your code is used for training, how long it's retained, and where it's processed.

4. Ask for the tools you need. Most organizations will approve tools that developers can articulate a clear business case for. Don't go around the system—push the system to keep up.

5. Be especially careful with client data. If you work in a services environment, your client's data deserves the same protection whether it's in a database or a chatbot prompt.

The Path Forward: Governance That Keeps Up

The shadow AI problem is ultimately a speed problem. Technology adoption moves at internet speed. Enterprise governance moves at committee speed. As long as that gap exists, shadow AI will fill it.

The enterprises that solve this problem won't be the ones with the strictest policies. They'll be the ones with the fastest governance—the ones that can evaluate, approve, and deploy new AI tools in days rather than months. They'll be the ones that treat AI tool governance as a product, not a policy document. They'll measure their success not by how few unapproved tools are in use, but by how few need to be unapproved.

For Indian enterprises specifically, this is a moment of competitive opportunity. The companies that build effective AI governance now—fast enough to match developer velocity, comprehensive enough to address real security risks, practical enough that developers actually follow it—will be better positioned to win global enterprise contracts, attract top developer talent, and ship faster with fewer surprises.

The silent majority isn't going to stop using AI tools. The question is whether your organization will be the reason they stop whispering.

---

Frequently Asked Questions

1. What exactly is "shadow AI" and how is it different from regular AI adoption?

Shadow AI refers to the use of AI tools, services, or agents within an organization without the knowledge, approval, or oversight of IT, security, or management. Regular AI adoption follows a deliberate process: evaluation, approval, procurement, deployment, and monitoring. Shadow AI skips all of those steps. The key distinction is organizational visibility—if the company doesn't know a tool is being used, it's shadow AI. This includes everything from using ChatGPT with a personal account to handle work tasks, to installing coding agents like Claude Code on a work machine without IT approval.

2. How widespread is shadow AI in enterprises really?

Very widespread. Multiple independent studies converge on similar numbers: Okta found 52% of employees use unapproved AI tools, Awareways found 73%, and Lenovo found 70% of enterprise AI operates outside IT oversight. The average enterprise has approximately 14 AI tools active but IT is only aware of 3 to 5. The gap between actual and perceived AI usage represents one of the largest blind spots in enterprise security.

3. Why do executives think they have visibility when they clearly don't?

Executive overconfidence in AI visibility stems from several factors. First, the tools they know about are being used responsibly, which creates a false sense that all AI usage is similarly governed. Second, AI adoption is so fast that governance frameworks can't keep up—executives built policies for a world of 2-3 approved tools and haven't updated for a world of 14+. Third, the people experiencing the gap (developers) don't report it upward because they don't see their unapproved usage as problematic. The oversight gap is structural, not intentional.

4. What's the difference between shadow AI and shadow agents?

Shadow AI is using an unapproved AI tool (like ChatGPT via a personal account). Shadow agents are a more serious category: unapproved tools that take autonomous actions on your behalf. When a developer installs Claude Code or Cursor without IT knowledge, they're installing an agent that can execute shell commands, read credential files, access the full file system, and modify code—essentially running with developer-level privileges outside any organizational monitoring. Shadow agents have a much larger potential blast radius than passive AI tools.

5. What kind of data are employees actually sharing with unapproved AI tools?

The numbers are significant: 54% have shared internal messages and emails, 45% have shared HR-related information (performance reviews, salary data), 39% have shared confidential business documents, and an estimated 47% have shared source code. The data is often shared casually—pasted into a chatbot for help with a task—without understanding that it's now stored on a third-party server with no data processing agreement with the employer.

6. What security risks does shadow AI create for enterprises?

Shadow AI creates five major risk categories: (1) credential exposure, when AI agents read .env files containing API keys and passwords on personal accounts; (2) proprietary code exfiltration, as source code is processed by unvetted cloud services; (3) supply chain attacks, where compromised AI tools inject malicious code; (4) compliance violations for GDPR, HIPAA, SOC 2, and similar frameworks; and (5) institutional knowledge loss when AI conversation history is tied to personal accounts that employees take when they leave.

7. How should enterprises address shadow AI without destroying developer productivity?

Prohibition doesn't work. The most effective approach has four pillars: (1) reduce the friction gap by making approved tools nearly as fast to access as shadow tools, (2) make approved tools better than shadow tools through regular benchmarking and customization, (3) monitor AI tool usage at the network and endpoint level without micromanaging, and (4) educate developers on data handling rather than just mandating restrictions. The goal is governance that's fast enough that developers choose the approved path voluntarily.

8. Is the shadow AI problem worse in Indian enterprises than in Western ones?

India has a unique mix of factors. Indian developers adopt AI tools faster (71% daily usage vs. 68% globally) but Indian enterprises have formal AI policies at lower rates (41% vs. 55% globally). The IT services model, where developers work across multiple client environments, creates multi-party risk. Cost sensitivity drives higher free-tier usage, which has weaker data handling. However, India's young workforce, existing IT governance expertise, and emerging regulatory frameworks position it well to solve the problem. Companies like MojoStudio are helping Indian enterprises build governance that matches developer velocity.

9. What should a developer do if their company doesn't have approved AI tools for the ones they need?

The best approach is to make a business case rather than go around the system. Document the productivity gains, identify the specific data handling concerns, and propose the enterprise tier of the tool you need. Most organizations will approve tools that developers can articulate a clear need for. In the meantime, follow safe practices: use personal accounts only for non-sensitive work, never paste credentials or customer data into AI tools, and advocate for faster governance processes. If your organization's approval process takes weeks, that's a systems problem that leadership needs to hear about.

10. How does MojoStudio help enterprises navigate the shadow AI challenge?

At MojoStudio, we help enterprises in two ways. First, we build AI-augmented development workflows that are designed with governance from the start—approved tools, proper data handling, audit trails, and enterprise-grade configurations. Second, we help teams conduct the kind of rapid shadow AI assessment described in this article, identifying what's actually being used, prioritizing the risks, and building practical governance frameworks that match developer velocity. The goal isn't to restrict AI usage—it's to make the governed path the best path.