Discovery and Inventory
Know every agent operating in or against your environment, who owns it, what it can reach, and when it was last reviewed.
Objective
Know every agent operating in or against your environment, who owns it, what it can reach, and when it was last reviewed.
Minimum bar (L2). Every agent the organization knows about is registered, owned, and reviewed on a defined cycle, and the boundary of what the inventory does not reach is written down rather than assumed to be empty.
6.1 Controls #
| ID | Control | Minimum bar (L2) | Enforced state (L3) |
|---|---|---|---|
| DISC-1 | Agent registry | A registry containing, for every managed agent: unique identifier, named human owner, business purpose, autonomy tier, tool inventory, data classes accessed, credential references, execution environment, deployment date, last review date, and decommission criteria. Entries are created before deployment, not reconstructed afterward. | Automated discovery across identity providers, cloud control planes, SaaS admin surfaces, network egress patterns, and code repositories. |
| DISC-2 | Unmanaged agent detection | A scheduled manual discovery sweep, at least quarterly, across the surfaces most likely to hold unregistered agents: low-code and copilot platforms, SaaS admin consoles with AI features enabled, identity provider app registrations created in the period, and developer environments. Findings are reconciled to the registry by hand, and known blind spots are documented and reported rather than left implicit. | Detection of unmanaged agents—the ones created in low-code tools, embedded in SaaS features, or run by developers locally against corporate credentials. |
| DISC-3 | MCP server inventory | A maintained list of every MCP server reachable from an agent runtime, recording owner, transport, authentication model, and the tools it exposes. Connection is restricted to an approved-server allowlist enforced at the client or gateway, and new servers require review before first use. | MCP server inventory: every server exposing internal systems, its authentication model, and which agents can reach it. |
| DISC-4 | Registry reconciliation | Periodic manual reconciliation of the registry against identity provider sign-in logs and cloud control-plane activity, with a named owner accountable for closing discrepancies. The reconciliation date and the count of unresolved gaps are reported, not just the clean rows. | Reconciliation between registry and observed activity, with alerting on unregistered principals taking actions. |
6.2 Evidence to Request #
- Registry export with owner attribution and review dates.
- A reconciliation report showing observed-but-unregistered agents.
- The discovery job’s coverage documentation, including what it cannot see.
6.3 Failure Modes #
- The registry covers agents built by the platform team and misses everything bought, embedded, or improvised.
- Ownership is assigned to a team alias, so nobody is accountable at 2 a.m.
- Decommission criteria are absent, so agents outlive their purpose and retain credentials indefinitely.