Trust3 says agent discovery must track hidden MCP connections

Trust3 AI published A Complete Guide to Agent Discovery on May 31, 2026. The guide defines agent discovery as the continuous inventory of every AI agent operating in an enterprise environment, the resources each agent can reach, and the people or teams that created it. Trust3 places that work as the first pillar of its Agent DOS model. The starting point is plain: an organization cannot attach runtime guardrails, audit logs, owner assignment, or a kill switch to an agent it does not know exists.

This is not a new model release or a benchmark announcement. It still belongs in the AI developer news cycle because 2026 enterprise agent products are turning agents into managed assets. Microsoft Agent 365, ServiceNow AI Control Tower, Collibra AI Command Center, and TrustLogix TrustAI all treat agents as objects that need governance. Trust3 focuses on the step before policy enforcement. It asks where a Copilot Studio support agent, a Bedrock internal agent, a Cursor or Claude Code MCP workflow, or a Databricks Mosaic analytics agent might exist before the security team has placed it in a registry.

Trust3's operational problem is the agent that bypasses procurement and change management. Traditional applications tend to create review points through new deployments, network changes, vendor onboarding, credential issuance, or infrastructure tickets. The Trust3 field guide argues that agents often avoid those choke points. A data scientist can create an agent inside Copilot Studio during an afternoon. An engineer can launch a Bedrock agent from the AWS console. A developer can connect a local IDE workflow to internal systems through an MCP server. If those paths are not inventoried, the first discovery point may be an incident review or a regulator's question.

The metadata Trust3 asks teams to collect is specific. Each agent needs an identity such as a service principal, application registration, or token, and it needs a human owner. The platform of origin matters because Bedrock, Databricks Mosaic, Copilot Studio, LangGraph, and custom Python expose different logging and policy surfaces. Tool bindings include MCP servers, internal APIs, plugins, and function permissions. Data reach should be tracked at the table, dataset, file-store, or knowledge-base level. Multi-agent systems add A2A relationships: which agent can call which peer, under which authority, and for which task.

Trust3's discovery approach has three inputs. The first is platform API discovery. Agents already deployed to Bedrock, Databricks, Copilot Studio, or similar platforms can be found through each platform's API and configuration data. The second is the development environment. Custom agents may not exist inside an agent platform, so repositories, CI pipelines, and container images have to be scanned for agent code and tool definitions. The third is runtime traffic. When an agent calls an MCP server or an internal API, network and identity signals remain. Trust3 describes egress observation as the failure case that catches agents missed by other inventory sources.

That taxonomy becomes a concrete task list for developers. When a team creates an agent project, the repository should carry the owner, service identity, allowed tools, MCP servers, data resources, and deployment stage next to the code. A LangGraph or custom Python agent using local environment variables and undocumented MCP configuration will not be visible through platform API discovery. If repository scans and runtime egress monitoring are also present, the organization at least has a path to answer why an agent called Jira and a customer table in the same session.

The Trust3 Agent Discovery product page uses more product-oriented language than the field guide. It says the product brings CloudTrail logs, platform APIs, SDK activity, and audit trails into one control plane. Its inventory record includes platform, owner, identity, data access, Trust Score, and status. The status labels include registered, unowned, and shadow AI. The underlying claim is that manual spreadsheets cannot keep pace with how quickly teams can create and modify agents.

The Trust Score model is also stated with numbers. Trust3 says each agent receives a 0 to 100 posture score using four weighted dimensions: policy compliance at 35%, scope adherence at 25%, security posture at 25%, and behavioral baseline at 15%. Those weights are not an independently verified industry standard. They are Trust3's product scoring model. Still, the variables reveal what the company wants to measure: whether an agent leaves its declared purpose, whether its credentials are too broad, whether its behavior diverges from its baseline, and whether active policy rules are being violated.

MCP appears as a separate risk surface inside this inventory view. Trust3 treats tool bindings as the place where an agent's blast radius becomes real. If an MCP server opens email, an issue tracker, a database, a browser, or a code repository, the connected tool can matter more than the agent's display name. Counting "12 Copilot Studio agents" is not enough. Security teams need to know which MCP server each agent can call, which credential that server uses against which API, and whether one agent can invoke another agent through A2A relationships.

This perspective connects directly to Microsoft's recent Agent 365 framing. Microsoft combines registry, shadow agent discovery, Entra, Defender, and Purview as an agent management surface. Trust3 is not tied to a specific productivity suite; it combines platform APIs, development scans, and runtime traffic as discovery sources. Both approaches treat agents more like users and applications that need inventory, identity, monitoring, and policy. The difference is where each starts. Microsoft is strongest inside a Microsoft 365 tenant and enterprise identity stack, while Trust3 foregrounds agents scattered across multiple platforms and custom code.

Okta's CISO-oriented agent security questions point at the same gap. Okta says organizations need the ability to discover agents across SaaS, browsers, endpoints, and the broader agentic AI ecosystem. Straiker Discover AI makes a similar pitch around AI agent inventory, misconfiguration, risky permissions, and unsafe MCP integrations. The vendors differ, but the shared event is clear: AI agents are moving from "model-calling code" into non-human identities and tool chains, and many asset inventory and IAM systems do not understand the agent-specific semantics yet.

Trust3 also maps discovery to compliance frameworks. The guide links discovery to the Map function in the NIST AI RMF, AI system inventory and ownership documentation in ISO/IEC 42001, EU AI Act Article 11 and Annex IV, SOC 2 and ISO 27001 asset inventory, and ISO/IEC 42005 impact assessment. That list can read like marketing, but it is practical in an audit. If a company cannot answer which AI agents it operates, who owns them, which data they can read, and which tools they can call, its governance documents remain detached from runtime reality.

Product teams should keep three constraints in view. First, discovery does not end with one detection product. Platform APIs may be accurate while missing custom agents and local coding agents. Repository scans may be useful while missing a runtime MCP binding added after deployment. Runtime egress monitoring may still struggle with encrypted traffic, shared credentials, and human-on-behalf-of-agent patterns. Trust3 recommends multiple sources because no single source is complete.

Second, the boundary between agent and script will disrupt operating policy. Trust3's FAQ distinguishes a script that executes fixed steps from an agent that receives a goal, plans, calls tools, and chooses the next step at runtime. Real codebases make this boundary messy. Is a cron job that asks an LLM to generate SQL an agent? Is a Slack bot that receives a user request and calls three tools an agent? If teams cannot answer consistently, their inventory criteria and security exceptions will diverge.

Third, decommissioning needs its own checklist. Trust3 says a retired agent should have credentials revoked, MCP connections closed, and live traffic for its service identity removed. Developers often treat feature shutdown as the end of the job. Agents can leave behind tokens, webhooks, scheduled tasks, MCP configuration, vector stores, audit logs, and A2A peers. If an agent is retired in documentation but still active at runtime, the next audit or incident will surface the mismatch.

For engineering teams, the immediate questions are operational. Where are agents recorded today: Jira tickets, README files, cloud console tags, IAM service account names, MCP config files, CI output, or a separate registry? If those records are scattered, discovery depends on memory. Who approves the tools and data reach an agent can use? If a developer can add an MCP server without approval, credential scope may become the incident root cause before the model prompt does.

Trust3 is a vendor, so its field guide should not be treated as a neutral standard. The actual accuracy of Trust Score, connector coverage, runtime attribution, and custom code scanning false positives still has to be evaluated inside each organization. The question the guide raises is useful anyway. Agent governance does not start when a policy document is published. It starts when the team can answer which agent used which identity to call which tool today.

Placed inside the broader agent control-plane market, the direction is concrete. Kill switches, policy enforcement, observability, and audit replay all depend on inventory that can actually find the agent. Trust3 calls that first line agent discovery. Developers do not need to memorize another security product name to act on it. They need to leave owner, identity, MCP binding, data reach, A2A relationship, and lifecycle stage as deployment artifacts whenever an agent is created. Without that record, the next missing capability will not be a smarter model; it will be a meeting to determine who built the agent in the first place.