Shadow IT conversations tend to default to marketing tools and sales automation, the kind of thing a non-technical team signs up for with a work email and a credit card. That framing misses a meaningful chunk of the actual risk. Engineers create shadow IT too, and the version engineering teams produce often carries more direct access to production systems than anything marketing ever touches.
This isn't a story about developers being careless. It's a story about how the exact instincts that make good engineers effective, moving fast, trying tools before committing, working around a slow internal process, produce a specific and underappreciated category of risk.
The Shape of Engineering-Originated Shadow IT
It rarely looks like a rogue application running in production. It looks like a personal API key generated for a debugging session that never got revoked. It looks like a staging environment spun up on a free-tier cloud account to test something quickly, still running eight months later with a stale copy of production-adjacent data. It looks like a browser extension that reads clipboard content, installed to speed up a repetitive task, now sitting in a browser that also has access to internal admin panels.
None of these are dramatic on their own. Collectively, across a team of a dozen engineers over a couple of years, they add up to a meaningful, mostly invisible attack surface that nobody signed off on and nobody is actively monitoring.
Personal API Keys Are the Most Common Pattern
Almost every engineer has, at some point, generated a personal API key for a third-party service to unblock themselves quickly, intending to formalize it later. Later rarely comes. The key stays tied to a personal account, outside any centralized credential rotation policy, often with broader scopes than the actual task required because requesting a narrower scope took an extra five minutes nobody had at the time.
The fix isn't telling engineers to stop doing this, since the underlying instinct, unblock yourself now, is exactly what makes a good engineer productive. The fix is making the sanctioned path just as fast. A self-serve credential request flow with automatic expiration and scoped permissions removes the reason to reach for a personal key in the first place. GitHub and similar platforms have pushed hard on short-lived, scoped tokens over long-lived personal access tokens for exactly this reason, and the pattern is worth copying internally even for services that don't enforce it themselves.
Forgotten Staging Environments Are a Slow-Motion Liability
A staging or demo environment spun up on a personal cloud account for a quick proof of concept tends to outlive its original purpose by months or years. It was fast to create and nobody owns decommissioning it, so it just sits there, often running an outdated version of whatever software it was testing, sometimes still connected to a data source nobody remembers granting access to.
These environments are attractive targets precisely because they're unmonitored. A production system gets patched, logged, and reviewed. A forgotten staging box on someone's personal account gets none of that, while potentially holding real credentials, real API connections, or a snapshot of real data pulled in for testing convenience and never scrubbed.
Browser Extensions Deserve More Scrutiny Than They Get
Developer-focused browser extensions, JSON formatters, API testing helpers, productivity tools, request broad permissions almost by default, and engineers install them freely because they genuinely help. The risk isn't that any specific popular extension is malicious. It's that browser extension permissions are usually all-or-nothing, and a tool installed for one narrow purpose often ends up with read access to every page the browser visits, internal admin dashboards included.
A reasonable middle ground is maintaining an approved extension list for anything touching a browser that also has access to production tooling, reviewed periodically rather than locked down entirely. OWASP maintains general guidance on browser extension security considerations that's useful background for building that review process, even though the guidance predates the current wave of AI-assisted coding extensions specifically.
Why This Gets Missed in Standard Shadow IT Audits
A typical shadow IT discovery process leans on expense reports and SSO logs, both of which are tuned to catch paid, business-function tools. Free-tier developer tools, personal cloud accounts, and browser extensions mostly fall outside both of those data sources. No corporate card gets charged, and a lot of developer tooling never touches the company's SSO provider at all.
Catching this category requires a different discovery method: a direct, specific conversation with the engineering team about personal API keys, forgotten test environments, and browser extension usage, framed the same way any good shadow IT amnesty period should be framed, no penalty, just visibility. Engineers are usually candid about this once they understand the goal is inventory, not blame.
What a Reasonable Policy Actually Looks Like
The instinct to lock everything down is understandable and almost always counterproductive. A policy that blocks all free-tier signups and personal API keys outright just pushes the same behavior further out of sight, exactly the dynamic that makes shadow IT worse instead of better. A workable policy looks more like this: fast, self-serve paths for the common cases (a scoped API key, a short-lived test environment with automatic teardown), paired with a periodic, blame-free check-in on what's actually running.
Automatic expiration does more work here than any policy document. A test environment that tears itself down after fourteen days of inactivity can't become a two-year-old forgotten liability, no matter how busy the team gets. Cloudflare and most major cloud providers support this kind of lifecycle policy natively; the barrier to using it is almost always that nobody set the default, not that the capability doesn't exist.
Connecting This Back to the Broader Shadow IT Problem
The marketing-tool version of shadow IT and the engineering-tool version of shadow IT are usually treated as separate problems by separate teams, which is part of why the engineering side gets less attention. They're the same underlying problem: a slow or invisible approved path pushes people toward a faster unofficial one, and the unofficial one accumulates risk nobody is tracking.
The engineers at 137Foundry have seen this pattern often enough in client codebases to treat it as a standard part of any technical audit, not a special case. A broader look at discovery methods, risk categorization, and governance that applies across both the business and engineering sides of this problem is available in 137Foundry's guide on identifying and reining in shadow IT.
A Simple Checklist for the Next Team Retro
If a full audit feels like too much to take on right now, a short list of questions raised at the next team retro will surface most of the same risk far more cheaply. Ask whether anyone is using a personal API key for a service the team relies on regularly. Ask whether there's a test or staging environment nobody has touched in the last month. Ask which browser extensions the team relies on for daily development work, and whether anyone has actually looked at what permissions those extensions request.
None of these questions require a security specialist to ask, and none of them take more than a few minutes to answer honestly in a retro setting where the tone is already collaborative rather than evaluative. The value isn't in getting a perfect inventory from one conversation. It's in normalizing the topic enough that engineers mention these things as they come up, rather than only when someone finally runs a formal audit two years later and finds a surprising amount of forgotten infrastructure still technically live.
Why This Matters More As Teams Adopt AI Coding Tools
The rise of AI coding assistants has added a new wrinkle to this problem. Many of these tools request broad codebase access, sometimes including the ability to read environment variables or connect to external APIs on the developer's behalf, and adoption often happens organically, one engineer trying a tool before the rest of the team even knows it exists. That's the exact shadow IT pattern described throughout this piece, just with a newer category of tool.
The same principles apply: fast, sanctioned evaluation paths beat outright bans, scoped and short-lived credentials beat broad standing access, and periodic blame-free check-ins catch what expense reports and SSO logs miss. Treating AI coding tool adoption as a special, unprecedented case tends to produce worse outcomes than just applying the shadow IT playbook that already exists for everything else engineers bring in on their own initiative.
The Bottom Line for Engineering Leads
If your last shadow IT conversation focused entirely on marketing and sales tooling, there's a real chance a meaningful category of risk, personal API keys, forgotten test environments, unreviewed browser extensions, never came up at all. It's worth a direct, low-stakes conversation with the engineering team specifically, separate from whatever process handles the rest of the company, because the discovery methods that work for one side mostly miss the other.
Top comments (0)