# AI inventory and agent map, with how each was found. > AI-SPM for agents, in ColossalX: a governed registry and a live AI Agent Map. Each agent is labelled with how it was found, mapped to the models, tools and data it reaches, recognised by its behaviour, and kept out of production until an accountable owner and a second approver have admitted it. A governed registry and a live map of agents found in code, traffic, CI and the cloud. Canonical page: https://colossalx.tech/platform/ai-inventory · Last reviewed: 6 Oct 2026 *Illustration:* Found, then owned: refunds-agent found calling registry; pricing-agent found calling registry; repo-agent to registry; registry to owner (owner named); registry to provider A; registry held for a person before customers (awaiting approval). ## Definition: Shadow agents Shadow agents are AI agents running without being registered, owned or approved: a script calling a model with a team key, a low-code agent built in an afternoon, or a vendor agent working on internal data. Unlike shadow AI tools, they act on their own, calling models and tools with nobody accountable for what they do. [AI security glossary](https://colossalx.tech/resources/glossary#shadow-agents) ## The threat and the control - **The threat:** An agent nobody registered starts calling models, and nobody is accountable for it. - **The control:** ColossalX finds it in traffic, code or CI, maps what it reaches, and asks for an owner. ## How it works: From an agent nobody registered to an owned one. One agent found in a repository: its threat brief, its place on the map, and the two people who admit it. ### Workflow: an agent found in code, owned (illustrative) 1. **Found in code.** A repository scan finds an agent and the AI libraries it imports. `agent = Agent(tools=[refund_payment, lookup_customer])` | refunds-agent · Found in code 2. **A threat brief.** Its own code gives a brief: abilities, risks and upgrades. Can do: refund payments; Risk: ASI02 tool misuse; Upgrade: agent framework | Tool that moves money (warning); Known issue in its version (warning: upgrade) 3. **On the map.** It joins the map with its calls, declared tools and data. Calls: model · provider A; Declares: refund_payment · customers | Found in code · Blast radius: 3 4. **Owned, then admitted.** An owner, then a second approver, before it reaches production. Accountable owner (done: Payments team); Guardrail profile (done); Second approver (waiting: waiting) | x, found ## What you see: The AI Agent Map, with what each agent reaches. Agents, model providers and models on one graph, built from what each agent declares and what the gateway sees. 1. **Agents enter four ways.** Registered by hand, found in code or traffic, or attested from CI. Each agent carries a label saying how it entered: registered by hand, found in code, discovered in gateway traffic, or attested from CI and the cloud. 2. **Recognised by behaviour.** Fingerprinting recognises an agent by what it does, not its key. Behavioural fingerprinting shows when an agent's behaviour moves from its baseline, and finds which known agent an anonymous caller really is. 3. **Mapped with blast radius.** The map shows what each agent calls, declares and delegates to. Click an agent to light up everything it can reach. The attack-path view shows routes from untrusted entry points to sensitive data. 4. **Owned before admitted.** An owner, a second approver and a guardrail profile before production. Registered is not approved. Workspaces roll admission out monitor-then-enforce, with time-boxed exceptions. *Illustration:* An illustrative agent registry: each agent with how it was found (registered by hand, found in code, attested from CI or seen in gateway traffic), its owner and its status. An unknown caller seen in traffic is named and waits for an owner, because registered is not approved. Notes: 1. How each agent was found 2. Seen in traffic, waiting for an owner 3. Registered is not approved ## How we know - Model, provider and delegation links on the map are observed from gateway traffic. - A credential used with the wrong behaviour raises an incident. - A risk score that comes from discovery is marked provisional. - Each agent keeps an append-only history of who acted on it, and why. ## Where a found agent goes next. Finding an agent is the start. The same record carries it through admission, policy, testing and the twin. - **Admission.** An owner, a second approver and a guardrail profile; credentials carry what was measured. - **Guardrails.** Its requests and tool calls are checked at the gateway under its own credential. - **Red-teaming.** A registered agent can be attacked in-path, with authorisation, through your real controls. - **CyberTwins.** Governed agents can be projected into a twin and attacked there, not in production. Where an x ends up: x, found. ## Specs: delivery and data - **Delivery:** SaaS, from one login. - **Isolation:** Each customer runs in an isolated workspace with its own database. - **Certifications:** None held. Frameworks are mapped to and assessed against. ## Frameworks - Assessed per agent against OWASP Top 10 for Agentic Applications: Each registered agent, against ASI01 to ASI10. - Mapped to EU AI Act: An owned agent inventory, cross-mapped. - Mapped to ISO/IEC 42001: The same inventory control, with evidence. - Mapped to NIST AI RMF: Inventory under Map and Govern. ## What it does not do - Tools and data on the map are what each agent declares; model links come from traffic. - The identity gate ships in monitor. Refusing unenrolled agents at the gateway is your decision. - Attack paths need your data assets catalogued; without them the map shows none rather than guessing. - Cloud placement is proven on AWS; other cloud connectors are built but not yet proven. *Illustration:* Agent record · labelled, not guessed: Agent pricing-agent; How found Discovered in traffic; Risk score Provisional; Owner Not yet named; Admission Monitor, until approved. Provenance kept. ## Questions ### What is AI security posture management (AI-SPM)? AI security posture management, or AI-SPM, is the practice of knowing which AI systems an organisation runs, how they are configured and what they can reach, and keeping that picture current. For agents, it starts with a registry, a map of what each agent touches and a record of how each one was found. ### What is an AI agent registry? An AI agent registry is the governed catalogue of the agents a company runs. In ColossalX each entry records how the agent was found, who owns it, its trust zone, its guardrail profile and whether it is admitted to production, with an append-only history of what was done to it and why. ### How does ColossalX find agents nobody registered? ColossalX finds agents calling through its gateway without a registration, agents in scanned repositories, and agents attested from CI or the cloud. Behavioural fingerprinting matches an anonymous caller to a known agent where it can; one it cannot match is shown as new and needs an owner. ### What is behavioural fingerprinting for AI agents? Behavioural fingerprinting recognises an agent by what it does rather than by the key it presents: the models it calls, the tools it uses and the shape and rhythm of its requests. ColossalX keeps a fingerprint per agent, shows when behaviour moves from its baseline, and spots a credential used by the wrong agent. ### What is the blast radius of an AI agent? The blast radius of an AI agent is everything it could affect if it were compromised: the models it calls, the tools and data it declares and the agents it delegates to. On the AI Agent Map, clicking an agent highlights all of it, and an attack-path view shows routes to sensitive data. ## Related - [Shadow AI](https://colossalx.tech/platform/shadow-ai) - [Agent identity](https://colossalx.tech/platform/agent-identity) - [AI bill of materials](https://colossalx.tech/platform/ai-bill-of-materials) --- ColossalX is an AI security and governance platform from Quantexra Labs LLP, delivered as SaaS. Book a walkthrough: https://colossalx.tech/demo · client.success@quantexra.tech