Shadow AI Is the New Shadow IT — And Your API Gateway Is How You Find It

Shadow IT — employees using unapproved software, SaaS tools, and cloud services outside the visibility of IT and security — has been a persistent governance problem for a decade. IT teams built detection and control mechanisms: network egress filtering, CASB tools, SSO enforcement, and software inventory audits.

Shadow AI is the same problem arriving faster and with a higher blast radius. An employee who installs an unapproved SaaS tool creates a data governance risk. An employee who connects an AI agent to production APIs using a service account credential they self-provisioned creates an access control, data leakage, and audit failure simultaneously — with no visibility into what the agent is doing or what data it has accessed.

The defining characteristic of shadow AI is not that AI is being used. It is that AI is calling real APIs, using real credentials, with no approved integration record, no audit trail in any security team's scope, and no rate limits protecting the upstream systems.

Why shadow AI is harder to detect than shadow IT

Shadow IT primarily involved humans using unapproved software. The detection pattern was relatively clear: an unrecognised SaaS domain appearing in proxy logs, a credit card charge on an expense report for a software subscription, or a login event from an unfamiliar application in your IdP audit log.

Shadow AI involves AI agents calling APIs — often the same internal APIs that approved services call, using credentials that look like legitimate service accounts. The detection signals are subtler:

The credential may be legitimate but the usage pattern is not. An employee gets their own service account credential for testing (a common developer workflow) and then connects an AI agent to it permanently. The credential is a real credential in your identity system. The AI agent is not an approved deployment.

The call pattern may look like a busy developer. An AI coding assistant that a developer has connected to your internal APIs might make 100 API calls in a session. Without agent-aware traffic analysis, this looks like an active developer working quickly.

The MCP server may be external and unreviewed. The AI agent might be connecting to an externally-hosted MCP server that aggregates your internal APIs with third-party data sources — a server that your security team has never reviewed, that may be logging your API calls.

There is no "login" event to detect. A new shadow IT SaaS tool typically produces a login event that appears in your IdP. An AI agent calling an API with an existing credential produces an API call that appears in your gateway logs — which may not be routed to your SIEM, and if it is, may not be parsed for agent-pattern detection.

What shadow AI looks like in API gateway traffic

The detection opportunity is in the traffic patterns. AI agent calls have distinct characteristics that differ from typical application traffic:

New client IDs with agent-pattern call sequences. An employee-provisioned AI integration typically uses a client credential that was never part of a formal provisioning process. It may appear as a new service account or a developer credential being used outside its expected context. The call pattern — bursts of multi-endpoint calls followed by idle periods — is distinct from both human-interactive traffic and typical batch job traffic.

Calls to endpoints the client was not designed for. A developer testing credential that was created to test one endpoint is now calling five different endpoints across three different services. The scope of calls has expanded beyond what the credential was created for.

Unusual call hours. AI agents that run autonomously often execute at hours when human developers are not working. A credential that historically showed activity during business hours suddenly generating calls at 2am is worth investigating.

High read-to-write ratio with occasional anomalous writes. Research agents are read-heavy. But a prompt injection that causes an unexpected write will produce a write call with no established pattern — a single write to an endpoint the client has never called before, in the middle of a read-heavy session.

Calls to external endpoints not in the approved catalog. An AI agent that has been given a tool that calls external APIs (for enrichment, AI processing, or data transmission) will generate outbound calls to domains that appear nowhere in your approved API catalog. If your gateway logs outbound proxied calls, these appear as calls to unrecognised external hosts.

MCP tool invocation patterns. If your APIs are served through MCP, agent traffic follows the list_tools → call_tool pattern. A client that starts every session by calling list_tools and then rapidly sequences multiple tool calls is behaving like an MCP client, not like a REST API consumer.

The inventory problem: what shadow AI looks like at rest

Detection through traffic analysis catches shadow AI in operation. But the harder problem is the static inventory: the AI integrations that exist in your environment right now that your security team does not know about.

Self-provisioned developer credentials connected to AI tools. Developers regularly provision their own credentials for testing and development. Many of these credentials are never deprovisioned when the developer moves on or when the testing purpose ends. A subset of these credentials are now connected to AI tools — Claude desktop apps, Cursor, or custom agent scripts — that continue using them as long as the credential is valid.

Service accounts created for "temporary" AI pilots. An AI pilot was approved for a 30-day evaluation. A service account was created. The pilot ended (or it did not — it just stopped being called a pilot). The service account and its credentials were never deprovisioned.

External MCP servers with access to internal tools. An MCP server hosted by an AI tool vendor may have been connected to internal APIs with a credential that an employee self-provisioned. The credential is in your identity system; the MCP server is hosted externally; your security team has no visibility into what the server does with the API access.

AI tools with OAuth consent to internal APIs. If your internal APIs support OAuth, developers may have granted third-party AI tools OAuth consent to access those APIs on their behalf. The consent grants appear in your IdP if you look for them; they are rarely audited.

How your API gateway becomes the detection surface

The API gateway has always been the right place to enforce API access controls. It is also the right place to detect unapproved API access — including AI-driven access — because every call to your APIs passes through it.

The detection capabilities that matter:

Client identity on every call. Every API call should carry a client identity in the gateway's audit log — not just an IP address or a service name. When you review calls from an unrecognised client ID, you can identify it as a shadow integration and investigate.

Per-client call pattern baselines. Once you have client identities, you can baseline their normal call patterns. New clients with agent-pattern call sequences (short bursts across multiple endpoints, tool-list calls before other calls, unusual hours) are candidates for investigation.

Scope anomaly detection. A client calling endpoints outside its historically observed scope is an anomaly signal. A testing credential suddenly calling your production payment endpoint is a high-priority investigation trigger.

External egress visibility. Calls proxied through the gateway to external destinations should be logged. An internal credential being used to transmit data to an external domain that is not in your approved API catalog is a detection signal for shadow AI with exfiltration capability.

Access review integration. The gateway's client inventory — every active credential with its last-seen timestamp and the endpoints it has called — should feed your access review process. Credentials that have never appeared in an access review, credentials owned by former employees, and credentials used by unrecognised callers are the starting inventory for your shadow AI audit.

The remediation process

Once detected, shadow AI integrations need a triage process. Not all of them are risks — some are legitimate integrations that were deployed informally but provide real value. The goal is not to turn everything off but to bring it into the governance model.

Triage: Can this integration be traced to a specific employee and a specific business use case? Is it calling APIs it is authorised to call? Does it have rate limits? Is the model it is using approved?

Remediate: If the integration is legitimate, formally provision it through the standard process — dedicated credential, scoped to what it needs, rate limits appropriate to the agent type, included in access reviews.

Decommission: If the integration cannot be traced to an owner, if it is calling APIs it was not provisioned for, or if it is using an external model or MCP server that has not been reviewed, revoke the credential and document the finding.

Prevent recurrence: Require formal approval for AI integrations before credential provisioning. Review access review data for agent-pattern callers quarterly. Monitor for new client IDs with agent call signatures.

The shadow IT problem was not solved by saying "no AI tools." It was solved by building a governance process that made approved tools easy to get and unapproved tools visible to security. Shadow AI requires the same response.

Zerq's per-client audit trail, access profile enforcement, and client inventory give security teams the visibility needed to find and triage shadow AI integrations. See how Zerq handles AI agent access or request a demo to discuss your shadow AI detection requirements.