Insider Threat Matrix™Insider Threat Matrix™
HumanSynthetic
Detections
Preventions
Github

Connected Tools and Functions

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.

Subsections (7)

ID Name Description
CF002.002Changed Tool Definition

Changed tool definition occurs when a connected tool’s name, description, schema, parameters, permissions, or server definition changes after approval. This may occur through a vendor update, package update, configuration change, or replacement Model Context Protocol (MCP) server.

 

This configuration creates an elevated exposure condition because synthetic subjects rely on tool definitions to decide when and how to use tools. A changed description or schema may alter tool selection, input handling, output routing, or the apparent purpose of the tool.

 

The primary risk is post-approval behavior drift. A tool approved for one purpose may later behave differently, request different inputs, expose new actions, or direct the synthetic subject toward unsafe use without a full review.

 

Investigators should review tool definition history, package versions, MCP server manifests, approval records, schema changes, descriptions, parameters, and tool-call patterns before and after the change. Particular attention should be given to changed descriptions, added parameters, new external destinations, and tools that changed without re-approval.

 

Investigative Relevance

Changed tool definitions are relevant because tool behavior can shift after the organization has accepted the integration. This sub-section is especially relevant where connected tools update automatically, use remote schemas, or depend on vendor-managed metadata.

CF002.004Impersonating Tool Package

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.

CF002.005Over-Permissive Tool Runtime

Over-permissive tool runtime occurs when a connected tool runs with broader file, network, credential, system, or environment access than required for its approved function.

 

This configuration creates an elevated exposure condition because a tool called by the synthetic subject may access resources beyond the data explicitly passed to it. It may read local files, environment variables, credentials, network services, logs, or system resources available to the runtime.

 

The primary risk is hidden tool-side access. Even if the synthetic subject appears narrowly scoped, the tool it calls may have broader runtime permissions and can retrieve, modify, or transmit data outside the intended tool function.

 

Investigators should review runtime permissions, container settings, environment variables, mounted files, network access, local secrets, execution logs, and tool behavior. Particular attention should be given to tools with access to home directories, secret stores, internal networks, unrestricted outbound connectivity, or shared execution environments.

 

Investigative Relevance

Over-permissive tool runtimes are relevant because tool execution environments can expand synthetic subject capability beyond visible tool descriptions. This sub-section is especially relevant where tools run on developer workstations, shared servers, CI/CD workers, agent runtimes, or cloud functions with broad local or network access.

CF002.003Poisoned Tool Description

Poisoned tool description occurs when a connected tool’s description, metadata, schema, or usage instructions contain hidden or adversarial instructions that influence the synthetic subject. These instructions may be visible to the model during tool selection but hidden, truncated, or unclear to the human reviewer.

 

This configuration creates an elevated exposure condition because tool descriptions are not passive documentation. They may enter the model’s context and affect which tool is selected, what data is passed to it, and how the synthetic subject behaves before or after the call.

 

The primary risk is metadata-driven manipulation. A synthetic subject may disclose secrets, call unsafe tools, pass sensitive data, or perform unauthorized actions because the tool description instructs it to do so.

 

Investigators should review tool descriptions, metadata, schemas, client display behavior, hidden text, encoded content, prompt-like language, and tool-call logs. Particular attention should be given to descriptions containing instructions to ignore rules, access sensitive files, forward data, or prefer one tool over another.

 

Investigative Relevance

Poisoned tool descriptions are relevant because the attack surface may sit in tool metadata rather than user prompts or tool code. This sub-section is especially relevant where tools are installed from marketplaces, open registries, third-party repositories, or MCP servers managed outside the organization.

CF002.001Unapproved Connected Tool

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.

CF002.006Unattributed Tool Call

Unattributed tool call occurs when a synthetic subject invokes a tool without logs that clearly preserve the tool name, arguments, result, invoking synthetic subject, non-human identity, human invoker, and downstream action.

 

This configuration creates an elevated exposure condition because investigators may see only the final system change, not the tool call that caused it. The action may appear to originate from a service account, host application, or employee rather than a specific tool invocation.

 

The primary risk is loss of reconstructable evidence. Without immutable tool-call logging, investigators may be unable to determine what the synthetic subject requested, what the tool returned, what data was exposed, or whether the action matched an approved directive.

 

Investigators should review tool-call logs, application logs, agent traces, audit trails, non-human identity records, request identifiers, and downstream system events. Particular attention should be given to missing arguments, missing results, overwritten logs, shared service identities, and actions that cannot be tied to a specific tool call.

 

Investigative Relevance

Unattributed tool calls are relevant because tool use is often where synthetic subject behavior becomes operational action. This sub-section is especially relevant where agents call APIs, send messages, write records, execute commands, or interact with external services.

CF002.007Unrestricted Tool Egress

Unrestricted tool egress occurs when a connected tool or tool runtime can send data to external destinations without destination allowlisting, network control, or policy enforcement.

 

This configuration creates an elevated exposure condition because a tool may transmit data outside the organization through email, web requests, file uploads, webhooks, application programming interface calls, or hidden copy mechanisms such as blind carbon copy.

 

The primary risk is tool-mediated exfiltration. A synthetic subject may call an apparently legitimate tool, while the tool or its runtime sends data to an unauthorized destination. This may occur through malicious tool logic, compromised packages, unsafe configuration, or hidden forwarding behavior.

 

Investigators should review web proxy logs, egress records, email headers, tool runtime network activity, webhook destinations, API endpoints, and tool-call outputs. Particular attention should be given to newly observed domains, non-allowlisted destinations, blind-copy behavior, unexpected external calls, and data transfers following tool invocation.

 

Investigative Relevance

Unrestricted tool egress is relevant because connected tools can create outbound paths that are not visible in the synthetic subject’s own prompt or response logs. This sub-section is especially relevant where tools send email, call external APIs, upload files, retrieve URLs, or operate from runtimes with broad internet access.