Shadow AI Is Already Here, And Your Security Team Doesn't Know It

TBDCyber | Agentic AI Security Series

In our previous article, The Identity Paradox: Why Agentic AI Breaks IAM by Design, we discussed how agentic AI challenges the key IAM design principles for authentication, authorization, and auditing. In this article, we dive deeper into the Shadow AI challenge.

When most security leaders hear "Shadow AI," they picture a developer running a personal ChatGPT subscription to write code, or a sales team pasting customer data into a consumer LLM.

The Shadow AI problem is not primarily about data leakage through consumer AI tools. It is about autonomous agents (agents with persistent credentials, real access to enterprise systems, and no governance record) that your business users are building right now, at scale, inside tools your organization has already licensed and approved.

Your security team almost certainly does not know how many exist. There is a good chance no one does.

Two Problems, Not One

Shadow AI in the agentic era is two converging problems with different risk profiles and different governance implications.

The first problem is developer-deployed Shadow AI. This is the variant that security teams have been pointing at for several years. Developers and technical teams spin up agents directly via platform APIs (e.g., OpenAI, Anthropic, Azure AI, AWS Bedrock) outside of centralized procurement or security review. They provision long-lived API keys, embed them in codebases or configuration files, build a workflow that solves an immediate problem, and move on to the next project. The project ends. The developer moves teams. The credential does not expire. The identity has no owner, no lifecycle policy, and no decommissioning plan. Because it was never formally registered, it exists entirely outside the organization's identity governance perimeter.

The blast radius when something goes wrong is real, but the population size is limited by technical skill. Only developers build these. The security team can, at least in principle, get upstream of the problem through API gateway controls, secrets scanning, and developer governance policies.

The second problem is citizen developer Shadow AI. This is the variant that is growing faster, is harder to govern, and is already operating at significant scale in most large organizations. And it is the one most security programs are not yet equipped to see.

The Agent Your Finance Manager Built Last Tuesday

No-code and low-code platforms have put agent creation capabilities directly in the hands of non-technical staff. Microsoft Copilot Studio. Power Automate. Salesforce Flow. ServiceNow AI. Zapier. These are not niche tools. They are embedded in the productivity suites and enterprise platforms that most organizations have already licensed. The finance manager, the HR coordinator, and the marketing analyst can all currently build agents that connect to corporate systems, process sensitive data, and execute business workflows without writing a line of code or notifying the security team.

Consider what this looks like in practice. A senior finance manager builds a Power Automate workflow to extract data from the ERP, summarize it, and distribute it to the leadership team every Monday morning. It takes her an afternoon to build. It works reliably. It saves her several hours a week. The security team was not consulted. The IT team did not provision anything. There are no tickets, no access requests, and no NHI registration.

There is, however, a non-human identity now operating in your environment under her full credentials, including privileged access to financial records, that will continue doing so indefinitely, regardless of whether she changes roles, takes on different responsibilities, or eventually leaves the organization.

Multiply that by the size of your business user population. If even a fraction of your employees deploy a single workflow agent through an approved productivity platform, the resulting identity population could dwarf your existing NHI estate in months. Each agent will typically carry the creator's full access rights rather than a least-privilege service account. Each will have no defined lifecycle or expiry. Each will generate no governance record at point of creation. Each will be invisible to existing NHI discovery tools, which scan for service accounts and API keys, not for platform-native workflow identities that live entirely within the Microsoft 365 or Salesforce ecosystems.

The Identity Blur Problem

The credential and privilege issue is significant. The audit problem may be more consequential.

When a citizen developer's agent takes an action (e.g., sends an email, modifies a record, transfers data to an external service, initiates a downstream workflow), that action is logged under the human user's identity. There is no separate agent identifier in the audit trail. There is no mechanism to distinguish whether a human or an agent acted autonomously.

If that action causes a compliance violation or data exposure, investigators face an immediate attribution problem. Was this the human acting? The agent acting on the human's standing instructions? An agent behaving unexpectedly in a context its creator never anticipated? The log cannot answer that question. And in regulated industries, that inability to attribute action to a specific, accountable entity is not merely an audit inconvenience. It may constitute a material failure of the accountability controls required by SOC 2, PCI DSS, and sector-specific regulatory frameworks.

This is the Identity Paradox, which we examined in our previous article, operating at the business user level. The agent is only useful because it carries its creator's full permissions. It is only dangerous for the same reason. You cannot solve it by restricting permissions without eliminating the utility the business user was trying to capture. You cannot solve it by blocking no-code platforms without removing capabilities that are now core features of tools the organization has licensed and budgeted for.

Why Restriction Is Not the Answer

The tempting governance response is to restrict access to no-code platforms. Require security review before any workflow can be deployed. Block external integrations. Limit which connectors are available.

Some of this is appropriate. Most of it will not contain the problem.

The business pressure to adopt AI productivity tools is not a trend that security teams can reverse by tightening controls. It is a board-level, CFO-level, CEO-level priority. The platforms that enable citizen-developer agents are not optional add-ons to the enterprise stack. Microsoft 365 Copilot, Salesforce, ServiceNow, and their agent capabilities are core product features embedded in contracts that will be renewed regardless of what security recommends. An organization that attempted to remove citizen developer agent capabilities from its Microsoft 365 deployment would be removing Microsoft 365.

The governance question is therefore not whether citizen developer agents will exist in your environment. They already do. The action is to gain visibility into them and ensure the identities they create are subject to some form of lifecycle management before an incident makes the absence of that management consequential.

The PocketOS Warning

In April 2024, a staging AI agent with unintended access to a production credential autonomously deleted PocketOS's entire production database (including all backups) in approximately nine seconds.

The agent's behavior was not malicious. It was goal-directed. It encountered a production API key within its accessible environment and, acting to fulfill its perceived operational objective, used it. The safeguards that would have prevented a human developer from making the same mistake (separation of environments, credential scoping, access review) were not in place for the agent.

The PocketOS incident involved a developer-deployed agent in a controlled technical environment. The citizen developer equivalent, an agent operating under a business user's full enterprise credentials, connected to live production systems, triggered autonomously, is operating in most large organizations today. The difference is that when it causes an incident, the audit trail will not clearly identify the agent rather than a human.

Three Things Security Leaders Should Do Now

Solving the citizen developer Shadow AI problem requires accepting that the goal is governance, not containment. Here is where to start.

Build discovery that operates at the platform layer, not the directory layer. Citizen developer agents do not appear in your identity directory. They are not service accounts. They will not show up in your existing NHI discovery scans. Identifying them requires discovery mechanisms that operate within the platforms where they were created (e.g., Copilot Studio, Power Automate, Salesforce Flow, ServiceNow) and that surface which agents exist, who created them, which systems they connect to, and which credentials they operate under. You cannot govern what you cannot see.

Establish a credential scoping requirement, enforced at the platform level. Citizen developer agents should operate under purpose-scoped service credentials rather than inheriting their creator's full access rights. This needs to be enforced at the platform level because most business users will not voluntarily scope down an agent that works fine as built. The IAM team, in partnership with the teams managing the productivity platforms, needs to make least-privilege credentials the default provisioning path, not the exceptional one.

Add citizen developer agents to your offboarding process. When a staff member leaves or changes roles, your current offboarding process almost certainly fails to identify and address the agents they created during their tenure. It should. A workflow agent built by a former employee, running under credentials that were never formally registered as non-human, and accessing systems appropriate for that employee's role but not for the role's successor, is an open exposure. It will not appear on any access review or deprovisioning checklist that was not specifically designed to find it.

***

Shadow AI is not arriving. It arrived. The first generation of ungoverned citizen developer agents is already operating in your environment, under your users' credentials, connected to your production systems, generating audit records that cannot distinguish human action from autonomous agent action.

The security teams that get ahead of this problem will be the ones that stop treating it as a policy problem and start treating it as an identity governance problem. The inventory does not exist yet. The lifecycle process does not exist yet. Credential scoping enforcement does not yet exist. Building those three things is the appropriate response to Shadow AI in the agentic era.

This is the third article in TBDCyber's Agentic AI Security series. Our research covers the citizen-developer and Shadow AI risks in greater depth, alongside the broader identity governance crisis. Read the full whitepaper.

The next article examines third-party agent risk: AI agents arriving in your environment through SaaS renewals, operating under vendor-controlled logic, and with access to your most sensitive data, and the five governance questions most procurement processes never ask.

TBDCyber advises security leaders on identity governance, agentic AI security, and emerging threat architectures. To discuss what this means for your organization, contact us.