Network Segmentation

A subject conducts a scan of a network to identify additional systems, or services running on those systems.

An organization entrusts a Managed Service Provider (MSP) with administrative or operational access to its digital environment - typically for IT support, system maintenance, or development functions. This access is often persistent, privileged, and spans sensitive infrastructure or data environments.

The means is established when MSP personnel, including potential subjects, are permitted to authenticate into the client’s environment from systems or networks entirely outside the client's visibility or jurisdiction. These MSP endpoints may be unmanaged, unmonitored, or physically located in regions where customer organization's policies, incident response authority, or legal recourse do not apply.

This creates an unobservable access channel: the subject operates from infrastructure beyond the reach of the customer organization's logging, endpoint detection, or identity correlation. The organization is therefore unable to monitor or verify who accessed what, when, or from where—rendering all downstream actions unauditable by the customer organization's internal security teams, unless mirrored within the client-controlled environment.

The exposure can be compounded by the MSP’s internal controls (or lack thereof). Weak credential custody practices, shared administrative accounts, inadequate background checks, or poor workforce segmentation create conditions where privileged misuse or unauthorized access can occur without attribution or immediate detection. The subject does not require escalation—they begin with sanctioned access and operate under delegated trust, often without the constraints applied to internal staff.

This structural dependency - privileged access held externally, without enforceable oversight - creates the necessary conditions for an insider infringement to occur with low risk of interruption or accountability.

A subject deploys a hardware-based remote access device, typically an IP-KVM (Keyboard, Video, Mouse over IP) system, to remotely interact with a workstation or server through its physical interfaces.

These devices connect directly to the system’s video output (HDMI or DisplayPort) and USB ports, capturing the display signal while injecting keyboard and mouse input remotely. The device presents itself to the operating system as standard USB Human Interface Devices (HID), such as a generic keyboard and mouse, allowing the subject to interact with the system as though physically present at the console.

Because the interaction occurs through physical interface emulation rather than installed software, activity generated through the device appears as local console input to the operating system. This can bypass controls designed to detect or restrict software-based remote access tools such as Remote Desktop Protocol (RDP) or third-party remote administration platforms.

Many IP-KVM devices provide independent network connectivity, including Ethernet, Wi-Fi, or cellular access, allowing the subject to maintain remote interaction with the system through an external management interface. When used in this manner, the remote session may not traverse corporate remote access infrastructure or generate conventional remote access/network logs.

While these devices have legitimate uses in system administration, hardware labs, and data center environments, a subject may deploy them covertly to maintain persistent remote access to a system without installing software or triggering typical remote access monitoring or network controls.

Within the Insider Threat Matrix, this behavior represents preparatory activity, as it establishes a covert remote control capability that may later enable unauthorized access, data exfiltration, or system manipulation.

A subject operates within an environment where artificial intelligence (AI) platforms or agents are integrated across multiple enterprise systems, providing centralized access to data, services, or functionality within the organization.

These platforms are typically deployed to support productivity, knowledge retrieval, automation, or decision-making. As part of their implementation, they may be connected to internal repositories, collaboration tools, identity systems, ticketing platforms, or other business-critical services. Integration is often achieved through APIs, service accounts, or enterprise-wide indexing capabilities.

As a result, the AI platform may provide:

• Access to data across multiple repositories through a unified interface.
• The ability to query, summarize, or retrieve information spanning different business functions.
• Integration with systems that enable interaction with internal services or workflows.
• Persistent access to organizational data or systems through configured permissions.

This form of integration creates a consolidated access layer within the environment that differs from standard user interaction patterns. Rather than accessing systems individually, the subject may interact with multiple data sources or services through the AI platform.

In some cases, the scope of access available through the platform may not align precisely with role-based access expectations, particularly where data is aggregated, summarized, or retrieved across systems. The platform may also operate with service account permissions or API-level access that are not directly accessible to the subject through traditional interfaces or individual user access controls, creating a divergence between user-level access and effective access via the platform.

This Section captures the availability of AI platforms that are integrated into the enterprise environment with broad access to data or systems. While deployed for legitimate operational purposes, such platforms may provide expanded capability that can be leveraged by a subject in the course of insider activity.

A subject with access to sensitive organizational data possesses the ability to view, retrieve, or manipulate information that is internally critical to the functioning, competitiveness, or integrity of the organization. This may include proprietary intellectual property, financial forecasts, internal audit reports, legal proceedings, incident investigation records, M&A materials, or internal threat detection logic. Access to such data is typically granted to personnel in roles including but not limited to finance, legal, security, compliance, research and development, or executive support functions.

While this data may not include customer information, its sensitivity is often equal or greater—particularly when tied to strategic decision-making, regulatory posture, or institutional trust. Misuse of access to sensitive organizational data can result in reputational harm, regulatory breach, loss of competitive advantage, or compromise of security functions. Because this access is frequently held by high-trust individuals or senior personnel, abuses may be harder to detect and more consequential in impact.

Unmonitored access to such data—particularly when permissions are inherited, overly broad, or poorly reviewed—can significantly elevate a subject's risk profile. This access may also attract external interest, such as social engineering attempts or recruitment by adversarial entities, making the subject a potential vector for external compromise.

Subjects with access to production and pre-production environments—whether as users, developers, or administrators—hold the potential to exploit or compromise highly sensitive organizational assets. Production environments, which host live applications and databases, are critical to business operations and often contain real-time data, including proprietary business information and personally identifiable information (PII). A subject with access to these systems can manipulate operational processes, exfiltrate sensitive data, introduce malicious code, or degrade system performance.

Pre-production environments, used for testing, staging, and development, often replicate production systems, though they may contain anonymized or less protected data. Despite this, pre-production environments can still house sensitive configurations, APIs, and testing data that can be exploited. A subject with access to these environments may uncover system vulnerabilities, access sensitive credentials, or introduce code that could be escalated into the production environment.

In both environments, privileged access provides a direct pathway to the underlying infrastructure, system configurations, logs, and application code. For example, administrative access allows manipulation of security policies, user permissions, and system-level access controls. Similarly, access to development environments can provide insights into source code, configuration management, and test data—all of which could be leveraged to further insider activity.

Subjects with privileged access to critical environments are positioned not only to exploit system vulnerabilities or bypass security controls but also to become targets for recruitment by external actors seeking unauthorized access to sensitive information. These individuals may be approached or coerced to intentionally compromise the environment, escalate privileges, or exfiltrate data on behalf of malicious third parties.

Given the sensitivity of these environments, subjects with privileged access represent a significant insider threat to the integrity of the organization's systems and data. Their position allows them to manipulate or exfiltrate sensitive information, either independently or in collaboration with external actors. The risk is further amplified as these individuals may be vulnerable to recruitment or coercion, making them potential participants in malicious activities that compromise organizational security. As insiders, their knowledge and access make them a critical point of concern for both data protection and operational security.

The subject intentionally weakens or bypasses network security controls for a third party, such as providing credentials or disabling security controls.

A subject has access to an artificial intelligence (AI) platform that aggregates data from multiple internal systems and presents it through a unified interface, where access controls are insufficiently enforced or misaligned with underlying role-based access restrictions.

These platforms are typically configured to index, query, or retrieve information from enterprise repositories such as file storage systems, collaboration platforms, knowledge bases, and internal documentation systems. Data from these sources may be combined, summarized, or surfaced in response to a single query.

In some implementations, the platform aggregates data across repositories without consistently applying the access controls of the underlying systems. As a result, information may be surfaced through the AI interface that the subject would not ordinarily access through direct interaction with those systems.

The AI platform may provide:

• Cross-repository search and retrieval spanning multiple data sources.
• Summarized or consolidated outputs derived from restricted or segmented repositories.
• Correlation of information across business functions or sensitivity domains.
• Visibility into data that is not directly accessible through standard user interfaces.

This access model creates a divergence between the subject’s direct access permissions and the information available to them through the AI platform. Data that is distributed, restricted, or contextually separated within underlying systems may be surfaced together through aggregated queries.

The presence of aggregated data access with insufficiently constrained access controls provides the subject with a means to obtain information beyond their intended role-based scope, particularly where enterprise-wide indexing or broad query capabilities are implemented.

A subject has access to an artificial intelligence (AI) platform that is integrated with internal systems and capable of interacting with those systems through APIs, service accounts, automation frameworks, or agent interaction protocols (e.g., Model Context Protocol (MCP)), where the platform operates with permissions or capabilities that exceed typical user-level access controls.

These platforms are connected to enterprise systems such as identity services, ticketing platforms, communication tools, file storage systems, and other operational applications. Integration enables the platform to execute actions, retrieve data, or interact with system functionality on behalf of the user.

In some implementations, the platform is granted broad or persistent permissions to support automation and cross-system functionality. These permissions may not align precisely with the subject’s role-based access and may allow the platform to perform actions or retrieve data beyond what the subject could achieve through direct interaction with the underlying systems.

The AI platform may:

• Execute actions against internal systems through API integrations.
• Operate using service accounts with elevated or persistent privileges.
• Trigger workflows or automation processes across multiple systems.
• Interact with system functionality outside standard user interfaces.
• Perform actions or retrieve data using permissions not directly available to the subject.

This interaction model creates a divergence between the subject’s direct capabilities and the effective capabilities available through the AI platform. Actions that would normally require elevated access, multi-system coordination, or additional authorization may be performed through the platform’s integrated functionality.

The presence of AI platforms with system interaction capability and insufficiently constrained permissions provides the subject with a means to interact with internal systems and services beyond their intended role-based authority.