Agent steering: what security teams miss when trust becomes weaponised

TL;DR: An attacker can use a compromised repository, an npm postinstall script, and a trusted skills directory to steer an agent into executing a custom malicious skill built from local VSCDB context, according to Dash Security research. The key problem is not one bad event but a session-level trust chain that ordinary point-in-time detection is poorly suited to evaluate.

Editorial analysis by NHI Mgmt Group, based on content published by Dash Security: “Agent Steering: When the Attacker Uses Your Agent Against You Part 2”.

Key questions

Q: What breaks when an AI agent can trust skills written by unvetted code?

A: The trust boundary breaks because the agent starts treating attacker-shaped instructions as legitimate workflow artefacts.

Q: Why do agent steering attacks evade ordinary security monitoring?

A: They evade it because each step can look routine on its own.

Q: How should teams govern local history and cached context for AI agents?

A: Treat them as sensitive identity evidence, not disposable telemetry.

Practitioner guidance

• Constrain repository provenance before agent execution Require provenance checks for cloned repositories and block agent execution on unvetted dependency trees until the source and package chain have been reviewed.
• Broker access to local agent history Separate conversation history and cached context from generic user-level code so that a package cannot read the session data the agent uses to shape decisions.
• Protect trusted skill locations as privileged surfaces Limit which processes can write to skill directories and add explicit review for any new skill source before the agent is allowed to load it.

Bottom line: Agent steering is dangerous because it weaponizes the trust relationships around an AI agent, not just the code it is asked to run.

Explore further

View Full Forum →  |  NHI Foundation Course →  |  Our Services →  |  Read the full analysis →