We use optional cookies to understand website visits and identify visiting businesses. You can change your choice anytime using Cookie preferences.
Apollo records page visits and sets a first-party cookie to identify visiting companies globally. If person-level tracking is enabled in Apollo, it may also identify visitors from the U.S. Read Apollo's privacy policy.
Your browser's Global Privacy Control signal is enabled, so Apollo tracking is off.
PLATFORM / DISCOVERY & SHADOW AI
Connect the discovery sources you already use to surface AI activity missing from your connected inventory. Review the evidence, the identities associated where available, and the next governance action. It is the lowest-friction place to start: read-only, out of the path, and nothing changes how your agents run.
A finding names what was observed, the source that saw it, and whose activity it was where the evidence allows. The next step — register, assign an owner, attach a policy — is a separate, deliberate governance action. Example data, not a live tenant.
01 / INVENTORY
Products, agents and model runtimes seen by the sources you connect, each with the record that revealed it.
02 / ATTRIBUTION
The people and service accounts behind the activity, where the source carries identity. Unknown stays visible.
03 / GOVERNANCE
Each finding checked against what you have registered, with the next governance action named.
In the product
Recorded on a demo tenant: a Shadow AI finding with its reason and evidence, what each source family can discover and attribute, a cloud account enumerating its agents, and MCP catalog discovery.
Four screens from a recorded demo tenant.
Also in the product
WHY ONE VENDOR IS NOT ENOUGH
Your proxy sees traffic leaving the network, not the Copilot features inside a suite you already pay for. Your identity provider sees an OAuth grant, not an API key in a build job. Your endpoint agent sees a local model, your LLM gateway only the traffic routed through it. Each answer is right about its slice and silent about the rest. Discovery reads them together and correlates them into one inventory, with the source of every finding named.
| AI activity | SIEM & log feeds | Network & endpoint | Identity & SaaS audit | LLM gateways |
|---|---|---|---|---|
| Browser use of AI appsChatGPT, Claude or Gemini in a browser tab | Partly | Sees it | Partly | — |
| AI built into your SaaSCopilot in Microsoft 365, Gemini in Workspace | Partly | — | Sees it | — |
| OAuth grants to AI appsA user connects an AI tool to their mailbox or drive | — | — | Sees it | — |
| API keys in code and CIA build job calling a model API with a personal key | Partly | Sees it | — | Partly |
| Local models and CLIsA model runtime or AI CLI on a laptop | — | Sees it | — | — |
| Traffic through your gatewayWhich keys and users called which models | Partly | — | — | Sees it |
Typical visibility. What each tool actually sees depends on what it is configured to log and export; a SIEM sees only what is forwarded to it. Agents running in your cloud accounts are found by cloud inventory rather than by these signals.
HOW THE SIGNALS BECOME ONE FINDING
A single classification falls short. A destination match says which AI product was called, not by whom or whether it is governed. A sign-in says who, not what they sent. A steady rhythm of calls looks like an autonomous agent, and also like a cron job. GovernorAI joins these signals, so a finding rests on more than one of them.
A maintained catalog of AI fingerprints: provider endpoints, gateway records, model CLIs and runtime processes, matched against each source's own record format.
Events from every connected family are resolved to one subject, and the finding lists every source channel that saw it, with sample events to check.
The rhythm of a subject's activity can flag a suspected autonomous loop. It is reported as suspected, never confirmed on rhythm alone.
Each subject is compared with what you have registered. When that check cannot be answered, the finding says unknown rather than guessing shadow.
THE LOWEST-RISK FIRST STEP
Discovery is a consumer of feeds. Every source below is either something your forwarder posts to an ingest endpoint, something GovernorAI polls on a schedule, or a list call against a cloud control plane. There is no agent to install in the request path and no configuration change to the systems being inventoried. What you provide is an export or a read-only credential; what GovernorAI changes in your environment is nothing. If you stop, you revoke a credential and you are back where you started.
Discovery never sits between an agent and a model, or between an agent and a tool. It reads records after the fact. Your availability path is untouched.
The egress picture comes from the proxy, CASB and endpoint vendors you already deployed. GovernorAI parses what they export; it does not sniff traffic or terminate TLS.
Scheduled sources are pulled against fixed vendor hosts; SaaS and cloud sources are enumerated with list and get calls. Discovery does not modify the AI resources it inventories. Your SIEM or proxy may need an export configured; permissions and collection setup depend on the source.
Discovery produces findings and an inventory. Registering an agent, attaching a policy or quarantining anything is a separate, deliberate governance action on a different page.
A per-vendor adapter maps the native envelope into one event shape. Missing fields stay empty; no value is ever invented to fill a column.
source_vendor · principal · destination Destinations are matched host-boundary-aware against a deliberately narrow list of known AI provider domains, and gateway records are attributed from the provider they actually called.
api.openai.com → openai The subject is checked against what you have already registered. If that check cannot be answered, the event fails closed rather than being labelled shadow on a guess.
known · likely_shadow · unknown Findings carry every source channel that saw the subject, a first and last seen time, and sample events to pivot into. The estate exports as an AI-BOM.
JSON · PDF · sha256 content hash WHAT DISCOVERY ACTUALLY READS
Every source is a shipped adapter with a real parsing contract, and every source carries a posture: connected when an enabled feed exists, available when the adapter is registered and you have not wired it yet, planned when nothing ships. The surface is derived from live wiring, so it cannot claim a source the backend cannot actually ingest.
event envelope is unwrapped and indexed fields merged with host/source/sourcetype routing.records export and value query envelopes unwrapped.ddtags into user, host and env dimensions and reading the nested attributes object.records / transactions feed shape.{status, data} export envelope.Coverage is exactly the set of sources you connect — nothing is inferred about the ones you do not. Each source resolves to connected, available or planned from live wiring rather than a marketing list, and each connected feed reports healthy, stale or not configured: a feed that is enabled but has not reported yet is awaiting its first data, and is flagged once its verification window passes, because silence is not health. A coverage grid states, per source family and per contribution, whether you have a live source, a shipped source you have not connected, or a genuine gap.
WHY A FINDING SAYS WHAT IT SAYS
Three destination buckets and one strictly separate behavioural bucket. Each finding stores a machine-readable reason code, a human-readable detail, the set of source channels that observed the subject, and sample event identifiers you can pivot into — so an operator can see why a row was classified the way it was rather than being asked to trust a score.
| Classification | Reason code | What it actually means |
|---|---|---|
| known | registered_in_model_registry | The AI product the subject reached is registered in your model registry. This is a match against your own inventory, not a vendor allow-list. |
| likely_shadow | ai_product_fingerprint_no_governance | The destination matched a known AI provider and no governance coverage was found for it. This is the shadow-AI row. |
| unknown | unknown_endpoint | AI-tagged signal, but the destination matched no known AI product. It needs human triage; it is not asserted to be shadow AI. |
| unknown | unmanaged_principal | The directory loaded and this person was not in it. It means "not present in the governed inventory" — deliberately not a claim that the human is unknown to the company. |
| unknown | unknown_principal | No directory is wired, or it could not be read. GovernorAI reports that it could not tell, rather than defaulting to managed. |
| suspected_autonomous_loop | cadence | A subject's event rhythm is regular enough to be machine-driven. Computed from observed timestamps only — never from prompt or model content — and carried on its own row so a rhythm signal and a destination signal can never merge into one confidence. |
When the registry that answers "is this already governed?" cannot be read, the event is not classified at all. A shadow finding is never produced on an unanswered question.
WHAT YOU LEAVE WITH
Discovery produces four artefacts. All four are computed from live reads of first-class stores; none of them invents a row to fill a section.
Agents, the models they are associated with, the policies that govern them and the frameworks in use — exported as JSON or as a PDF, and fingerprinted with a content hash over the inventory so a post-hoc edit is detectable.
sha256 content hashEach finding keeps every source channel that observed the subject, the first and last time it was seen, its event count and a bounded set of sample events. An identity feed and an egress feed agreeing is visible as two channels, not one merged assertion.
source-vendor provenanceSource families against contributions — discovery, enrichment, attribution and prevention context. A cell is covered only when a connected source has reported for it. Partial means only part of that scope has reported. A source that is available but not connected is not coverage, and nothing shippable at all is an explicit gap, never a blank.
gap · partial · coveredWhere an identity source is connected, findings roll up how many distinct principals behind them are inside your governed directory and how many are not. Where no directory is wired, the answer is unknown — and the rollup says so rather than assuming.
counts, never a single scalar// GET /api/v1/aibom/export?format=json
{
"agents": [ /* id, name, namespace, environment, models, policies */ ],
"models": [ /* registry entry, approved_by provenance */ ],
"guardrails": [ /* policies covering at least one agent */ ],
"frameworks": [ "langchain", "langgraph", "crewai", "n8n" ],
"owners": [],
"tools_mcp": [],
"data_sources":[],
"notes": [
"Owners: GovernorAI records the agent registrant and model approver"
" as provenance, not a designated owner.",
"Tools/MCP: per-tenant agent-to-tool bindings"
" are not recorded yet, so this list is empty.",
"Guardrail coverage reflects the governance-graph projection"
" as of <timestamp> and may lag live policy assignments."
],
"content_hash": "sha256:…"
}WHAT STARTING LOOKS LIKE
A source is registered, issued its own scoped ingest credential, and can be proved end-to-end before you point production telemetry at it.
Pick a vendor whose posture is available. The catalog only offers what the running system can genuinely ingest, so there is no configuring your way into a dead end.
no codeEach source gets its own bearer token, bound to that source and that account, and rotatable and revocable on its own. A full account API key is never handed to a forwarder.
per-source, revocableA test-ingest call runs a representative payload for that vendor through the real adapter and the real classifier, and persists nothing. A successful preview proves the exact path your live telemetry will take.
persists nothingPush vendors post to the ingest endpoint. Pull-only sources are polled on an interval, so they are not real-time and are not presented as such. Some vendors support both.
push · pull · dualNothing on this page requires a policy, an SDK in an agent, or an enforcement decision. You can run discovery, export the AI-BOM and stop there. Registering a discovered agent, attaching a policy to it, or holding it are separate governance actions you take deliberately — and the state machine refuses several of them outright when the underlying finding is only circumstantial.
Start with one source
Bring one source you already run: a SIEM, a proxy, your identity provider or an LLM gateway. We will show you what it reveals, read-only, before anything else changes.