October is Cybersecurity Awareness Month (CAM). GuidePoint Security is proud to join the national effort, championed by the US National Cybersecurity Alliance (NCA) in collaboration with the Cybersecurity & Infrastructure Security Agency (CISA), to amplify essential cybersecurity practices under the 2025 themes: Stay Safe Online and Building a Cyber Strong America.

Author: Jonathan Sander, Field CTO, Astrix Security

The AI wave hit fast. One moment, your organization was testing a chatbot in a corner of the business. Next, AI was everywhere. Every team, every process, every leadership meeting. The pressure to adopt AI isn’t just high; it’s relentless.

In the rush to deploy AI-powered everything, a new class of risk has slipped in through the back door: Shadow AI Agents.

These aren’t the simple bots of yesterday. They’re autonomous, API-wielding systems acting on your behalf, granting themselves access, triggering workflows, and touching sensitive data. Most of them were never approved. Many of them aren’t even on your radar. And because they operate with identities you can’t see, they create a blind spot that traditional security tools simply weren’t built to cover.

This post is about shining a light on those agents: where they come from, why they’re dangerous, and what you can do about them today.

When Did Your Chatbot Become an Agent?

It happens faster than most teams realize.

Give an AI system a set of tools, a few API keys, or the ability to trigger workflows, and it stops being “just a chatbot.” It becomes an AI agent, a system capable of taking real-world actions without direct oversight.

But that transformation doesn’t always happen in the open. Even sanctioned AI platforms (like an enterprise ChatGPT license) can spawn shadow agents the moment someone connects them to sensitive systems outside approved channels.

It’s happening everywhere. A single employee can now spawn dozens or even hundreds of non-human identities (NHIs) – service accounts, tokens, and agents – and IT has no record. What was once a trickle of automation has become a flood of identities. All with access. All invisible.

Shadow Agents Are a Security Nightmare

The AI rush didn’t come with a playbook for identity security, and attackers know it. Shadow agents are a security nightmare because:

1. Agents are Unpredictable and Overprivileged
   AI agents are designed to operate flexibly, which often translates to permanent credentials with broad, cross-system access. In practice, that means a single leaked token can open the door to your entire infrastructure.
2. The NHI-to-human Ratio is Exploding
   In most organizations, every human has a few accounts. In an AI-driven enterprise, one human might generate dozens of NHIs and no one’s keeping track. Ownership is unclear, permissions stack up, and privilege sprawl accelerates.
3. Attackers are Already Living Off the Land
   Threat actors have perfected the art of hiding in plain sight. Now, by compromising NHIs tied to AI agents, they can blend into legitimate automation traffic (sadly, the same way they’ve been exploiting cloud automation for years). It’s just that with the huge uptick in AI stuff, there’s so much more to hide in.

What you get is a perfect storm: a massive spike in identities, unpredictable access paths, and a security model that was never designed for this world.

Fingerprinting Shadow Agents with Tools You Already Have

The good news: you don’t need to start from scratch. You can start detecting and fingerprinting these shadow agents today using tools like Splunk, Microsoft Sentinel, and other major SIEMs and log-management platforms. It’s a manual process. You’ll need to piece together logs, tune detections, and update patterns yourself.  Let’s see what you can do to find some of these beasts.

1. IP Range Mapping
   Many AI providers publish their egress IP ranges. By mapping traffic back to these ranges, you can quickly spot activity originating from AI agents. To make this easier, we’ve compiled a reference table of current IP resources (as of today) — you’ll find it at the end of this post.
2. User-Agent Strings
   AI-driven traffic often carries unique User-Agent patterns. Monitoring for these strings in your logs can uncover previously invisible automation.
3. OAuth App Identification
   OAuth activity is a goldmine for agent discovery. By auditing which apps are granted access, when, and by whom, you can start pulling shadow agents out of the dark.

These techniques won’t solve the entire problem, but they’re a powerful first step. Visibility is the start of everything, and if you’re willing to put in the work you can get it today.

A Framework Secure AI Adoption

Organizations need to embrace AI safely, not fear it. A simple but effective approach to achieving this could look like:

1. Discover: Real-time inventory of every agent, identity, scope, and data touchpoint, with risk scoring for prioritization.
   
2. Secure: Minimize blast radius by removing long-lived credentials, tightening permissions, and detecting abnormal behavior.
   
3. Deploy: Enable teams to confidently roll out AI agents with short-lived, scoped credentials and security baked in from day one.

This framework turns AI from a risky experiment into a business accelerator. The faster you gain visibility and control, the faster your teams can innovate safely.

From Shadow to Strategy

Shadow AI agents aren’t a temporary blip—they’re the new normal. The organizations that thrive in this AI-driven era won’t be the ones who try to ban or slow adoption. They’ll be the ones who embrace it with security guardrails built in.

Here’s how to get started today:

• Treat all AI agents as shadow until proven governed.
  
• Use IP ranges, OAuth apps, and User-Agent patterns to fingerprint AI-driven activity.
  
• Kill long-lived tokens and enforce least-privilege policies.
  
• Make security part of your orchestration layer, not an afterthought.

By doing this, you stop AI from being a risk vector and start turning it into a competitive advantage.  Learn more my contact Astrix Security. This also is where a trusted partner like GuidePoint Security comes in. Learn more about GuidePoint’s AI services here.

Provider	Surface(s) this applies to	Do they publish fixed egress IPs?	Where / notes
OpenAI	ChatGPT Actions (server → your API)	Yes (CIDR JSON)	Doc explicitly says ChatGPT calls Actions from IPs in chatgpt-actions.json. Use that list for allowlisting. (OpenAI Platform)
	Crawlers / bots (training & user fetches)	Yes (CIDR/IPv6 JSON)	Official JSON endpoints: GPTBot openai.com/gptbot.json, ChatGPT-User openai.com/chatgpt-user.json, SearchBot openai.com/searchbot.json. Use these if you want to recognize/allow/block those bots. (OpenAI Platform, OpenAI)
Anthropic	Claude MCP/tool calls & Console	Yes (fixed IPs; includes one CIDR for ingress + list for egress)	Anthropic publishes inbound CIDR (160.79.104.0/23, 2607:6bc0::/48) and stable outbound IPs used for requests (e.g., MCP tool calls). (Anthropic)
Perplexity	PerplexityBot / Perplexity-User (on-demand fetch & crawling)	Yes (JSON)	Official JSON endpoints: perplexity.ai/perplexitybot.json and perplexity.ai/perplexity-user.json. Docs describe both and when each hits your site.
Microsoft	Copilot Studio / Power Platform managed connectors calling out	Yes (via service tag)	Microsoft maintains the AzureConnectors service tag with regioned IP prefixes for connector egress; allowlist by service tag or exported ranges. (This is about connectors powering Copilot/agents—not Bing/Copilot web browsing.) (Microsoft Learn)
Google	Vertex AI Agents / Agent Engine / Extensions	No single Google egress list	Google steers you to route egress through your VPC/NAT/Secure Web Proxy, so the traffic presents your IPs. No fixed Google-owned list for agent egress. (Google Cloud)
AWS (Agents for Amazon Bedrock)	Agents calling external APIs	No provider IP list	AWS docs describe agents calling APIs but provide no static egress IPs. Standard AWS patterns apply (your VPC/NAT/Lambda egress), so detection is via your IPs, not Bedrock-owned ranges. (AWS Documentation)
Mistral	Le Chat on-demand fetch (MistralAI-User UA)	No official CIDR list	The UA is documented by third parties, but there’s no provider-published egress range to allowlist. Treat as unknown/variable. (DataDome)
Cohere	Connectors / web fetch	No official CIDR list	Connector features exist, but Cohere does not publish fixed egress IP ranges for you to allowlist. (Use auth/webhook signing instead.) (Cohere Documentation)
xAI (Grok)	API & “Live search”	No published list	No official egress/CIDR publication found. Assume variable cloud IPs or rely on auth. (xAI Docs)
Hugging Face	Inference Endpoints / Serverless	No provider CIDR	Endpoints run in managed infra or your VPC; egress typically goes through your NAT/PrivateLink/proxy—no HF-wide egress list. (Hugging Face)