Hoplite Labs

Abstract: Modern IT stacks rely heavily on third-party tools with opaque data flows. This post explains how AI integrations change vendor risk and which due diligence questions actually matter. It is written for legal, procurement, and risk stakeholders as much as technical teams.

—

Modern environments already rely heavily on third-party tools. Email, ticketing, document storage, CRM, and identity systems all connect and operate together.

Over time, those integrations become part of the environment. They are trusted because they have been in place for years.

Then, a familiar vendor introduces a new AI feature. It promises better search, faster summaries, or automated drafting. It can be enabled with a setting or a license change.

Nothing else changes. No new onboarding process or architecture review. No change to how the system is understood.

The system keeps functioning. What changes is how it behaves.

The question is no longer what the system was assumed to do. It is what it can do now.

Why the Safety Assumption is Reasonable

Teams assume the feature operates within the same boundaries as the rest of the platform. The system has already been established. Access has been granted. Nothing has broken. From the outside, it seems like an upgrade. 

That assumption is reasonable. Most environments are not rebuilt every time a capability changes. 

But that understanding is anchored to how the system behaved at an earlier point in time. It does not account for how new functionality changes what the system can access, how it retrieves data, or which identities it operates under.

When Capability Expands, the Data Path Changes

AI-enabled features introduce new runtime behaviors:

• A search function may now query additional services behind the scenes.

• A drafting tool may read across multiple internal repositories using an existing service account.

• A summarization feature may process data that was previously never aggregated.

These changes are not visible in the interface. They occur in how the system retrieves and moves data.

When a feature is enabled, the system can often reach data and systems it could not before. This happens using identities that already have access.

From an attacker’s perspective, the question is simple: What can this system now reach?

Where Real Environments Diverge from Expectations

Systems are understood at a point in time. Environments evolve continuously:

• Features are released incrementally. 

• Permissions expand. 

• Integrations accumulate because they make teams more efficient.

None of these changes stand out as a meaningful shift.

Over time, the system behaves differently than it did when it was originally evaluated. Documentation may still reflect an earlier version of the environment.

That gap defines where systems behave differently than expected — and where attackers find leverage.

Monitoring Does Not Scale Automatically

Most environments establish visibility when a system is first deployed. Access pathways are understood. Logging exists.

Less common is sustained visibility into how that system behaves after enabling new features. Ponemon Institute research suggests many organizations do not actively monitor third-party access, often citing trust in vendor controls or limited internal resources.

AI-enabled features introduce additional system-to-system activity, often through APIs and automated requests that were not part of the original design. If monitoring does not expand alongside that activity, teams lose clarity on how data is actually being accessed. From an attacker’s point of view, reduced visibility creates room to operate without detection.

Identity Expansion Through Automation

Modern environments run on non-human identities. Service accounts and API credentials connect systems across the stack. Industry research from CyberArk shows machine identities can outnumber human users by as much as 82 to 1. AI functionality typically operates through those same identities.

System access using those identities is often broader than intended to ensure the feature works across different workflows. Over time, permissions expand faster than they are reviewed. Service accounts persist. Ownership becomes unclear.

When a new AI feature is enabled, it inherits that structure. In overly permissive environments, that functionality can expose data never meant to be broadly reachable.

Feature Velocity Expands the Attack Surface

New AI capabilities are introduced within systems that are already trusted.

McKinsey’s 2025 research finds that 71% of organizations report using generative AI in at least one business function. In many environments, those capabilities are embedded directly into existing tools and enabled incrementally, without revisiting how systems behave at runtime.

Individually, these changes appear small. Collectively, they alter how data moves, how access is used, and how systems interact across the environment.

Attackers do not evaluate features in isolation. They assess what the system can do now and where that creates new attack paths.

How Mature Teams Handle AI Integrations

Mature teams treat AI functionality as a change in system behavior. A feature toggle may look incremental, but it can introduce new data paths, identities, and access patterns that need to be understood.

They focus on how the system behaves in practice — what it can access, how it moves data, and whether that activity is visible.

In practice, this means reviewing configurations for inherited permissions, evaluating identity scope, confirming that logging captures actual activity, and testing how the integration behaves under pressure.

The goal is not to document the feature but to understand what the system can do now.

When Capability Grows, Exposure Changes

AI integrations do not introduce a new risk category. They change how existing systems behave.

Data may move further. Identities may reach wider. Activity may become harder to observe. 

Exposure emerges when capability expands without a corresponding update in validation.

Disciplined teams recognize that shift. When functionality changes, they reassess assumptions and validate how access, monitoring, and system behavior actually operate.

That work is rarely urgent. It is deliberate. And it is what separates awareness from control.

Recent Supply Chain Incidents

Over the past few weeks, several supply chain incidents have reinforced how quickly risk can propagate through trusted tools:

• Trivy pushed a routine update to a widely used security tool, introducing compromised code into client environments without any change in how teams had approved or deployed it.

• LiteLLM released new versions of its AI integration library that included backdoored functionality, expanding what the tool could access without any new review from the organizations using it.

• Axios had a malicious update injected into a trusted package—turning a standard dependency update into a remote access pathway.

In each case, the risk emerged within tools that were already trusted and integrated into existing environments. The gap between what’s documented and what’s actually happening continues to widen and attackers are taking advantage of it.

—

If you are unsure what new AI functionality allows within your environment — what it can access, how it moves data, and what it exposes — validate how it behaves under real-world conditions.