How to Discover Shadow AI Agents Before They Discover You

Six months ago, most CISOs we spoke with had a rough count of the AI agents in their environment: "a handful." Six months later, that same organisation runs sixty. Developers spin up copilots, product teams wire GPT calls into internal workflows, ops engineers stand up MCP servers to expose systems to Claude. Every one of those is an NHI, and almost none of them are inventoried.

The analogy to shadow IT is imperfect but instructive. Shadow IT was a procurement and compliance problem. Shadow AI agents are a security and access-control problem. An unregistered SaaS subscription cannot exfiltrate your production database schema. An unregistered MCP server that a developer wired to your internal GitHub and Confluence almost certainly can — and it authenticates with credentials that your IdP never scoped for autonomous use.

This post is a practical discovery playbook. Not a fear brief — a working methodology for inventorying what you have, understanding which agents represent real risk, and building the operational muscle to keep discovery current as the count grows.

Where shadow agents hide

What makes the vendor-supplied agent category particularly uncomfortable is that you may have explicitly approved the SaaS product without knowing the agent was included in the latest release. The vendor ships a "Copilot" feature in a minor version bump. It inherits the OAuth scopes the original integration was granted — which may include read access to everything the product can see. Security was never asked to approve this expansion.

Similarly, the "automation scripts" category is larger than it appears. One engineering organisation we spoke with found 340 distinct Python scripts in internal repositories that imported the OpenAI SDK. Each was a service account in waiting — and because they ran as CI/CD jobs, each inherited the broad IAM permissions the CI runner carried.

Why traditional NHI discovery misses agents

Standard NHI discovery is built around stable, long-lived identities: a service account created via Terraform, a deploy key generated on a known date, an API key provisioned through a secrets manager. Agents are different. They are ephemeral, they spawn dynamically, they may run for minutes or months, and the path from "developer runs a command" to "production identity with real access" can be thirty seconds.

• No provisioning event. A static service account is created through an API call you can log. An agent MCP server is started with a command that may not produce any IdP-visible event at all.
• Personal credentials, not service credentials. The first version of most agents uses the developer's personal API key, not a provisioned service identity. Personal keys do not appear in service account inventories.
• Dynamic tool access. Unlike a workload that always calls the same three APIs, an agent's resource footprint changes on every run based on what the LLM decides to do next. Posture scoring based on a static permissions snapshot is meaningless.
• Multi-hop delegation. An agent orchestrator may spawn sub-agents, each with their own identity context. The sub-agent's access is often inherited from the parent's token, creating a delegation chain that no existing NHI tool models.

A five-step discovery playbook

1. Trawl your identity providers. Every OAuth grant issued to a client with "gpt", "claude", "anthropic", "openai", "copilot", or "agent" in its name is an agent-shaped NHI. This surfaces about 30% of them.
2. Fingerprint outbound traffic. Requests to `api.openai.com`, `api.anthropic.com`, and `generativelanguage.googleapis.com` from your production networks are agent origins. Correlate the source workload identity.
3. Search the codebase. `Anthropic()`, `OpenAI()`, `.mcp.json`, `mcpServers` in `settings.json`. Every match maps to a workload identity you can now inventory.
4. Query MCP registries. Enumerate `.well-known/mcp` on internal hosts. Publish an internal registry so teams can register agents formally.
5. Reconcile with humans. Every agent needs a human owner. If none is found, the agent is orphaned and should be quarantined.

The five steps are not sequential — run them in parallel in week one. Each surfaces a different population. IdP scanning finds formally registered agents. Egress fingerprinting finds unregistered agents that are already making calls. Code search finds agents that exist in repositories but have not yet been deployed. MCP registry enumeration finds running servers that were never formally registered. Human reconciliation stitches the results together.

What to do with each discovered agent

Once you have an inventory, the remediation path is straightforward in principle and requires discipline in practice.

The technical anatomy of a compliant agent registration

# agent-registration.yaml — submitted to TigerIdentity identity-svc
agent:
  id: agent-finance-reconciler-v2
  display_name: Finance Reconciliation Copilot
  owner: [email protected]
  team: finance-engineering

  identity:
    type: workload
    attestation: k8s-oidc
    namespace: finance-prod
    service_account: svc-finance-reconciler

  tools_allowed:
    - mcp_server: internal-spreadsheets
      actions: [read, comment]
    - mcp_server: internal-erp
      actions: [read, query]
    - mcp_server: internal-jira
      actions: [read, create_issue]
    # Explicitly deny: delete, export, write to production tables

  policy:
    max_session_ttl: 2h
    require_tidr_enrolment: true
    allow_sub_agents: false
    data_classification_ceiling: confidential   # not secret

  review_cadence: 30d

The registration manifest does several things at once: it provisions a service identity tied to a verifiable workload attestation; it declares the tool access the agent is permitted, which the MCP gateway enforces per-call; it sets a session TTL and TIDR enrolment requirement; and it draws an explicit ceiling on data classification. This is the difference between "the agent can do whatever the LLM decides" and "the agent can do exactly what the manifest permits."

Keeping discovery current

The hardest part of agent discovery is not the initial scan — it is staying current. Agent deployment cadences are faster than any other NHI type. A developer can go from idea to deployed MCP server in an afternoon. If your discovery runs weekly, you have a six-day window of blindness on every new agent.

• Hook CI/CD pipelines. Any pipeline that deploys to production and imports an AI SDK or creates an MCP configuration should emit a discovery event.
• Monitor DNS egress in near-real-time. Queries to AI provider domains from production environments trigger immediate investigation, not a batch report.
• Scan on every git push. The code scanner runs on every commit to main, not on a cron job.
• Maintain a self-registration deadline. If an agent's first production call is detected before registration, the owner receives an automatic Slack message with a five-day registration deadline.

What TigerIdentity does at each step

• Automatic OAuth grant reconciliation against MCP-shaped client patterns.
• Egress fingerprinting from the connector-service, correlated with the identity graph.
• Code-scanner discovery worker that ingests repo events and flags new agent-shaped identities.
• MCP gateway that proxies tool calls, enforces per-action policy, and produces a full audit trail.
• Ownership attribution worker that maps every agent to a human and pages the owner when policy shifts.
• TIDR enrolment that baselins every agent's tool-call patterns and alerts on behavioural anomalies in seconds — not the next morning.

The six capabilities above form a closed loop: discovery feeds the identity graph, the graph feeds policy, policy is enforced at the MCP gateway, the gateway feeds TIDR, and TIDR signals feed back into policy decisions. No component is useful in isolation; the value compounds when they share the same data model.