---
title: "Shadow IT Stored Data. Shadow Agents Take Actions."
slug: "agent-governance-new-shadow-it-day-one-controls"
author: "ibl.ai Engineering"
date: "2026-09-11 09:00:00"
category: "Premium"
topics: "shadow IT, shadow AI, AI agent governance, non-human identity, agent registry, enterprise AI security, audit trails, AI access controls"
summary: "IBM's 2026 breach report puts shadow AI in 43% of security incidents, more than double the year before, while close to seven in ten breached organizations had no governance policy covering unapproved AI use."
banner: ""
thumbnail: ""
linkedin: |
  The shadow IT analogy for AI agents is mostly right, and the part it gets wrong is the part that matters.

  Shadow IT was unsanctioned software that held company data. A Dropbox account nobody approved was a copy of files in a place with no retention policy and no audit trail. Bad, recoverable, and visible the moment someone looked at the expense report.

  An unsanctioned agent is a different object. It holds data and it takes actions — sends the email, updates the record, approves the invoice, calls the API. And it usually does so with credentials it inherited from the employee who built it, which means the audit log shows the employee, not the agent.

  That is the discovery problem. You cannot find it in procurement, because nobody bought anything.

  The numbers are no longer speculative. IBM's 2026 Cost of a Data Breach Report, based on 602 breached organizations:

  → Shadow AI figured in 43% of security incidents, more than double the prior year
  → Close to seven in ten breached organizations had no governance policy for spotting unapproved AI use
  → 92% of organizations with an AI-related breach were missing role-based access and MFA on those AI systems

  The day-one control set is not exotic: a registry so every agent is named, a scoped non-human identity per agent instead of a shared human's token, allowlisted egress, a human approval gate on irreversible actions, retained audit trails, and a kill switch.

  With ibl.ai you own all the code and the data — self-hosted inside your own perimeter, model-agnostic across any LLM, usage-based with no per-seat pricing, deployable anywhere from your own cloud to a fully air-gapped network.

  #iblai #AgenticAI #EnterpriseAI #ShadowAI #AgentGovernance #InfoSec
---

## The Short Answer

**Shadow IT was unsanctioned software holding data. An unsanctioned AI agent also takes actions, with credentials inherited from whoever built it. IBM's 2026 breach report found shadow AI in 43% of security incidents, more than double the prior year, and close to seven in ten breached organizations had no policy governing unapproved AI use. With ibl.ai you own all the code and the data, so the identity, egress and audit controls run inside your perimeter.**

The analogy is useful. The place it breaks is where the control set has to change.

## How is an unsanctioned AI agent different from shadow IT?

By one property: it acts.

Shadow IT was unsanctioned software that held data. An unapproved Dropbox account was a copy of company files sitting somewhere with no retention policy, no access review and no audit trail. Serious, but static, and generally discoverable through an expense report.

An agent holds data and then does things with it. It sends the message, writes to the CRM, approves the invoice, calls the external API.

The second difference is where its permissions come from. An employee who builds an agent usually gives it the credentials they already have — an OAuth token, a session cookie, an API key issued to them.

**The agent therefore acts as the employee.** In the systems it touches, there is no record of an agent at all: the audit log shows a person doing an unusual volume of ordinary work.

## How common is shadow AI, and what does it cost when it fails?

Common enough that it is now a leading factor in breaches, and the growth rate is the more alarming half.

[IBM's 2026 Cost of a Data Breach Report](https://www.ibm.com/reports/data-breach), built on **602 organizations breached between March 2025 and February 2026** across 17 industries and 16 countries, puts the global average breach cost at **$4.99 million**, a 12% rise and a record.

Inside that dataset, [workers using unapproved AI tools figured in **43% of security incidents**](https://www.helpnetsecurity.com/2026/07/30/ibm-cost-of-a-data-breach-2026/) — more than double the prior year's share.

The governance gap is wider than the incident rate.

[Close to seven in ten breached organizations had no governance policies for managing AI or spotting unapproved use](https://www.cybersecuritydive.com/news/data-breach-costs-ai-governance-ibm/826463/), and **92%** of those reporting an AI-related breach were missing role-based access, multifactor authentication and comparable controls on the AI systems involved.

Volume is rising underneath those numbers. Microsoft's [2026 Work Trend Index](https://www.microsoft.com/en-us/worklab/work-trend-index/agents-human-agency-and-the-opportunity-for-every-organization), published 5 May 2026 from a survey of 20,000 workers across 10 countries, reports **15x year-over-year growth in active agents in Microsoft 365**, and 18x among large enterprises.

Those are the sanctioned ones, in one vendor's telemetry.

## Why doesn't the agent framework itself provide these controls?

Because a framework is a runtime, and the frameworks in use are also churning faster than a governance program can follow.

Three names come up in most enterprise conversations, and the current state of each is worth stating accurately.

**[LangGraph](https://github.com/langchain-ai/langgraph)** is LangChain's low-level orchestration framework for long-running stateful agents, actively developed, at roughly 41,500 GitHub stars.

**[CrewAI](https://github.com/crewAIInc/crewAI)** is a standalone Python framework for multi-agent crews and flows, independent of LangChain, at roughly 58,400 stars.

**[AutoGen](https://github.com/microsoft/autogen)** is the one usually described incorrectly. Its README now opens with "Maintenance Mode — AutoGen is now in maintenance mode. It will not receive new features or enhancements and is community managed going forward," and directs new users to Microsoft Agent Framework as "the enterprise-ready successor to AutoGen."

[Microsoft announced that transition on 2 October 2025](https://github.com/microsoft/autogen/discussions/7066), merging AutoGen and Semantic Kernel into the new framework. Naming AutoGen today as a current Microsoft recommendation is about a year out of date.

ByteDance's [DeerFlow](https://github.com/bytedance/deer-flow) is frequently reported as new for the same reason. Version 1 shipped in May 2025; the 2.0 SuperAgent harness launched in late February 2026 and the v2.0.0 tag landed 25 June 2026. The repository now shows more than 82,000 stars.

Its README also warns that, for the `allowed-tools` entries in an installed `.skill` archive, DeerFlow "does not inspect tool arguments" — the runtime boundary examined in [DeerFlow 2.0 is free, your governance layer is not](/blog/deerflow-open-source-agents-governance-layer).

The enterprise point is different from the per-framework one: you cannot write policy against a runtime that may be in maintenance mode in twelve months. The controls have to sit under all of them.

## Which controls can an enterprise mandate on day one?

Six, and each is enforceable centrally without approving or banning any particular framework.

- **An agent registry.** Every agent is declared before it runs: owner, purpose, systems it may reach, review date. Unregistered agents are denied at the identity layer rather than discovered later.
- **A scoped non-human identity per agent.** Each agent authenticates as its own principal with its own permissions. Never a shared human's token, which is the default today and the reason agents are invisible in audit logs.
- **Allowlisted egress.** The network decides which destinations an agent may reach, enforced at the perimeter so the control does not depend on the agent's own configuration.
- **Human approval gates on irreversible actions.** Payments, deletions, external communications, production writes and record changes require a person to confirm, enforced server-side rather than requested in a system prompt.
- **Retained audit trails.** Every tool call, argument, retrieved document and model response written to storage the agent cannot modify, retained for the period your regulator specifies.
- **A kill switch.** One action that revokes an agent's credentials and halts execution across every system, exercised on a schedule so it is known to work.

None of these requires agreement about which framework is best. They are the reason that question can stay open.

## Why does the agent registry have to come first?

Because the other five controls all take an agent as their argument.

You cannot issue a scoped identity to an agent you have not named, allowlist egress for a workload you have not enumerated, gate the irreversible actions of a process you do not know exists, or kill what you cannot find.

The registry is also the only control that addresses discovery. Shadow IT was found through spend and through network logs showing traffic to a SaaS domain.

A shadow agent generates neither: it runs on a laptop or a team's own cloud account and authenticates as a known employee to systems that employee is allowed to use.

So the registry has to be paired with an incentive, which is the lesson procurement learned the first time. **Registration has to be faster than not registering.**

If getting an agent approved takes six weeks and building one takes an afternoon, the registry will document a minority of what is running and provide false assurance about the rest.

This is the same conclusion reached by giving [AI agents corporate identities rather than borrowed ones](/blog/ai-agent-corporate-identity-enterprise-security): naming the actor is the precondition for every control that follows.

## How does ibl.ai give an enterprise day-one control over its agents?

By running the control plane inside your own perimeter and handing you its source.

With ibl.ai you own all the code and the data.

The platform deploys on your infrastructure with full source code access, so identity scoping, egress policy, approval gates and audit retention are components you can read and change rather than assurances from a vendor.

It is model-agnostic across any LLM, usage-based with no per-seat pricing, and deploys anywhere — your own cloud, on-premise, GovCloud, or a fully air-gapped network with no outbound connectivity.

Agents authenticate as distinct principals bound to your existing identity provider, act under role-scoped permissions enforced server-side, and write a complete audit trail of every tool call to storage they cannot alter.

Open-source frameworks then become an interchangeable capability layer on top of governance you own and can still run when this year's framework enters maintenance mode. 1.6M+ users across 400+ organizations run the platform this way, including NVIDIA, MIT, and Syracuse University.

ibl.ai is family-owned and operated from New York, NY.

*Related reading: [DeerFlow 2.0 is free, your governance layer is not](/blog/deerflow-open-source-agents-governance-layer) — the same controls at the level of a single agent runtime; and [AI agents need corporate identities](/blog/ai-agent-corporate-identity-enterprise-security) — why a borrowed token is the root of the audit problem.*

*Sources: the 43% shadow-AI incident share and study scope from [Help Net Security's summary of IBM's 2026 Cost of a Data Breach Report](https://www.helpnetsecurity.com/2026/07/30/ibm-cost-of-a-data-breach-2026/) and [Cybersecurity Dive](https://www.cybersecuritydive.com/news/data-breach-costs-ai-governance-ibm/826463/); the $4.99M average cost from [IBM's report page](https://www.ibm.com/reports/data-breach); agent growth from [Microsoft's 2026 Work Trend Index](https://www.microsoft.com/en-us/worklab/work-trend-index/agents-human-agency-and-the-opportunity-for-every-organization); framework status from the [LangGraph](https://github.com/langchain-ai/langgraph), [CrewAI](https://github.com/crewAIInc/crewAI), [AutoGen](https://github.com/microsoft/autogen) and [DeerFlow](https://github.com/bytedance/deer-flow) repositories, and the maintenance-mode announcement in [AutoGen discussion #7066](https://github.com/microsoft/autogen/discussions/7066).*

## Why does owning the AI stack matter?

**ibl.ai is the agentic AI platform where you own all the code and the data. You self-host the entire stack inside your own perimeter, run it model-agnostic across any LLM and switch anytime, and pay by usage with no per-seat pricing — so you can deploy anywhere: your cloud, on-premise, GovCloud, or fully air-gapped.**

- **You own all the code and the data.** Full source code under a perpetual license, running on your infrastructure. Not API access to someone else's platform — the stack itself is yours.
- **Model-agnostic.** Run any LLM — Claude, GPT, Gemini, Llama, Command, or your own fine-tune — and switch providers without rewriting the platform.
- **No per-seat pricing.** Usage-based billing against a budget cap you set. Cost tracks what your organization actually uses, not how many people you employ.
- **Deploy anywhere.** Your cloud, your VPC, on-premise, GovCloud, or a fully air-gapped network with no outbound connectivity.

1.6M+ users across 400+ organizations run the platform this way, including NVIDIA, MIT, and Syracuse University.

ibl.ai is family-owned and operated from New York, NY — a U.S.-headquartered, domestically-owned long-term partner, not a vendor that sells licenses and moves on.
