Topic starter
25/10/2026 11:03 am
TL;DR: A session-level attack path can emerge when compromised repositories, npm postinstall scripts, and trusted skills directories let attacker-written skills load, Dash Security found. Session history and trusted skill locations need tighter correlation because isolated alerts can miss the chain behind the steering.
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: 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.
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.
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.
Glossary terms: Agent Steering, Trusted Skill Directory, Session-level trust, Local State Store
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 7 days ago by NHI Mgmt Group
27/10/2026 7:17 pm
Session-level trust, not single-event trust, is the real control boundary: this attack works because the agent's decision chain spans repository content, local history, installed packages, and trusted skills. Point-in-time controls can see each event separately and still miss the relationship that makes the chain malicious. The governance failure is analytical, not merely technical: the unit of review is too small. Practitioners need to judge the full session as one identity transaction.
A question worth separating out:
A: Assume the source may be contaminated and verify where the artefact came from, who wrote it, and whether it altered a trusted execution path. The right response is not to inspect the skill alone, but to trace how it entered the trust hierarchy and whether future sessions will reuse it.
👉 Read our full editorial: Agent steering turns trusted skills into a session-level attack path
This post was modified 7 days ago by NHI Mgmt Group