Asset Inventory & Discovery of the Agent Estate

Connected tools and functions are the plugins, connectors, functions, application programming interfaces, and Model Context Protocol (MCP) servers made available to a synthetic subject. MCP is an integration pattern that allows a synthetic subject to discover and use external tools, data sources, and actions through a structured interface.

This configuration creates an elevated exposure condition because connected tools define what the synthetic subject can do beyond text generation. A tool may allow it to read records, send messages, update systems, retrieve files, call APIs, execute commands, or transmit data outside the immediate application.

The primary risk is unsafe tool trust. Tool names, descriptions, schemas, parameters, outputs, and server definitions may influence how the synthetic subject chooses and uses tools. If these definitions are changed, poisoned, impersonated, or poorly governed, the synthetic subject may call the wrong tool, pass sensitive data to an unsafe tool, or perform an action outside its approved purpose.

Investigators should review connected tool inventories, MCP server records, tool definitions, schemas, descriptions, permissions, version history, provenance, tool-call logs, runtime egress, and change approvals. Particular attention should be given to newly added tools, changed descriptions or schemas, shadowed tool names, unexpected destinations, and tool calls that cannot be attributed to an approved configuration.

Investigative Relevance

Connected tools and functions are relevant because they convert a synthetic subject from an advisory system into an actor with operational capability. The configuration of tools determines whether the synthetic subject can only answer, or whether it can retrieve, modify, send, execute, or integrate across systems.

This section is especially relevant where synthetic subjects use marketplace tools, plugins, MCP servers, internal functions, SaaS connectors, email tools, database tools, cloud APIs, command execution tools, or externally supplied tool runtimes.

Vendor-embedded AI is a synthetic subject delivered through a third-party platform rather than built and operated entirely in-house. This may include an assistant built into a Software as a Service (SaaS) application, a vendor-hosted agent platform, or a third-party artificial intelligence capability connected to marketplace tools, plugins, connectors, or external services.

This deployment pattern creates an elevated exposure condition because the organization grants access to its own data and workflows, while key operating components remain outside its direct control. The model, prompts, tool wiring, safety controls, update channel, logging, and connected suppliers may be managed by the vendor or its ecosystem.

The primary risk is rented trust. The synthetic subject may run inside the organization’s tenant with access to customer records, tickets, files, messages, workflows, or connected systems, but its behavior may depend on vendor-managed logic or third-party tools. A silent vendor update, compromised connector, weak marketplace control, or unsafe default configuration may alter how the synthetic subject behaves without the organization fully observing the change.

A related risk is downstream model-provider exposure. The vendor may use a foundation model provider, inference platform, embedding service, or agent runtime to deliver the artificial intelligence capability. Organizational data, prompts, retrieved context, outputs, telemetry, or tool-call metadata may therefore pass beyond the SaaS vendor to backend services the organization cannot directly inspect or control.

A further risk is externally shaped invocation. Customer fields, partner messages, inbound emails, support tickets, uploaded documents, or web forms may carry instructions that later influence the vendor-embedded synthetic subject. An external actor may therefore steer activity inside the organization’s trusted SaaS environment without directly authenticating to that environment.

Investigators should review the vendor’s AI feature scope, tenant permissions, service identities, connector inventory, marketplace tools, update history, prompt and response logs, tool-call records, data access logs, and available vendor audit trails. Particular attention should be given to vendor-managed changes, third-party connectors, downstream model-provider exposure, externally supplied records, allow-listed external destinations, and cases where the organization cannot determine why the synthetic subject acted.

Investigative Relevance

Vendor-embedded AI is relevant because the organization may rely on a synthetic subject it does not fully control. The system may appear to operate as a native part of a trusted business platform, while the directive, model behavior, tool routing, data processing path, or update channel remains dependent on the vendor, foundation model providers, and connected suppliers.

This section is especially relevant where artificial intelligence features operate inside customer relationship management platforms, ticketing systems, productivity suites, document platforms, email systems, support tools, finance systems, or other Software as a Service environments with access to organizational data and workflows.

Orphaned agent identity occurs when a synthetic subject’s credential, service account, connector identity, token, or cloud role remains active after the agent, workflow, vendor tool, or integration it supported has been retired, replaced, or abandoned.

This configuration creates an elevated exposure condition because the identity may retain access without an active owner, business purpose, or monitoring expectation. Authentication by the orphaned identity may be mistaken for legacy system behavior or ignored because no current team clearly owns it.

The primary risk is uncontrolled residual access. An orphaned identity may still retrieve data, call Application Programming Interfaces (APIs), access cloud resources, or operate tools after the original synthetic subject is no longer in use. The access may be later repurposed, or become a candidate for misuse, causing validation of legitimate activity difficult, as well as attribution.

Investigators should review identity ownership, last-use timestamps, deployment records, connector inventories, access review results, vendor integrations, and decommissioning records. Particular attention should be given to active credentials linked to retired agents, inactive projects, disabled applications, former vendors, or undocumented workflows.

Investigative Relevance

Orphaned agent identities are relevant because they preserve access after operational need has ended. This sub-section is especially relevant during incident containment, vendor offboarding, platform migration, and synthetic subject decommissioning.

Uninventoried agent identity occurs when a synthetic subject authenticates through a credential, service account, token, connector, cloud role, or application identity that is not represented in asset inventory, identity governance, access review, or ownership records.

This configuration creates an elevated exposure condition because defenders may not know the identity exists, what it can access, who owns it, or which synthetic subject uses it. Without inventory coverage, the identity may fall outside monitoring, recertification, rotation, and decommissioning processes.

The primary risk is invisible authority. An uninventoried identity may continue accessing systems, retrieving data, or calling tools without being assessed as part of the organization’s synthetic subject risk surface.

Investigators should review identity provider records, cloud accounts, service principals, connector inventories, agent manifests, vendor integrations, authentication logs, and asset discovery outputs. Particular attention should be given to identities with no owner, no linked application, no documented purpose, or no access review history.

Investigative Relevance

Uninventoried agent identities are relevant because unknown identities cannot be reliably governed or contained. This sub-section is especially relevant where teams create experimental agents, vendor integrations, local automation, or Model Context Protocol (MCP) servers outside central identity processes.

Unapproved connected tool occurs when a synthetic subject is configured to use a plugin, connector, function, application programming interface, or Model Context Protocol (MCP) server that has not been reviewed, approved, or inventoried.

This configuration creates an elevated exposure condition because an unapproved tool may introduce unknown permissions, data access, runtime behavior, supplier dependencies, or outbound destinations. The synthetic subject may treat the tool as trusted even though the organization has not assessed its provenance or purpose.

The primary risk is uncontrolled extension of capability. A single unapproved tool may allow the synthetic subject to retrieve data, send messages, call external services, or perform actions outside the intended design.

Investigators should review connected tool inventories, MCP server lists, configuration files, package manifests, marketplace installs, connector approvals, and tool-call logs. Particular attention should be given to tools installed outside approved channels or tools that do not appear in asset or vendor inventories.

Investigative Relevance

Unapproved connected tools are relevant because they expand what a synthetic subject can do without governance visibility. This sub-section is especially relevant where teams can install marketplace tools, local MCP servers, plugins, or connectors without central approval.

Impersonating tool package occurs when a connected tool, plugin, package, or Model Context Protocol (MCP) server presents itself as a trusted integration while being operated, published, or modified by an unauthorized or malicious supplier.

This configuration creates an elevated exposure condition because the synthetic subject and the deploying team may trust the tool based on its name, description, repository appearance, or apparent relationship to a legitimate service.

The primary risk is supplier impersonation. An impersonating package may receive sensitive inputs, send messages, call APIs, or exfiltrate data while appearing to be an approved or official tool.

Investigators should review package names, publishers, repository ownership, signatures, download sources, version history, dependency changes, marketplace records, and tool-call logs. Particular attention should be given to lookalike names, recently transferred ownership, sudden behavior changes, and tools that mimic official vendor integrations.

Investigative Relevance

Impersonating tool packages are relevant because synthetic subjects may use third-party tools with high trust and high permissions. This sub-section is especially relevant where agents rely on public package registries, marketplace listings, MCP servers, or community-maintained connectors.

A third-party tool agent platform is a standalone artificial intelligence agent platform connected to external tools through marketplaces, plugins, connectors, or Model Context Protocol (MCP) servers. MCP servers provide a standardized way for agents to access external tools, data sources, and actions. Each connected tool may allow the agent to read data or perform actions such as sending email, calling application programming interfaces (APIs), updating records, or retrieving files.

This deployment pattern creates an elevated exposure condition because every added tool becomes another supplier in the trust chain. The organization may approve the agent platform, but each marketplace tool, connector, or MCP server introduces its own permissions, update path, dependencies, and operator.

The primary risk is tool-mediated compromise. A connected tool may become malicious through a silent update, impersonating package, compromised dependency, weak marketplace review, or supplier compromise. Once connected, the tool may act through the agent’s authority and access organizational data or systems on the agent’s behalf.

A related risk is attribution failure. Harmful activity may appear to originate from the agent platform, while the actual cause sits inside a specific tool, connector, package, or MCP server. If logs do not preserve tool-level provenance, investigators may be unable to determine which supplier component read the data, sent the message, called the API, or caused the adverse outcome.

Investigators should review the agent platform’s directive, installed tools, marketplace sources, MCP servers, connector permissions, package provenance, update history, tool-call logs, outbound destinations, and vendor audit records. Particular attention should be given to newly added tools, recently updated packages, impersonating names, unexpected email or API actions, and cases where activity cannot be attributed to a specific connected tool.

Investigative Relevance

Third-party tool agent platforms are relevant because they extend organizational trust beyond the agent vendor to every connected tool in the platform ecosystem. A tool added for convenience may become a separate operational actor with access to sensitive data and action capability.

This sub-section is especially relevant where a standalone agent platform can install marketplace tools, connect to MCP servers, send mail, call APIs, read documents, access customer data, update SaaS records, or execute workflow actions through third-party integrations.