{"slug": "you-can-t-govern-the-ai-agents-you-can-t-find", "title": "You Can't Govern the AI Agents You Can't Find", "summary": "AI agents are entering enterprise environments through application teams rather than IT, authenticating via API keys, OAuth grants, and delegated tokens so they appear in logs as ordinary service accounts, according to a guide on agent discovery and governance. The guide argues agents differ from static service accounts because they compose actions across systems and change behavior with every prompt, and it identifies three discovery signal classes: credential patterns, behavioral signatures, and creation context. It concludes that discovery without ownership is incomplete, requiring every agent to be linked to a human owner and reviewed with the same rigor as human identities.", "body_md": "**TL;DR:** AI agents don't announce themselves. They authenticate through API keys, OAuth grants, and delegated tokens, and they look like service accounts in your logs right up until they behave nothing like one. This guide covers how to discover them, why agent identity is a different problem from NHI inventory, and how to assign ownership that holds up.\n\n- **The core problem:** agents are created by application teams, not IT, so they never pass through the front door your inventory watches.\n- **Agent vs. service account:** a service account is static and predictable; an agent composes actions across systems and changes behavior with every prompt.\n- **Discovery signals:** credential patterns, behavioral signatures, and creation context.\n- **The second question:** discovery without ownership is just a longer spreadsheet. Every downstream control depends on linking an agent to a human.\n- **What good looks like:** agents discovered, inventoried, owned, and reviewed with the same rigor as human identities, at agent speed.\n\nSomewhere in your environment right now, an engineer has wired an AI agent into Salesforce, or Snowflake, or your ticketing system. It authenticates with a credential someone minted six weeks ago. It reads data, takes actions, and shows up in your logs looking like just another service account.\n\nThat's the problem. On enterprise architecture calls, the same question keeps surfacing, asked almost word for word: how do you discover these agents in the first place? How do you even determine that something *is* an agent?\n\nIt's the right question, because the old playbook doesn't apply. Service account discovery is a solved problem. You know where they live, you know the naming conventions, you can enumerate them from your IdP and your cloud accounts. AI agents are scattered everywhere. They authenticate through API keys, OAuth grants, and delegated tokens, the same plumbing covered in [SAML vs OAuth](https://www.c1.ai/blog/saml-vs-oauth). And they multiply faster than any review cycle.\n\n## How is an AI agent different from a service account?[#](#how-is-an-ai-agent-different-from-a-service-account)\n\nThe instinct is to treat agents as a new flavor of [non-human identity](https://www.c1.ai/solutions/identity-security) and fold them into your existing NHI inventory. Resist it, at least as a complete answer.\n\nA service account is static. It does one thing, its permissions rarely change, and its behavior is predictable enough that anomaly detection works. An agent is dynamic by design. It composes actions across systems, its behavior varies with every prompt, and its effective access is the union of everything it can touch. A service account with read access to a database is a known quantity. An agent holding the same credential, plus a connection to your email and your CRM, is a fundamentally different risk object.\n\nOne security leader on a recent call named the gap precisely: everyone focuses on managing the agents themselves, and almost nobody is thinking about who monitors and governs the permissions underneath them.\n\n## What signals reveal the agents already in your environment?[#](#what-signals-reveal-the-agents-already-in-your-environment)\n\nDiscovery has to account for how agents actually enter an environment: sideways, through teams shipping fast. Three signal classes do most of the work.\n\n**Credential patterns.** OAuth apps with broad scopes, long-lived API keys attached to automation platforms, and tokens issued to LLM orchestration frameworks. If your organization has adopted [MCP](https://www.c1.ai/blog/what-is-mcp-authorization), the authorization grants agents use to reach tools are themselves a discovery surface.\n\n**Behavioral signatures.** Identities that touch multiple unrelated systems in short windows, or whose access patterns shift without a corresponding change ticket. A \"service account\" that suddenly starts reading from four new systems is telling you something.\n\n**Creation context.** Who minted the credential, from where, and attached to what project. Agents built in low-code platforms and internal AI tools leave a paper trail if you know where to look. This is the same visibility problem as [shadow AI discovery](https://www.c1.ai/solutions/shadow-ai-discovery): the tools your teams adopted before anyone asked permission.\n\n## Who owns an AI agent, and what happens when they leave?[#](#who-owns-an-ai-agent-and-what-happens-when-they-leave)\n\nDiscovery without ownership is just a longer spreadsheet. On those same architecture calls, the second question follows immediately: once we find an agent, how do we link a human identity to it?\n\nThis matters because every downstream control depends on it. Access reviews need a reviewer. Offboarding needs a trigger. An incident response needs someone to call. An agent with no owner is an agent nobody can revoke.\n\nThe ownership model has to survive turnover, which means it can't just be \"whoever created it.\" One security team described deliberately refusing to assign NHIs to individuals for exactly this reason: if the owner of twenty service accounts resigns tomorrow, twenty identities go orphaned at once. Assign agents to a team or role, backed by a named individual, so that your [joiner-mover-leaver process](https://www.c1.ai/solutions/jml-automation) reassigns rather than orphans when that person moves on.\n\n## How does C1 handle agent discovery and ownership?[#](#how-does-c1-handle-agent-discovery-and-ownership)\n\nC1 treats agent identities the way it treats human ones: discovered, inventoried, owned, and reviewed. It maps every identity in your environment, human and non-human, surfaces the AI agents, links each one to an accountable owner, and keeps [governance](https://www.c1.ai/solutions/identity-governance) running at agent speed. Security here isn't the brake on your agentic rollout. [It's the engine](https://www.c1.ai/blog/security-is-the-engine-not-the-brake).\n\n[See how C1 discovers and governs every AI agent in your environment.](https://www.c1.ai/lp/request-demo)", "url": "https://wpnews.pro/news/you-can-t-govern-the-ai-agents-you-can-t-find", "canonical_source": "https://www.c1.ai/blog/how-to-discover-ai-agents", "published_at": "2026-09-22 07:00:00+00:00", "updated_at": "2026-09-22 17:52:38.783421+00:00", "lang": "en", "topics": ["ai-agents", "ai-safety", "ai-policy", "agent-protocols"], "entities": ["Salesforce", "Snowflake", "MCP"], "alternates": {"html": "https://wpnews.pro/news/you-can-t-govern-the-ai-agents-you-can-t-find", "markdown": "https://wpnews.pro/news/you-can-t-govern-the-ai-agents-you-can-t-find.md", "text": "https://wpnews.pro/news/you-can-t-govern-the-ai-agents-you-can-t-find.txt", "jsonld": "https://wpnews.pro/news/you-can-t-govern-the-ai-agents-you-can-t-find.jsonld"}}