It is a standard maxim in cybersecurity that you cannot secure what you cannot see. Agent sprawl has made the same principle true for AI governance, with a sharper edge: you cannot govern a population of agents you cannot categorize, register and fingerprint.
Agents now quickly proliferate across repositories, notebooks, demo branches, cloud environments, and production — faster than governance can follow.
As a result, most enterprises have no reliable answer to these basic questions with security, risk and governance implications:
- What agents exist in our environment.
- Where do they run?
- Who is accountable for them?
- What identities do they hold?
- What tools can they reach?
- And, which of them have been evaluated for resilience and trustworthiness for their task?
That gap is the governance blindspot, and it is the reason we built Vijil Discover.
Discover scans five surfaces continuously — cloud VPC, on-prem, endpoints, browser, and source code — fingerprints every agent it finds, and lands it in one registry as an enriched record with a named owner, a cryptographic identity, and a risk profile. It is the visibility layer for the agent trustworthiness lifecycle, and it extends the Vijil platform to its logical starting point: before an agent can be evaluated, protected, or improved, it has to be known.
Shadow AI and ungoverned AI are different problems
Shadow AI is a familiar problem with a familiar shape. It began as a security concern: blocking unsanctioned use of third-party GenAI apps, and more recently limiting agents used for vibe coding or personal productivity on employee devices. As organizations eased those policies to permit sanctioned use, security teams shifted from blocking to risk mitigation — enforcing data security and compliance policy on prompt input, and preventing exfiltration through prompt injections.
Agent sprawl has created a second problem that the first playbook does not solve. Industry analyst firm Gartner predicts that by 2027, 40% of enterprises will demote or decommission autonomous AI agents because of governance gaps found only after production incidents. The stakes are higher than with GenAI apps, because a rogue or compromised agent can act, and even a sanctioned, legitimate agent can take ungoverned actions — accessing or performing inference on sensitive and regulated data without anyone having decided that it should.
Ungoverned AI, in other words, is not the same as shadow AI. It’s legitimate agents operating without visibility, ownership, or trustworthiness assessment:
- Inconsistent visibility. Governance teams have no centralized view of what agents - rogue or legitimate - are under development and which are in production.
- Unclear ownership. No standard mechanism assigns the person or team accountable for the agent. Unowned agents still hold API keys, and rotating those keys risks breaking dependencies nobody has mapped.
- No validation of trust. Agents are not tested for safety, reliability, and security against their specific risks and requirements before deployment.
- Ineffective guardrails. Generic guardrails do not constrain an agent’s risky behavior, improve its resilience, or prevent the failures specific to it in production.
- No auditability. Without clear accountability for the deployment and behavior of new agents, governance policies have no enforcement target.
Why the existing tooling stops short
The AI security tools that emerged in response to shadow AI focus on the risks that already exist. They take a top-down approach: profile and map what is already running, combine posture with runtime and environment metadata to produce a prioritized list of risk objects, and apply generic guardrails. Each agent is treated as a black box to be constrained from the outside.
Agent identity security vendors start from a different premise but land in a similar place. Their governance pivot is the agent’s permissions and data access — not how the agent behaves, and not whether it is exposed to failures, novel attack techniques, or emergent probabilistic behavior.
Governing agents requires the opposite approach: understanding the agent itself, so that hardening follows the policies and context that actually apply to it. That is why discovery in the Vijil platform is not a standalone inventory feature. It is the intake stage of a trust lifecycle.
Many surfaces in, one registry out
Discover connects to both the source of agents and their destination. On the source side, it scans GitHub repositories for agent signatures. On the destination side, it scans the corporate environments and cloud VPCs where agents actually run. Five surfaces feed one registry:
- Cloud VPC — AWS, GCP, Azure
- On-prem — Kubernetes, VMware
- Endpoints — Mac, Windows, Linux
- Browser — model use in the browser
- Source code — GitHub repositories
Each finding becomes an enriched agent record: identity, model, owner, permissions, and risk, stored, searchable, and auditable. For custom agents, that depth comes from Kubernetes service discovery, host-runtime detection, and API gateway auditing rather than signature matching alone.
Vijil Discover runs as a scheduled scan inside your own environment — not as a SaaS service reaching in through a proxy or gateway. Metadata leaves; your data never does.
From shadow to attested
Discovery establishes what exists. Attestation establishes that what exists is who it claims to be. Vijil Discover moves an agent through four steps:
- Scan. Five surfaces, continuously: cloud VPC, on-prem, endpoints, browser, and source code.
- Fingerprint. Identify each workload as an agent by its model, its tools, and its operational reach.
- Register. Land it in one registry as an enriched record with a named owner, permissions, and risk.
- Attest. Issue cryptographic identity via SPIFFE / SPIRE X.509 SVIDs — extending not retrofitting identity access management for a new class of assets.
Registration is the explicit governance handoff. Discover reads the agent source, builds a versioned A2A card in a centralized inventory, generates the agent profile, creates a persistent identity, and establishes governance ownership.
It returns an Agent ID, a constraint policy URL, and a SPIFFE identity scope.
That identity is cryptographic rather than inferred, supporting a robust, extensible agent security architecture by design. An IAM token says which account an action was taken under; an X.509 SVID establishes which workload took it. Credentials follow the same principle — ephemeral, vault-pulled, auto-rotated, never persisted locally — which removes the orphaned keys that make shadow agents so dangerous to remediate.
The agent moves from unknown to known, and from ungoverned to governable.
Governance intake, not a list
An inventory that ends in a spreadsheet does not change anything. Findings from Discover arrive in the Vijil Console, where agent owners, business owners, and risk owners triage them: dismiss, ban, or promote into the Agent Registry for lifecycle management. The goal is to funnel agents built for legitimate use back into a proper governance workflow, rather than repeat the mistake of the first wave of GenAI adoption risk management tactics by uniformly blocking agents.
Once an agent is registered, governance teams can run a human-in-the-loop process to collect the business case and technical specifications from the agent owner, through either the UI or the CLI. That input sets the rest of the lifecycle in motion and defines the promotion and engineering governance gates: what trust score is acceptable for this agent, which bespoke policies apply, and whether it is protected against its known weaknesses and vulnerabilities before deployment.
This matters because most governance teams are resource-constrained. Even where a department has a legitimate justification for its use of AI, the review queue is longer than the team can clear. Manual audits and information collection do not scale to the volume of agents now in flight.
What is needed is a holistic approach that pairs system-level discovery and profiling with what humans know about the agent, its intent, and the policies and compliance mandates it should adhere to — so that the business owner responsible for the use case and the risk owner who gates deployment are working from the same record.
Where Discover fits in the agent trustworthiness lifecycle
Discover is the first stage of a six-stage lifecycle: Discover → Register → Evaluate → Protect → Monitor → Adapt. Discover inventories the agents actually running and registers the verified ones. Diamond evaluates them against custom policies for reliability, security, and safety. Dome enforces those policies as runtime guardrails. Darwin turns operational telemetry into defensive improvements.
Every stage after the first depends on knowing which agents exist. Without discovery, questionnaires have no subjects and policies have no enforcement targets. With it, three things become true that were not true before:
- Ownership at intake. Every record carries a named owner, so governance decisions have a responsible party attached, and processes for creating, updating, retiring, and auditing agents have someone to attach to.
- Validated trustworthiness. A registered agent can be evaluated against relevant policies and compliance mandates, and its protections validated against its specific vulnerabilities and weaknesses, as part of a formalized engineering governance process.
- Provable scope. Estate size, risk, and compliance claims become enumerated rather than estimated.
Governance starts with enumeration
Enterprises cannot assess, harden, or attest to an estate they have never fully seen — and the agents most likely to cause harm are the ones no one registered. Discover creates the authoritative inventory the rest of the trust lifecycle is built on.
Get started:
$ pip install vijil-sdk
$ vijil discover --github-org acme
$ vijil register github.com/acme/agent
Reach out to find your shadow agents and schedule a demo of the Vijil platform.
.png)