Shadow engineering is the use of technologies — AI tools, frameworks, libraries, infrastructure components — that haven't been evaluated, approved, or documented by security and platform teams. It's the engineering-specific variant of shadow IT, and it's growing faster than any other category.
Why Shadow Engineering Is Different
Traditional shadow IT involves business users adopting SaaS tools without IT approval. Shadow engineering is fundamentally different:
- It ships to production. A marketing team using unapproved Canva doesn't change your attack surface. A developer using an unapproved npm package does.
- It's invisible at the procurement layer. Developers install open-source packages with
npm install, not purchase orders. - It compounds. Every unsanctioned dependency brings its own transitive dependencies. One unapproved package can introduce hundreds of unknowns.
- AI accelerates it. AI coding assistants suggest libraries and patterns that developers adopt without explicit evaluation.
The Scale of the Problem
A typical enterprise engineering organisation:
- Documents 50-100 approved technologies in their registry
- Actually uses 2,000-5,000 distinct technologies across all repositories
- Has 60%+ of developers using AI coding tools that haven't been through security review
- Ships code with an average of 700+ transitive dependencies per Node.js application
The gap between documented and actual is your ungoverned attack surface.
Detection Methods
Build Artifact Inspection
The most reliable detection method. Inspect every build artifact to identify all technologies compiled, bundled, or packaged into the output:
- Direct and transitive dependency enumeration
- Framework and runtime detection
- Vendored code identification
- Infrastructure component discovery from container layers
Build inspection catches everything that makes it into the artifact, regardless of how it got there.
Desktop Monitoring
For AI coding tools that don't leave traces in build artifacts:
- Detect AI coding assistant activity (Copilot, Cursor, Claude Code, etc.)
- Identify which models and providers are in use
- Track adoption patterns across the organisation
- Distinguish sanctioned from unsanctioned tool usage
Desktop monitoring observes coding tool activity at the OS level — no IDE plugins required.
Repository Analysis
Complement build inspection with source-level analysis:
- Package manifest scanning (package.json, requirements.txt, go.mod)
- Import statement analysis
- Configuration file detection
- CI/CD pipeline inspection
From Detection to Governance
Detection alone is insufficient. The workflow:
- Discover — Identify all technologies in use through build inspection
- Classify — Auto-categorise by type, risk level, and licence
- Assess — Route high-risk technologies to security review
- Decide — Approve, block, or mark as pending review
- Enforce — Block builds that use blocked technologies; alert on pending
- Track — Monitor adoption trends and migration progress over time
Policy Examples
- AI tools: Only approved AI coding assistants may be used. Unapproved tools detected by desktop monitoring trigger a review workflow.
- Data residency: Block packages and tools with data processing in specific jurisdictions.
- Licence compliance: Prevent copyleft-licensed packages in proprietary builds.
- End-of-life: Alert when technologies reach end-of-life status.
Balancing Governance and Velocity
The goal is not to prevent all unapproved technology adoption. That creates friction that drives developers to work around governance entirely. Instead:
- Make approval lightweight — Hours, not weeks. Security review should be proportional to risk.
- Auto-approve low-risk changes — New patch versions of approved packages don't need human review.
- Block only clear violations — Reserve hard blocks for known-malicious packages and policy violations.
- Provide visibility, not just enforcement — Teams should see their own technology footprint and make informed decisions.
The most effective governance systems are the ones developers barely notice for routine changes but catch the important exceptions.
Connecting to Code Ownership
Shadow engineering detection is most effective when combined with code ownership data:
- Who introduced this technology? — Git history identifies the developer and team
- Which team should evaluate it? — Route to the team with the most context
- Is there an existing standard? — Check if an approved alternative exists
- What's the migration path? — If blocked, ownership data identifies who needs to migrate
This combination of visibility (what's in use) and accountability (who's responsible) is the foundation of effective engineering governance.