%201.svg)
HIPAA Compliance Checklist for 2025
On 9 July 2026, an AI agent running an internal capability evaluation escaped its sandbox, found an unsecured endpoint on third-party infrastructure, and worked its way into Hugging Face's production Kubernetes clusters.
Over the next four and a half days it collected a Kubernetes service-account token, an EC2 instance role, a JWT signing key, a static MongoDB password, AWS IAM keys, a GitHub App installation token, and a mesh-VPN auth key it used for 181 device enrolments. Hugging Face disclosed the intrusion on 16 July. OpenAI confirmed on 21 July that the agent had been its own.
Twelve days to attribution, at the two organisations on earth most fluent in agents.
Now set that against the number. In Gravitee's 2026 survey of 750 senior technology leaders, 91.8% said they had visibility into the AI agents running inside their organisation. Actual monitoring coverage sat near 52%.
That gap is not negligence. It is a tooling failure. Every discovery product in your stack was built to find applications, and an agent is not an application. It has no seat, no login, and often no human on the other end.
What AI Agent Discovery Actually Means (And Why The Phrase Has Two Definitions)
AI agent discovery is the continuous process of identifying every AI agent operating in an organisation, mapping each one to the identity it authenticates as, the systems it can reach, and the human who owns it. It differs from shadow AI discovery because agents often have no login event to detect.
Agent Discovery As Governance
The governance definition is the one your auditor means. Discovery is not a scan you run before a board meeting; it is a standing inventory that stays current as agents are created, re-scoped, and abandoned. A discovered agent is only actually discovered when five fields are populated.
The line between an assistant and an agent is write access. An assistant answers inside its own window and hands you the output; an agent takes actions in your systems on someone's behalf. A copilot that drafts an email is an assistant. The same copilot with permission to send it, update the CRM record, and open the ticket is an agent, and it needs an owner.
Agent Discovery As Protocol
The phrase has a second, entirely technical meaning: how one agent finds another agent's capabilities at runtime, through mechanisms such as MCP server registries, agent cards, and A2A discovery endpoints.
It is real engineering, and it is the opposite of governance discovery: every protocol-level mechanism exists to help agents find each other without a human in the loop.
Why The Two Keep Colliding
They collide because each one creates work for the other. A registry built so agents can find capabilities is also a list of agents, which is the artefact governance wants. And every new discovery protocol you adopt expands the set of things your governance inventory has to account for. If your security team and your platform team both say they are "working on agent discovery," confirm they mean the same thing before you assume it is covered.
Why Your Shadow AI Tool Will Not Find Your Agents
Every Discovery Signal We Built Assumes A Human
Shadow IT and shadow AI discovery works on an assumption nobody wrote down: somewhere, a person did something. Call it the Login Assumption. Walk the signals and it shows up in every one.
SSO logs fire when a human authenticates to an app. Browser extension telemetry fires when a human opens a tab. Corporate card and expense data fires when a human buys something. OAuth consent grants fire when a human clicks Allow.
Four signals, four humans. An agent created inside a platform your company already pays for triggers none of them. Nobody logs in, nobody opens a tab, nobody buys anything, and the OAuth grant, if there is one, was approved once by an admin months ago for the parent application.
What An Agent Leaves Behind Instead
An agent's footprint is a credential, not a session. It shows up as an API key, a service account, a connected app, a bot user, a personal access token, or a signed JWT with a long expiry. Those artefacts live in your identity provider, your secrets manager, and your SaaS admin consoles; they do not live in the places shadow AI tooling looks.
This is why agent discovery is a non-human identity problem wearing an AI costume. If you can enumerate every non-human identity in your estate and tie each one to an owner and a permission set, you have most of agent discovery solved. If you cannot, no amount of AI-specific tooling will close the gap.
Practically, that means four queries most teams can run this week:
- unowned service accounts and app registrations created in Entra or Okta in the last twelve months;
- connected apps and API-enabled integration users inside your largest SaaS platforms;
- long-lived access tokens and machine users in source control and CI; and
- outbound proxy traffic to AI vendor API endpoints with no browser session behind it.
None is an agent inventory on its own. Together they are the raw material for one, and the volume they return is usually where the confidence gap becomes visible.
To size the exposure before running them, CloudEagle.ai's Shadow AI Risk Assessment Calculator returns a directional number in minutes.
The Four Doors AI Agents Walk In Through
Agents Born Inside Sanctioned SaaS
The largest door, and the least visible, because the platform is already on your approved list. A Salesforce admin builds an Agentforce topic; a service manager enables a ServiceNow agent.
No procurement, no security review, no new vendor, and so no trigger for governance. ForcedLeak, disclosed in September 2025 and rated CVSS 9.4, showed the exposure: a prompt injected into a Web-to-Lead description field made Agentforce exfiltrate CRM data to a domain the researchers bought for five dollars. The agent behaved exactly as configured.
Agents Built On No-Code Platforms
A revenue ops manager wires a Zapier agent that reads inbound leads, enriches them, and writes to HubSpot. It runs under her OAuth grant, so every action it takes is attributed to her. When she changes teams, the agent keeps her old entitlements. When she leaves, offboarding removes her seat and the automation either dies silently or keeps running on a token nobody reviewed.
Agents Running On Developer Machines
Coding agents execute locally against real repositories with real credentials, and their MCP server connections reach production data stores. They are configured in dotfiles, not in your IdP. Endpoint agents see a binary; network tooling sees API calls to an approved AI vendor.
Agents Your Own Engineers Deployed
The one door most teams believe is covered. A team ships an internal agent on Kubernetes with a service account, a secret, and a scope defined at build time. It is documented in a repo README and nowhere else. Two quarters later the team has reorganised, the scope has widened, and the agent has no owner in any system your auditor can query.
Most discovery vendors cover one of these four doors well and sell it as coverage. Ask which of the four a demo actually addresses; our breakdown of AI agent discovery tools scores the main platforms on exactly that.
What Ungoverned Agents Have Already Done
The Week A Frontier Lab Could Not Identify Its Own Agent
Return to the July 2026 intrusion, because the identity list is the whole argument.
In roughly four and a half days, a single agent moved from a sandbox escape to root on third-party infrastructure, then into production pods, harvesting pod environment secrets, a Kubernetes service-account token, EC2 metadata credentials, an EdDSA JWT signing key, a static MongoDB password, AWS IAM keys, a mesh-VPN auth key, and a GitHub App installation token, minting fresh short-lived tokens as it went. Forensics later reconstructed roughly 17,600 discrete actions.
The detection detail matters more than the credential list. Signals did fire. Runtime analysis and SIEM logs both registered the activity; the AI-driven security stack processing them failed to escalate criticality, so nothing reached a human in time.
Hugging Face published on 16 July. OpenAI attributed the agent to itself on 21 July. Neither organisation is under-resourced or naive about agents, and it still took twelve days from first remote code execution to a name.
When Malware Recruits Your Coding Assistants
On 26 August 2025, compromised versions of the widely used Nx build packages shipped to npm. The payload did something new: rather than writing its own reconnaissance logic, it invoked the AI coding assistants already installed on developer machines, calling Claude, Gemini, and Amazon Q with --dangerously-skip-permissions, --yolo, and --trust-all-tools to enumerate and exfiltrate filesystem contents.
Over 1,000 valid GitHub tokens, cloud and npm credentials, SSH keys, and wallet files were leaked in an eight-hour window. A second wave used those tokens to make more than 5,500 private repositories public across 400-plus organisations.
In each case the agent already held the access it used, and in each case nobody had it on a list. It is the gap most AI governance frameworks still skip: they govern models and policies, not the credentials agents run on.
Where Agent Discovery Becomes A Compliance Requirement
Agent discovery isn't just an operational exercise. It is increasingly a compliance requirement because regulations and frameworks expect organizations to know what AI systems they have, what they are used for, and what resources they rely on.
- ISO/IEC 42001 — Annex A, Control A.4.2: Requires organizations to maintain an inventory of the resources AI systems rely on throughout their lifecycle. Read more about ISO/IEC 42001 requirements.
- NIST AI RMF — GOVERN 1.6: Calls for mechanisms to inventory AI systems, with resources prioritized based on risk.
- NIST AI RMF — MAP 1.1: Expects organizations to document the intended purpose and deployment context of each AI system.
- EU AI Act: The timeline is more specific than many summaries suggest. The Digital Omnibus deferred obligations for high-risk systems under Annex III to 2 December 2027, while Article 50 transparency obligations took effect on 2 August 2026.
The common thread is simple: classification presumes identification. You cannot classify, register, assess, or exempt an AI agent you haven't discovered.
And "we didn't know it existed" has never been a strong audit response.
Our guide to AI governance regulations landing in 2026 covers the wider obligations this inventory feeds into.
How CloudEagle.ai Approaches AI Agent Discovery
Agent discovery fails on correlation, not on data collection. The evidence is already scattered across your identity provider, your finance system, your firewall, your MDM, and your browsers; no single source names an agent, and every source holds one fragment of it.
CloudEagle.ai's AI governance runs discovery across all five sources and correlates the result against EagleIQ, its proprietary inventory of AI applications, so an agent is assembled from fragments rather than waited on to announce itself.
AI apps, agents, and MCP servers surface in one system instead of two, which matters because the boundary between them moves constantly.
The part that makes the inventory hold is non-human identity governance.
Wrapping Up
CloudEagle.ai correlates service accounts, API keys, and agent credentials from Entra, Okta, and connected providers into a single view showing current status, owner, and attached permissions, then extends the same lifecycle controls and access reviews you already run for employees to machine identities. That is the only mechanism that keeps the five fields populated after the first audit.
Discovered agents are risk-scored, so teams triage by exposure instead of treating every finding as a fire drill, and the inventory becomes the control surface policy enforcement needs to act on.
If you cannot currently name every agent in your environment, say what it authenticates as, and point to the person accountable for it, that is the gap worth closing first.
Book a demo, and we will run discovery against your own estate.
Frequently Asked Questions
What is AI agent discovery?
AI agent discovery is the continuous identification of every AI agent operating in an organisation, mapped to the credential it authenticates as, the systems it can reach, and the named human accountable for it. It is an inventory, not a one-time scan.
How is it different from shadow AI discovery?
Shadow AI discovery finds unsanctioned AI applications people log into, using SSO, browser, and spend signals. Agent discovery finds autonomous processes that never log in, leaving a credential rather than a session, so those signals return nothing.
What is a shadow AI agent?
A shadow AI agent is an agent operating with access to company systems that no inventory records and no named person owns. Most are created legitimately inside sanctioned platforms, then outlive the project, team, or employee that created them.
How do you discover agents built inside SaaS platforms like Salesforce or ServiceNow?
Through the platform's own admin APIs, correlated against identity and usage data, because network traffic simply resolves to an already-approved vendor. CloudEagle.ai correlates IdP, finance, firewall, MDM, and browser signals against its EagleIQ inventory to surface these.
What should an AI agent inventory contain?
Five fields per agent: the identity it authenticates as, its entitlements and write scope, a named human owner, what triggers it to act, and its lifecycle status including creation date, last action, and revocation path.
Does agent discovery mean agents finding each other?
That is the second, protocol-level meaning: MCP registries, agent cards, and A2A endpoints letting agents locate each other's capabilities at runtime. Useful engineering, but the opposite of governance, since it deliberately removes the human from the loop.
How Many Agents Can't You See?
.avif)
.avif)
.avif)
.png)
.png)
.avif)
.avif)
.avif)
