You Can't Secure Agents You Can't Find: A Practical Guide to AI Agent Discovery and Governance

An enterprise security team is asked a seemingly simple question: How many AI agents are running across the organization?

They produce a number.

A week later, the number changes.

A sales operations team has built an agent using a low-code platform. A developer has connected an AI coding assistant to internal systems through an MCP server. A SaaS vendor has enabled an agentic capability inside an application the company already uses.

None of these necessarily went through the organization's standard architecture or security review.

This is the emerging challenge of shadow AI agents.

Unlike traditional shadow IT, AI agents don't simply store information or provide another interface to an application. They can retrieve sensitive data, invoke APIs, modify records, initiate workflows, and execute actions across multiple systems.

And increasingly, they can decide which actions to take without requiring a human to approve every step.

That changes the security equation.

An organization cannot govern an agent it doesn't know exists. But discovering an agent is only the beginning.

The real challenge is establishing who owns it, what it can access, what actions it can perform, and how those actions are monitored and controlled.

Fortunately, a growing ecosystem of identity platforms, agent registries, gateways, observability tools, and security products is emerging to address these challenges.

The important question is not simply which tool to purchase. It is how these capabilities fit together.

1. Why traditional asset discovery isn't enough

Traditional enterprise asset management focuses on relatively well-defined resources: servers, applications, endpoints, service accounts, APIs, and cloud workloads.

AI agents introduce a different kind of asset.

An agent might exist as:

• A configured agent inside Salesforce Agentforce or Microsoft Copilot Studio.
• A custom application built using LangGraph, CrewAI, or another agent framework.
• An AI coding assistant connected to internal tools through MCP.
• A background process that invokes an LLM and executes actions based on its responses.
• An embedded capability inside an existing SaaS application.

These agents may operate across different execution environments, identity systems, and integration architectures.

Some are registered in enterprise platforms. Others exist only as application code, cloud workloads, or local developer configurations.

Consequently, there is no single discovery mechanism that can reliably identify every agent across an enterprise.

How agent discovery actually works

Several approaches are emerging.

API-based discovery

Security platforms integrate with agent platforms through supported APIs to retrieve metadata such as agent names, creators, configurations, permissions, and status.

This works well for supported platforms but may not reveal custom agents or agents running in unsupported environments.

Browser-based discovery

Browser extensions can identify employee interactions with AI applications and agent-building platforms.

This is useful for uncovering shadow AI adoption, although observing usage does not necessarily reveal every agent, its complete configuration, or its runtime permissions.

Cloud and workload discovery

Organizations can inspect cloud resources, deployment configurations, service identities, container workloads, and application telemetry to identify custom agents.

This becomes especially important when agents are deployed as backend services rather than managed through a commercial agent platform.

Network and runtime discovery

API gateway logs, network telemetry, identity-provider events, and tool-invocation traces can help identify agent activity.

For example, repeated calls to an LLM endpoint followed by API requests to enterprise applications may indicate an agentic workflow.

However, such patterns are not conclusive proof that a workload is an autonomous agent.

Each method provides a different view.

The practical implication is straightforward: enterprise agent discovery requires multiple sources of evidence, not just a single inventory API.

2. The five layers of AI agent governance

One useful way to evaluate the emerging tooling landscape is to separate agent governance into five capabilities.

Layer 1: Discovery — What exists?

The first requirement is a reliable inventory of agents across the organization.

At a minimum, an inventory should capture the agent's purpose, environment, creator, accountable owner, operational status, connected systems, and approval state.

It should also identify potential risks, such as exposed endpoints, excessive permissions, hardcoded credentials, and agents that remain active after their owners leave.

Discovery answers a fundamental question:

What agents are operating in our environment?

But knowing an agent exists does not mean it is secure.

Layer 2: Identity — Who is acting?

An agent interacting with enterprise systems needs an identity that can be authenticated, managed, and audited.

Ideally, that identity is distinguishable from both the human user who initiated the workflow and the application hosting the agent.

This distinction matters.

If multiple agents share the same service account, security teams may struggle to determine which agent performed a particular action.

An agent identity should support lifecycle management, credential rotation, access revocation, and clear ownership.

Identity answers:

Which agent is making this request, and who is accountable for it?

Layer 3: Authorization — What is it allowed to do?

Authentication establishes identity. Authorization determines permitted actions.

Consider an agent that can retrieve Salesforce customer records.

Should it also be able to update those records?

Delete them?

Access records belonging to another customer?

Invoke a financial transaction API?

The agent's permissions should reflect its business purpose, not merely the permissions available to the application or user account through which it operates.

This requires controls such as least-privilege access, scoped credentials, resource-level authorization, and restrictions on sensitive operations.

Crucially, authorization must be enforced by trusted systems rather than relying exclusively on instructions provided to the language model.

Layer 4: Observability — What actually happened?

An agent can be properly registered, authenticated, and authorized while still behaving unexpectedly.

Security and engineering teams therefore need visibility into execution.

Useful telemetry includes:

• Agent and session identifiers.
• Tool invocations and their outcomes.
• Target resources and authorization decisions.
• Workflow transitions and failures.
• Policy violations and anomalous activity.
• Correlation identifiers linking actions across systems.

Observability enables incident investigation, troubleshooting, performance analysis, and compliance review.

However, capturing traces is not equivalent to preventing unsafe actions.

Layer 5: Enforcement — What can be stopped?

The final layer is the ability to enforce policy at execution time.

Examples include blocking an unauthorized tool invocation, requiring approval for a high-impact transaction, limiting access to sensitive resources, or revoking an agent's credentials.

Enforcement is especially important because agent behavior is partly determined at runtime.

Unlike conventional application workflows, an agent may dynamically select tools and determine the sequence of operations needed to achieve a goal.

The enforcement layer must therefore remain effective even when the model chooses an unexpected action.

Together, these five layers provide a more complete governance model: discovery establishes visibility, identity establishes accountability, authorization establishes boundaries, observability establishes evidence, and enforcement provides control.

3. A practical example: the customer-support agent

Imagine an enterprise deploying an AI customer-support agent.

The agent can retrieve customer information from Salesforce, query an internal knowledge system through an MCP server, and invoke an API to initiate refunds.

From a business perspective, this is an attractive use case.

The agent can reduce manual work, respond faster, and potentially resolve customer issues without human intervention.

Now consider the governance questions.

The agent appears in an internal registry. It has a service identity. Its tool calls are recorded in an observability platform.

Everything appears reasonably controlled.

But suppose the agent receives a customer message requesting a $5,000 refund.

Who determines whether it can issue that refund?

The language model might conclude that the refund is justified. The API credentials might technically permit the operation. The observability platform might faithfully record the transaction.

None of those facts establishes that the refund was authorized.

The refund service needs to enforce the applicable business policy independently of the model's reasoning.

For example, the policy might allow refunds up to $100 automatically, require human approval for larger amounts, and reject requests that do not meet eligibility requirements.

This illustrates an important distinction:

Agent governance cannot stop at knowing which tools an agent can call. It must also consider which business operations the agent is authorized to perform, on which resources, and under what conditions.

The same principle applies to updating customer records, modifying infrastructure, approving payments, and accessing confidential information.

4. The emerging agent governance tooling landscape

Several technology categories address different parts of this architecture.

No single category should automatically be treated as a complete governance solution.

Microsoft Entra Agent ID: identity and lifecycle

Microsoft Entra Agent ID approaches agent governance through identity management.

Microsoft's architecture introduces agent identity blueprints and agent identities, allowing supported agents to be represented and managed within the Entra ecosystem.

The model supports ownership, identity lifecycle management, and integration with enterprise access controls.

This is an important architectural development because it moves agent identity closer to the established practices used for managing users, applications, and service principals.

For organizations already invested in Microsoft identity infrastructure, this is a logical starting point.

However, identity management should not be confused with universal agent discovery.

An agent running outside supported integrations may not automatically become visible simply because an organization deploys Entra Agent ID.

Source: Microsoft Entra security for AI overview

AWS MCP Gateway and Registry: cataloging and controlling agent integrations

The open-source MCP Gateway and Registry project from AWS Labs addresses a different problem.

As developers adopt MCP, organizations need a way to catalog MCP servers, tools, agents, and related assets without relying on scattered configuration files and hardcoded endpoints.

The project combines registry capabilities with optional gateway functionality.

Its documented capabilities include integration with identity providers, scoped asset visibility, registration-time security scanning, and tool-level access controls.

This makes it particularly interesting for engineering teams experimenting with centralized management of agent integrations.

However, a registry primarily governs assets that are registered or integrated with it.

It should not be assumed to discover every unmanaged agent or MCP server operating elsewhere in an organization.

Similarly, gateway enforcement only applies to traffic that actually passes through the gateway.

For teams building their own agent platforms, this distinction is critical.

Source: AWS — Governing AI Assets at Scale with MCP Gateway and Registry

MuleSoft Agent Fabric: enterprise agent connectivity and governance

Salesforce introduced MuleSoft Agent Fabric on September 25, 2025 as an approach to connecting, orchestrating, and governing agents across enterprise environments.

Its announced architecture includes several components:

• Agent Registry: A catalog of agents, tools, and supported integration assets.
• Agent Broker: Coordination and routing across agents.
• Agent Governance: Policy and control capabilities using gateway infrastructure.
• Agent Visualizer: Visibility into relationships and interactions among agents.

The broader architectural idea is important.

Enterprise agents are unlikely to operate within a single vendor ecosystem.

A customer-facing agent might interact with Salesforce, an ERP system, internal APIs, cloud services, and external AI tools during the same workflow.

A governance architecture must account for these cross-platform interactions.

The practical question for an enterprise evaluating Agent Fabric is which agents and tool connections it can discover, which interactions it can route through its control plane, and where policies are actually enforced.

At announcement, Agent Governance was already generally available, while Agent Registry, Broker, and Visualizer were targeted for general availability in October 2025 — a milestone that, as of this writing, has already passed. Confirm each component's current state with Salesforce rather than treating any of it as still pending.

Source: Salesforce — MuleSoft Agent Fabric announcement

Salesforce Agentforce: observability and operational governance

Agentforce provides another important part of the picture: understanding agent execution.

Salesforce has described capabilities for session tracing, analytics, monitoring, and optimization.

These help teams investigate how supported agents process requests, interact with tools, and produce outcomes.

For engineering teams, this kind of visibility is valuable for both operational reliability and governance.

However, observability has a fundamental limitation.

A trace showing that an agent accessed a customer record does not establish whether the access was appropriate.

That decision depends on identity, authorization, application context, and business policy.

Agent Analytics and Agent Optimization were already generally available at announcement; Agent Health Monitoring was targeted for Spring 2026, a date that has also now passed. Organizations should therefore evaluate Agentforce observability as part of a broader control architecture rather than treating tracing as a substitute for authorization.

Source: Salesforce — Agentforce observability capabilities

Shadow-AI discovery and security vendors

A growing market of security vendors focuses on identifying unmanaged AI usage and associated risks.

Depending on the product, discovery may rely on browser extensions, SaaS integrations, identity telemetry, endpoint visibility, or network monitoring.

These tools can help security teams uncover AI adoption that never passed through formal approval processes.

But discovery coverage varies significantly.

A vendor might identify employees using an agent-building platform without being able to inspect the agents they created.

Another might inventory agents in supported SaaS platforms while missing custom agents deployed as internal services.

When evaluating these products, the most important question is not simply how many integrations they advertise.

It is what those integrations can actually observe.

Sources: Nudge Security-sponsored article on BleepingComputer, Push Security comparison, and Netwrix comparison. These are vendor-authored or sponsored sources and should be treated accordingly.

5. How the tools fit together

The following comparison illustrates the primary architectural role of each technology.

These categories overlap, and product capabilities will continue to evolve.

The key is to evaluate them against the governance capabilities an organization needs rather than assuming that every product described as an AI governance platform solves the same problem.

6. A practical enterprise implementation strategy

Organizations do not need to wait for a perfect governance platform before taking action.

A phased approach can provide immediate value.

Phase 1: Establish a baseline inventory

Start with the systems already under enterprise control.

Identify agents in supported SaaS platforms, internal applications, cloud environments, and developer tooling.

Record ownership, purpose, deployment environment, connected systems, credentials or identities, and approval status.

Separate confirmed agents from suspected agentic workloads so the inventory does not create a false sense of precision.

Phase 2: Identify the highest-risk agents

Not every agent presents the same level of risk.

An internal knowledge assistant with read-only access has a different risk profile from an agent capable of modifying financial records or production infrastructure.

Prioritize agents based on the sensitivity of accessible data, scope of permissions, autonomy, exposure, and potential business impact.

Pay particular attention to agents with destructive privileges, externally accessible endpoints, shared credentials, or no accountable owner.

Phase 3: Establish identity and authorization boundaries

Where possible, give agents dedicated identities and narrowly scoped access.

Avoid shared credentials that make it difficult to attribute actions.

For sensitive operations, enforce resource-level and business-level authorization in trusted application services or gateways.

Do not rely solely on prompts such as "only access the current customer's records" or "never approve refunds above $100."

Instructions can guide model behavior, but they are not a reliable security boundary.

Phase 4: Add runtime visibility

Instrument agent execution with correlation identifiers, tool-call telemetry, authorization outcomes, and operational metrics.

Connect these signals to existing monitoring and incident-response processes where practical.

Design logging carefully to avoid unnecessarily capturing sensitive customer information, credentials, or confidential prompt content.

The objective is actionable evidence, not unlimited retention of everything an agent sees.

Phase 5: Introduce enforcement and continuous review

Once agents and their integrations are understood, introduce controls appropriate to their risk.

These may include gateway policies, approval workflows, permission restrictions, rate limits, credential revocation, and automated detection of anomalous activity.

Review the inventory continuously as new agents are deployed, permissions change, and owners move between teams or leave the organization.

Governance should become part of the agent lifecycle rather than a one-time discovery exercise.

7. The architectural challenge enterprises should not overlook

There is a deeper issue beneath agent discovery.

Traditional applications generally execute workflows defined by developers.

AI agents introduce another decision-making layer.

A model may determine which tool to invoke, which parameters to provide, and which sequence of operations to perform.

That flexibility creates value, but it also introduces uncertainty.

For example, a developer may intend an agent to retrieve a customer record, summarize an interaction, and recommend a next action.

But the agent might receive misleading instructions embedded in retrieved documents, customer messages, or external tool responses.

If the model can influence authorization-sensitive parameters, an unexpected tool invocation could target the wrong customer or resource.

This is why enterprise governance must distinguish between the agent's reasoning and the security controls that authorize its actions.

The model can propose an action.

The trusted application layer must determine whether that action is permitted.

An agent's identity, user context, resource ownership, and applicable business rules should be validated independently of model-generated arguments.

This is not an entirely new security principle.

It is the familiar principle of enforcing authorization at a trusted boundary, applied to systems where the next operation may be selected dynamically by an AI model.

And it is one of the most important architectural considerations as enterprises move from AI assistants to agents capable of executing real business transactions.

8. Questions to ask before buying an agent governance tool

Before selecting a platform, enterprise architects and security teams should be able to answer a few practical questions.

1. Discovery: Can the product identify custom agents as well as agents created inside supported SaaS platforms?
2. Coverage: Which discovery methods are used, and what remains invisible?
3. Identity: Can individual agents be identified and associated with accountable owners?
4. Authorization: Can policies restrict actions at the resource and business-operation level?
5. MCP security: Can the product inspect and control MCP connections, tool permissions, and authentication?
6. Observability: Can security teams trace actions across agents, tools, and downstream enterprise systems?
7. Enforcement: Can the product block unsafe operations before execution, or does it only report them afterward?
8. Lifecycle: What happens when an agent is retired, its permissions change, or its owner leaves?
9. Integration: Can the product work with existing identity, API management, cloud, and security infrastructure?
10. Evidence: Can the vendor demonstrate these capabilities in a realistic environment rather than relying only on architecture diagrams?

These questions help separate visibility tools from identity systems, observability products, and genuine enforcement capabilities.

They also expose where multiple technologies may need to work together.

Conclusion: Discovery is the starting point, not the destination

The biggest mistake enterprises can make is treating AI agent governance as a single product purchase.

An inventory tells you what exists.

Identity tells you who is acting.

Authorization establishes what an agent is permitted to do.

Observability tells you what happened.

Enforcement determines whether an unsafe action can be stopped.

Each capability matters, and none is sufficient on its own.

As enterprises move from AI assistants that generate recommendations to autonomous agents that execute business operations, governance must evolve from documenting access to controlling execution.

That evolution does not require abandoning established security principles. It requires applying them consistently to a new class of software actors.

The question is no longer just "How many AI agents do we have?"

It is "Which agents can act on our behalf, what are they allowed to do, and who is accountable when they do it?"

Organizations that can answer those questions will be in a much stronger position to scale agentic AI responsibly.

---

References

1. BleepingComputer — Shadow AI agents are multiplying: Here's how to find and secure them (sponsored content)
2. Microsoft Learn — Entra security for AI overview
3. AWS Open Source Blog — Governing AI Assets at Scale with MCP Gateway and Registry
4. Salesforce — MuleSoft Agent Fabric announcement
5. Salesforce — Agentforce observability capabilities
6. Push Security — Top 10 shadow AI discovery and governance tools (vendor comparison)
7. Netwrix — Shadow AI detection tools (vendor comparison)