NHI and Agentic Risk: Third-Party Tools

Sixth post in the NHI and Agentic Risk series — extending it because we kept running into this gap. Every third-party tool an agent calls runs someone else’s code with your credentials.

An agent’s tool registry includes a data-formatting utility maintained by an open-source contributor. A routine update pulls a compromised transitive dependency. The agent calls the tool with a database connection string in scope. The tool works normally — and exfiltrates the connection string to an external endpoint. The incident report says “agent data exfiltration.” The root cause is a supply chain compromise in a tool the agent trusted because it was in the registry.

The OWASP Overlap

NHI3 (vulnerable third-party NHI) maps to ASI04 (supply chain vulnerabilities) and ASI02 (tool misuse). Series 01 flagged NHI1 as the supply chain parallel — stale identities behaving like forgotten dependencies. NHI3 is the more direct vector. The tool itself is the compromised entry point, and the agent’s credentials are the payload.

How Trust Transits

Trust in agent tool chains is a point-in-time decision applied to a runtime problem. A team approves a tool at a specific version, against a known threat model. The agent invokes it later — possibly updated, in a context the approver never anticipated. The approval goes stale the moment it’s granted.

Four failure modes show up repeatedly:

• Tool registries and marketplaces. MCP servers, agent tool catalogs. Low barrier to publish. Sparse review. A compromised tool looks identical to a legitimate one in the registry listing.
• OAuth integrations. SaaS tools granted broad scopes at initial setup. The scope outlives the original reason. When the SaaS provider is breached, those scopes become the attacker’s permissions.
• Transitive dependencies. A tool depends on a library that depends on a library. Compromise anywhere in that chain reaches the agent’s execution context.
• Dynamic tool discovery. Agents select tools by matching descriptions to task requirements. Descriptions are self-reported trust signals with no verification that the tool does only what it claims.

What Makes Agents Different

This isn’t the traditional supply chain problem rebranded. Agents change the dynamics in ways that matter:

• Runtime selection. Agents pick tools per task, not per deployment. The attack surface shifts with every invocation.
• Automatic composition. A developer chains 3 tools knowingly. An agent chains 12 based on task planning, with no human reviewing the sequence.
• Description poisoning. Tool descriptions influence which tool gets selected. A malicious tool with the right description beats a legitimate one with the wrong one.
• No drift detection. A tool that starts making unexpected network calls or returning subtly altered data goes unnoticed. The agent evaluates results for task completion, not integrity.

The CSA NHI survey data puts numbers on the baseline:

These numbers reflect traditional integrations. Agent tool ecosystems — where invocation is dynamic, frequent, and automated — are less measured and less mature.

Where It’s Already Happened

The mechanisms are proven. The agent context just hasn’t caught up to the incident reports yet:

• Salesloft/Drift (2025). An attacker abused OAuth tokens tied to Salesloft’s Drift chat integration to pull data from customers’ Salesforce instances. The stolen records were then mined for cloud credentials — AWS keys, Snowflake tokens — creating lateral movement paths the original OAuth scope was never meant to enable. (GTIG report)
• VSCode marketplace extensions. A batch of extensions — collectively installed tens of thousands of times — were caught exfiltrating developer credentials and personal data while providing plausible IDE functionality. They had access to source code, environment variables, and anything else the IDE could reach. (Checkpoint)
• Sisense (2024). Database credentials shared with a third-party BI provider were compromised when the provider was breached. (Analysis)
• JetBrains GitHub plugin. A security issue in IntelliJ-based IDEs exposed repository credentials through the GitHub plugin. (JetBrains advisory)

Every one of these involved a third-party integration that was trusted, then compromised. Scale the invocation frequency from “developer clicks a button” to “agent calls the tool 200 times a day” and the exposure math changes.

Controls

1. Pin tool versions. Verify integrity — checksums, signatures — before every invocation, not just at install time.
2. Scope credentials per tool. Each tool gets its own NHI. Never share the agent’s primary identity across tools. Rotate and revoke independently.
3. Monitor tool behavior. Baseline network calls, response patterns, latency. Alert on drift.
4. Require attestation for tool updates. Signed releases. Verified publishers. Diff the update before promoting.
5. Default-deny for new tools. Explicit approval workflow before an agent can invoke a tool it hasn’t used before.
6. Treat tool selection as a security decision. The tool an agent picks determines whose code runs with your credentials.

What This Doesn’t Solve

Pinning versions creates maintenance burden and can leave you running known-vulnerable code. Behavioral monitoring needs baselines that take time to build and generates false positives during legitimate updates. Attestation doesn’t prevent a trusted publisher from being compromised — that’s the SolarWinds lesson. None of these controls help if the tool was already compromised at first approval.

The hardest tension: locking down dynamic tool discovery directly reduces agent capability. An agent restricted to pre-approved tools is safer and less useful. That tradeoff is real, and pretending otherwise doesn’t help.

Practical Takeaways

1. Inventory every third-party tool your agents can invoke. If you can’t list them, you can’t secure them.
2. Assign each tool its own scoped NHI. Rotate independently. Revoke independently.
3. Pin tool versions in production. Diff updates before promoting.
4. Log every tool invocation with the identity used, the tool version, and a response hash.
5. Run supply chain scanning on tool dependencies, not just your own application code.
6. Simulate a compromised tool. If there’s no response playbook, write one before you need it.

The agent isn’t the vulnerability. The tool chain is. Third-party NHI risk existed before agents — agents made it operational at machine speed with no human reviewing each call. If your tool registry doesn’t carry the same rigor as your dependency management, the next incident starts there.

Previous posts in this series: How Compromise Happens, Least Privilege Meets Least Agency, Secrets, Memory, and Persistence, Blast Radius Engineering, When Humans Use Machine Credentials.