The Challenge
What “Shadow AI” Looked Like in Practice
The pattern didn't start with bad actors. It started with motivated teams solving real problems faster than the formal process could keep up.
In one case, an employee built a useful internal tool: it used a hosted large-language-model service to draft responses. The catch surfaced only when the employee asked IT to "host it properly." By then the tool had already been built and tested on a personal cloud subscription created with a free trial, under an individual account, outside any company tenant or governance. The intent was good—the developer explicitly preferred a properly governed environment—but the working system already existed on unmanaged personal infrastructure, with whatever data it had touched along the way.
In a parallel case, a team stood up a popular open-source workflow-automation platform to wire together internal systems and AI services. IT discovered it after the fact—it had been configured without their involvement, and the managing IT team initially had no access to the platform at all.
A third pattern was the attempted rollout of an autonomous AI agent framework (an "OpenClaw"-style tool) capable of executing code and acting on the user's behalf with persistent credentials. It was being deployed with no clear sign that leadership was even aware.
None of these were sanctioned, documented, or reviewed before they went live. They were discovered, not requested.
Risks That Emerged
Across these cases the same categories of exposure showed up regardless of the specific tool:
- Credential and secret exposure — hardcoded passwords in automation scripts, plus API keys and OAuth tokens living in ungoverned environments where they could leak through misconfiguration.
- Unclear and uncontrolled data paths — AI tools and agents sending business data to model services with no record of what was sent, where it was stored, or whether it was retained or used for training.
- Personal-infrastructure risk — production-adjacent tooling running on individual free-trial cloud accounts, outside the company tenant, with no continuity, backup, or offboarding control.
- High-privilege agents outside governance — autonomous agents operating with broad permissions and persistent credentials, creating exposure to prompt injection, malicious third-party "skills," and remote-code-execution vulnerabilities, and a path for lateral movement into connected systems.
- No audit trail or ownership — no logging, no inventory of what AI was in use, and no clear owner accountable for any of it.
- Discovery-after-deployment — in every case, security learned about the tool only once it was already running.
The common thread: the risk wasn't theoretical model behavior. It was ordinary infrastructure and identity hygiene breaking down because the work happened outside the normal guardrails.
Why This Keeps Happening (Root Cause)
- Business and marketing teams are measured on outcomes, not infrastructure, so they optimize for speed.
- Modern AI tools are marketed as "safe by default" and are trivially easy to stand up on a personal account or a free trial.
- There was no shared intake path for "I want to use AI for X," so the path of least resistance was to just build it.
- Security and IT were brought in late—or discovered the work themselves—rather than being a designed-in step.
The Solution
The Course Correction (What Should Have Existed)
The fix was not to ban the tools. In each case the underlying idea was legitimate and worth supporting. What was missing was a lightweight model that met the teams where they already were.
What the organization put in place:
- An AI intake and escalation path — a single, low-friction way for a business team to say "I want to use AI for this," routing the request from the requesting team through IT and security before anything goes live.
- Company-governed infrastructure as the default — projects hosted in the company tenant on managed subscriptions, not personal accounts or free trials, with proper resource ownership, tagging, and budget controls.
- An approved-vs-restricted tool posture — clear guidance on which AI tools and agent frameworks are sanctioned, which require isolated proof-of-concept review, and which are off-limits for business data.
- Secure credential handling — managed secrets and identity-based access in place of passwords pasted into scripts.
- Logging, documentation, and a named owner — every AI workflow inventoried, auditable, and accountable to someone.
- A "guardrails, not gatekeeping" delivery model — rather than blocking the marketing-built automation, IT provisioned a source-control organization, a staging-to-production deployment pipeline, and managed cloud resources so the team could keep iterating on a safe foundation.
“Before AI adoption becomes a security incident, organizations need governance that meets teams where they are.”
The turning point was a single working session that aligned IT, security, and the business on AI-agent ownership, licensing, platform choice, and a secure access model—converting an ad-hoc scramble into a repeatable process.
The Results
- Innovation continued — the useful tools survived, on infrastructure that could be trusted.
- Personal-account and plaintext-credential exposure was eliminated.
- IT and security regained visibility, ownership, and an audit trail over AI usage.
- Most importantly, trust improved between marketing, IT, and security, because the model rewarded teams for coming forward instead of punishing them
