Rhodian Group

Something ships here on Thursday. Before it does, here is the scorecard it should be held to. Along with every other agent discovery tool on your list this year. Five questions. Worth asking verbatim. ━━━━━━━━━━━━━━ 01 / WHAT IS YOUR PRIMARY DISCOVERY MECHANISM? API, identity, runtime, network, or endpoint. If the answer is a list, ask which one actually does the work. 02 / WHAT DO YOU ACTUALLY ENUMERATE? Agents? Identities? Tools? Data flows? Those are four different inventories, and only one of them is an agent inventory. 03 / WHAT ENVIRONMENTS DO YOU COVER? SaaS, cloud, local, browser, code. Make them name each one rather than accepting comprehensive. 04 / WHAT GOVERNANCE CONTEXT COMES WITH EACH AGENT? Detection without context is just an alert. Who owns it, what can it reach, was it ever approved, does it still need to exist? 05 / WHAT DO YOU MISS? Every vendor has blind spots. The trustworthy ones name theirs without being cornered into it. ━━━━━━━━━━━━━━ That last one is not a gotcha. It is the only question of the five that cannot be answered from a datasheet. If a vendor 𝗰𝗮𝗻𝗻𝗼𝘁 𝗮𝗻𝘀𝘄𝗲𝗿 𝟬𝟱, the first four stop mattering. Thursday.

Here is the part of shadow agent discovery that most tools quietly skip. ━━━━━━━━━━━━━━ ◆ THE HALF THAT WORKS Connect to a platform's API and it returns a clean inventory. Agent name, creator, creation date, status, components. It works well. It is also the easy half. ━━━━━━━━━━━━━━ ◆ THE HALF NOBODY MENTIONS A meaningful share of agent-building platforms expose no public API for agent inventory. No endpoint to query. No integration to build. If the discovery strategy is connect to the platform's API, those platforms are not partially covered. They are absent. And that is exactly where the shadow agents are. Agents built on formal, API-exposed platforms tend to be the sanctioned ones. A platform team stood them up deliberately and somebody signed off. The agent a business user spun up in an afternoon, in a no-code builder, with no security review? Different platform. Often no API, no registration, no record. ━━━━━━━━━━━━━━ API discovery finds the agents somebody 𝗮𝗹𝗿𝗲𝗮𝗱𝘆 𝗮𝗽𝗽𝗿𝗼𝘃𝗲𝗱. Which is why browser-level visibility matters more than it sounds like it should. Catching the moment an employee creates or lists an agent inside a builder reaches a category of risk that API-based discovery structurally cannot. It is not the elegant answer. It is the one that finds the agents nobody registered.

Someone resigned four months ago. Their agent didn't. ━━━━━━━━━━━━━━ ◆ WHAT OFFBOARDING CAUGHT ▪ SSO account, revoked ▪ Email, disabled ▪ Laptop, returned ▪ Badge, collected ▪ VPN certificate, revoked Textbook. Nothing missed. ━━━━━━━━━━━━━━ ◆ WHAT IT DIDN'T The agent they built is still running. Still authenticated. Still pulling records on a schedule. Still writing to a system that matters. The OAuth grant they approved on their way out never expired, because nobody offboards a thing they don't know exists. Offboarding checklists were built for humans and SaaS seats. Close the account, reclaim the licenses, done. But an agent built inside a SaaS platform often doesn't live under the departed employee's login. It holds its own credentials, granted once and persistent by default. So the account is closed and 𝘁𝗵𝗲 𝗮𝗴𝗲𝗻𝘁 𝗶𝘀 𝗳𝗶𝗻𝗲. ━━━━━━━━━━━━━━ Here is the uncomfortable version of the question. How many of the agents running in your environment right now have an owner who still works there? If the honest answer is that there is no way to tell, that is not a failure of your offboarding process. It is a discovery gap. Nobody can revoke access that was never inventoried.

Shadow SaaS and shadow agents are not the same problem. Treating them as one is how security teams end up under-resourcing this. ━━━━━━━━━━━━━━ ◆ WHAT A SHADOW APP DOES It sits there. Someone logs in, puts data somewhere it shouldn't be, and the damage is roughly proportional to what they uploaded. One box. One boundary. ━━━━━━━━━━━━━━ ◆ WHAT A SHADOW AGENT DOES It makes API calls. It writes to systems. It pulls data on a schedule with nobody watching. Some of them spawn other agents to finish subtasks. Three of those risks have no clean SaaS equivalent: 01 / NON-HUMAN IDENTITY SPRAWL Every agent needs credentials. API keys, OAuth tokens, service accounts. Notoriously hard to track, and a well-worn path to privilege escalation. 02 / PROMPT INJECTION Any agent that reads outside content can be hijacked by instructions buried inside it. That exposure cannot be assessed for agents nobody has found. 03 / DELEGATION CHAINS Agent A hands credentials to Agent B. Blast radius stops being a single permission scope. ━━━━━━━━━━━━━━ Same discovery discipline as shadow SaaS. 𝗠𝘂𝗰𝗵 𝗵𝗶𝗴𝗵𝗲𝗿 𝘀𝘁𝗮𝗸𝗲𝘀. Which of those three worries your team most? The answer usually says something about what you have already found.

"Do you have AI agents in your environment?" It's a bad question, because nobody agrees on what counts. ▪ Half your vendors are calling a scheduled script an agent. ▪ Half your employees don't think what they built counts as one. Agent-washing has made the category almost useless as a governance term. ━━━━━━━━━━━━━━ ◆ THE WORKING DEFINITION An AI agent uses a model to decide its next action toward a goal, then takes that action through tools or APIs, adjusting as results come back. The load-bearing word is 𝘁𝗮𝗸𝗲𝘀. A chatbot recommends. An agent 𝗮𝗰𝘁𝘀. ━━━━━━━━━━━━━━ ◆ WHY THE LINE MATTERS An unknown SaaS app is one question. What data did someone put in it? An unknown agent is three questions at once: 01 / DATA. What can it reach? 02 / IDENTITY. Whose credentials is it holding? 03 / ACTION. What can it change while nobody is watching? ━━━━━━━━━━━━━━ Nobody can inventory a category the organization has not defined. So the first governance decision is not which tool to buy. It is what your team agrees to count. What definition is yours using?

Your marketing coordinator built an AI agent last Thursday. It has access to your CRM. It can send email on her behalf. It runs on a schedule, whether or not she's at her desk. She didn't file a ticket. She didn't need to. The builder asked her three questions and shipped it. 𝗦𝗲𝗰𝘂𝗿𝗶𝘁𝘆 𝗱𝗼𝗲𝘀𝗻'𝘁 𝗸𝗻𝗼𝘄 𝗶𝘁 𝗲𝘅𝗶𝘀𝘁𝘀. ━━━━━━━━━━ This isn't a hypothetical, and it isn't a rogue-employee story. It's the natural result of putting agent builders inside the tools everyone already uses: ▪ Microsoft 365 ▪ Salesforce ▪ ServiceNow ▪ N8N ▪ Workato 𝗘𝘃𝗲𝗿𝘆 𝗲𝗺𝗽𝗹𝗼𝘆𝗲𝗲 𝗶𝘀 𝗻𝗼𝘄 𝗮 𝗱𝗲𝘃𝗲𝗹𝗼𝗽𝗲𝗿. Most security teams are still inventorying SaaS logins. ━━━━━━━━━━ So here is the question worth sitting with. If someone asked you today how many AI agents are running in your environment, could you give them a number? 𝗡𝗼𝘁 𝗮 𝗴𝘂𝗲𝘀𝘀. 𝗔 𝗻𝘂𝗺𝗯𝗲𝗿. Drop the honest answer in the comments. That baseline is worth knowing.