Shadow IT and Shadow AI: The Experiment Account Your Security Tooling Never Sees

Most security programs have an unwritten rule about experimentation: leave it alone. The product team wants a sandbox account to try ideas. The account is isolated from production, it costs little, and everyone in it has administrator access because restrictions slow people down. Nobody wires it into the security tooling because there is nothing sensitive in it yet, and the money is better spent elsewhere.

That reasoning is correct more often than security folklore admits. Heavy controls on an experimental environment can cost more than they save, and an organization that insists on full governance for every throwaway account will find that people stop using accounts and start using personal ones.

But the reasoning has a shelf life. It holds while the account is small, the team is small, and the work is low risk. It quietly stops holding when AI-assisted coding arrives, when LLM API keys start living in environment files, when interns join, when someone requests a GPU instance, or when a prototype begins to use a copy of real data. None of these events trigger an alert. The account simply crosses a line without anyone noticing, because nobody is watching.

This post is about that line. It covers what shadow IT and shadow AI mean in a cloud account context, why the experimental account is a rational choice, the specific ways it turns into an incident, a decision framework for when it is safe to leave an account unmanaged, a baseline of five lightweight controls that preserve speed, and sample guardrails you can adopt today. The goal is not to talk you out of sandboxes. It is to help you keep them without being surprised by them.

Definitions, kept practical

Shadow IT is technology used for work without the knowledge or approval of the people responsible for security and governance. In cloud terms, it is an account, a service, a SaaS subscription, or a tool that is not in your inventory and not covered by your controls.

Shadow AI is the same pattern applied to AI. Examples: an engineer pasting source code or customer data into a public chatbot; a team calling a hosted model API with a personal credit card; an AI coding assistant running in a developer terminal with cloud credentials in scope; a prototype that sends internal documents to a third-party model. Our explainers on shadow AI and shadow AI detection cover the definitions in more depth.

A shadow account deserves its own mention. It is a cloud account that exists, is paid for, and is used, but is not connected to your security tooling, your identity governance, or your monitoring. Sometimes it is a deliberate decision. More often it is a decision nobody remembers making.

Why the experiment account is a reasonable idea

It is worth being fair to the pattern before critiquing it.

• Isolation limits blame. A separate account is a hard boundary. If someone deletes a database or runs up a bill, the damage stays in that account.
• Speed matters. Prototypes die in approval queues. Admin access removes the queue.
• Cost of control is real. Every security tool charges by account, asset, or user. Applying the full stack to a throwaway environment can cost more than the environment.
• Maturity should earn spend. A sensible position is: invest in controls once a workflow proves itself and the revenue justifies it.

All of that is defensible. The failure is not in the sandbox. It is in treating “unmanaged” as a permanent state instead of a decision with an expiry.

What changed: five forces that break the assumption

1. AI coding tools act on whatever credentials they inherit. An agent in a developer’s terminal or IDE uses the environment it finds. If the shell has administrator keys, so does the agent. It can create, modify, and delete anything, at machine speed, and it can be steered by text it reads, including text hidden in a file or a web page. We cover the mechanics in AI coding agents leaking credentials.

2. LLM API keys are a new kind of secret. They are long-lived, easy to paste into a repository, and directly convertible to spend. A leaked key does not just expose data; it lets someone run inference on your bill.

3. GPUs turn small mistakes into large invoices. A general-purpose instance left running costs dollars a day. A multi-GPU instance costs hundreds. An admin with the ability to launch any instance type in any region can create a five-figure bill in a weekend, by accident or by intent.

4. Interns and short-tenure contributors multiply identities. People who join for a few months, work fast, and then leave. Their credentials, access keys, and tokens are rarely rotated or revoked on schedule, and nobody runs an access review on a sandbox.

5. Data drifts in. A prototype begins with synthetic data. Someone needs realistic data to test a model, so they copy a table. A “temporary” export lands in a bucket. Now the sandbox holds customer data and has no logging, no review, and no masking.

Seven ways a harmless sandbox becomes an incident

#	Pattern	How it unfolds	Why nobody notices
1	Long-lived admin keys on laptops	An engineer creates access keys for convenience. They sit in shell profiles and old projects.	No inventory of keys, no rotation
2	LLM or cloud keys in a repository	A key is committed to a public or shared repo. Scrapers find it within minutes.	The repo is not scanned; the account has no billing alert
3	Unbounded compute	A job, loop, or compromised key launches large instances across regions.	No budget, no anomaly alert, no instance-type restriction
4	Public storage or endpoints	A demo bucket or API is exposed “just for a day” and forgotten.	No posture monitoring
5	Production data copied in	A realistic dataset is exported for testing.	No data boundary rule, no logging
6	A pivot into production	The sandbox shares an identity provider, a VPC peering, a trust relationship, or a shared secret with production.	The link was created for convenience and never reviewed
7	Compliance scope creep	The sandbox now touches in-scope data, so an auditor can pull it into scope.	Nobody mapped data flows to accounts

Items 3 and 6 deserve emphasis. Spend is the most common real-world consequence, because it is the one attackers monetize fastest. Pivoting is the most damaging, because it is how an “isolated” account stops being isolated.

A decision framework: is it safe to leave this account unmanaged?

Ask these six questions. Be honest and write the answers down.

1. Does the account contain, or can it reach, real customer, employee, or financial data? If yes, it is not a sandbox.
2. Does any identity in it have a trust path to production? Check IAM roles that trust other accounts, shared identity provider groups, VPC peering, transit gateways, and shared secrets.
3. Can anyone launch expensive resources? Look at instance types, regions, and managed AI services.
4. Are there long-lived credentials? IAM users, access keys, API tokens, personal access tokens.
5. Do AI tools or agents operate with credentials from this account? Include coding assistants and automation.
6. Would you know within a day if something went wrong? If the answer is “only from the bill,” you have no detection.

Scoring is simple. Zero “yes” answers to questions 1, 2, 4, and 5, and a “yes” to question 6 with budget alerts in place: the account can stay lightly managed. A “yes” to question 1 or 2: bring it under governance now. Anything else: apply the five-control baseline below, which costs little and closes most of the exposure.

The five-control baseline for a lean sandbox

These controls are chosen because they are cheap, require no new agents on developer machines, and do not slow down legitimate work.

1. Visibility: see the account without changing how people use it

You cannot decide what to do about an account you cannot see. At minimum:

• Enable CloudTrail for the account and deliver logs to a bucket outside the sandbox’s own administrators’ reach.
• Connect the account to read-only posture and identity visibility. Agentless tools that connect with a read-only role give you the list of identities, keys, public resources, and risky permissions without touching workflows.
• Enable GuardDuty if your budget allows; it is priced by usage, and a quiet sandbox is cheap.

2. Spend guardrails: put a ceiling on the worst case

• Create an AWS Budget with alerts at 50, 80, and 100 percent of expected monthly spend, sent to a channel a person reads.
• Turn on Cost Anomaly Detection for the account.
• Use budget actions to apply a restrictive policy automatically when a threshold is crossed.
• Treat Service Quotas for GPU instance families as a brake. Do not raise them until there is a named workload that needs them.

3. Permission guardrails: restrict the dangerous few, not the many

Rather than removing admin from everyone, use service control policies to deny a short list of high-risk actions. You are not telling people what they can do; you are fencing off the things that cause incidents. Sample policies follow in the next section.

4. No long-lived keys: swap standing credentials for short-lived access

• Prohibit new IAM users and access keys in the sandbox. Use federated sign-in with temporary sessions.
• Make elevated access time-boxed: engineers request administrator rights for an hour, an approver confirms, and access expires on its own. This keeps the speed of “admin when needed” and removes the permanent admin.
• For automation and AI tools, give workloads scoped credentials that live for seconds or minutes, not days.

5. A data boundary rule: nothing real goes in without a decision

Write one sentence and publish it: “No customer or employee data enters this account without a documented exception.” Pair it with a periodic scan for public buckets and obvious sensitive data patterns. A rule with an owner beats a hundred silent assumptions.

Sample guardrails you can adopt

These are starting points. Test them in a non-critical account first and adapt the exemptions to your environment.

Deny GPU and accelerator instances unless a named role requests them.

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "DenyExpensiveInstanceFamilies",
    "Effect": "Deny",
    "Action": ["ec2:RunInstances"],
    "Resource": "arn:aws:ec2:*:*:instance/*",
    "Condition": {
      "StringLike": { "ec2:InstanceType": ["p*", "g*", "trn*", "inf*", "*.metal"] },
      "ArnNotLike": { "aws:PrincipalArn": "arn:aws:iam::*:role/gpu-approved" }
    }
  }]
}

This denies launching GPU, accelerator, and bare-metal instance types for everyone except a dedicated role. That role becomes the place where a human decision happens, and where logging and approval attach.

Prevent the account from leaving your organization.

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "DenyLeavingOrganization",
    "Effect": "Deny",
    "Action": "organizations:LeaveOrganization",
    "Resource": "*"
  }]
}

Restrict to the regions you actually use. Attackers and accidents both favor regions you never look at. A region allow-list with the standard exemptions for global services removes that blind spot. Use AWS’s documented pattern with aws:RequestedRegion and a NotAction list for global services, and test it before applying.

Block creation of long-lived credentials.

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "DenyNewIamUsersAndKeys",
    "Effect": "Deny",
    "Action": ["iam:CreateUser", "iam:CreateAccessKey", "iam:CreateLoginProfile"],
    "Resource": "*"
  }]
}

Service control policies require the account to live in an AWS Organization you control. If your accounts sit in someone else’s organization, see the shared responsibility model has a fourth party.

Shadow AI: a short policy that people will follow

Long AI policies are ignored. A one-page version is more effective if it answers five questions plainly:

1. Which AI tools are approved? Name them. A list is more useful than a principle.
2. What data may go into them? Define three tiers (public, internal, restricted) and say which tiers each tool may receive.
3. Where do API keys live? In a secrets manager, never in code, never in chat. Scan repositories for the key formats your providers use.
4. What can an AI tool do on its own? Distinguish suggest-only tools from tools that execute commands, and require approval for the latter on anything beyond the sandbox.
5. Who do I ask? Name a person or a channel with a response-time promise. Shadow usage grows where official answers are slow.

On the technical side, discovery comes from three places: billing (new marketplace or AI service line items), network and API logs (calls to model endpoints), and identity (new keys and tokens). The aim is to notice quickly, not to forbid.

Where Cloudanix fits

Cloudanix is designed so that governing a lean environment does not require heavy tooling on every machine.

• See the account in minutes. Connect it with a read-only role and use CSPM and CIEM to list identities, long-lived keys, public resources, and risky permissions. You decide what to do with the findings. No agent, no workflow change.
• Replace standing admin with time-boxed admin. Cloud JIT lets engineers request administrator rights for a limited window through the access flow they already use, with approval and automatic expiry, so interns and engineers keep their speed while permanent admin goes away.
• Give AI tools short-lived credentials. Coding Agent JIT and Agentic JIT issue task-scoped credentials to AI coding assistants and automation, destroy them afterwards, and keep a human in the loop for sensitive grants, so the agent never inherits a permanent key.
• Make the decision visible. If you choose to leave an account out of scope, that is a legitimate decision. Document it, set a review date, and let the posture view tell you when the facts change.

Cloudanix does not set cloud spend limits. Pair it with AWS Budgets and anomaly detection for cost guardrails, and use it for the identity, access, and exposure side.

A 30-day plan

Week 1: inventory. List every cloud account, who owns it, what it costs, and whether it is connected to any security tooling. Include accounts that finance pays for and security has never heard of.

Week 2: classify. Apply the six questions. Mark each account as lightly managed, baseline, or fully governed. Write the reason next to each.

Week 3: install the baseline on every “baseline” account: logging, budgets, anomaly detection, the GPU and region guardrails, and a ban on new long-lived credentials.

Week 4: fix the human layer. Publish the one-page AI policy, set up time-boxed admin, and schedule a 90-day review where each lightly managed account has to justify staying that way.

Closing thought

Experimentation is how companies find their next product, and a security program that smothers it is a program that gets bypassed. The way to protect experimentation is to make the failure modes boring: capped spend, no standing keys, a data boundary, and visibility. None of that requires a compliance project. It requires deciding, in writing, which accounts you are choosing not to manage, and attaching a date to that choice.

If you want to see what a sandbox account looks like from the outside, we can run it through a read-only review and show you the identities, keys, and exposures in under an hour.

Related Resources

• The Hidden Cost of Cloud Security Tooling: Surprise Bills and Sparse Alerts
• AI Coding Agents Are Leaking Credentials — What Security Teams Need to Know
• Why AI Coding Agents Become an Identity and Credential Risk
• Cloud Security for Lean Teams: What a CISO With No Dev Team Should Do First
• What Is Shadow AI?
• Shadow AI Detection: Finding Ungoverned AI Tools Across Your Organization
• Coding-Agent and Intern Guardrails for an AI Product Team in an Admin-by-Default Sandbox Account
• Cloudanix Cloud JIT
• Cloudanix Coding Agent JIT