Agent steering turns trusted skills into a session-level attack path

At a glance

What this is: This is an analysis of agent steering, showing how a malicious repository, local conversation history, and trusted skills can be chained into a stealthy attack on coding agents.

Why it matters: It matters because identity and access controls built for individual files or prompts miss the cumulative trust boundary that an agent crosses across a full session.

Context

Agent steering is an attack pattern in which an adversary shapes an AI agent's decisions by planting context that looks legitimate to the model and to the human reviewer. The governance problem is that the agent's trust decisions are now influenced by prior session state, local files, and tool outputs that classic IAM and endpoint controls do not evaluate together.

In this case, the attacker used a compromised repository on a developer endpoint, then relied on the agent reading local state, loading packages, and trusting a skill written back into a privileged location. The security gap is not a single malicious command, but a workflow in which the agent treats attacker-influenced artefacts as ordinary work products.

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. A malicious writer does not need to win every prompt. It only needs to place a trusted instruction source into a location the agent will load later, which turns one compromise into persistent steering across sessions.

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

A: They evade it because each step can look routine on its own. A repository is cloned, a local file is read, a package runs, and a skill loads. The maliciousness appears only when those actions are correlated as one session-level chain that reshapes the agent's future behaviour.

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

A: Treat them as sensitive identity evidence, not disposable telemetry. If a package or plugin can read prompts, responses, secrets, and workflow details, it can build a highly targeted payload. Access should be minimized, brokered, and logged like any other privileged data path.

Q: What should security teams do when a skill or plugin appears legitimate but comes from a suspicious source?

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.

Technical breakdown

How a malicious repository becomes an agent trust primitive

The first mechanism is delivery through code that the agent is expected to inspect and run. A repository can carry a postinstall script or dependency payload that looks like ordinary development work, especially when the agent is already acting as a coding assistant inside the workflow. The attack succeeds when the repository content is not judged in isolation, but in the context of a real task the developer would plausibly ask for. That context makes suspicious behaviour harder to separate from normal build activity, and it gives the payload repeated execution opportunities whenever dependencies are installed or updated. Practical implication: treat repository provenance and dependency execution as part of the agent's identity boundary, not just as code hygiene.

Practical implication: verify repository provenance and restrict dependency execution before an agent is allowed to act on cloned code.

Why local agent history is such a powerful reconnaissance source

The second mechanism is reconnaissance against the agent's local state store, such as conversation history and workspace artefacts. That store captures prompts, responses, references to secrets, and the shape of the work the developer is doing. A malicious package that can read it does not need to guess what the victim is building, because the session history reveals it. This is materially different from ordinary file theft: the attacker is mining the agent's own trust context to craft a payload that blends into the current workflow. Practical implication: isolate or tightly broker access to agent history and cached context, because that material can be used to tailor the next stage of the attack. See the Agentic AI Identity Guide.

Practical implication: segregate agent session history from user-level code that does not need to read it.

How a trusted skill directory turns context theft into persistent steering

The third mechanism is write-back into a location the agent already trusts, such as a skills directory. Once the payload writes a custom skill there, the agent is no longer evaluating a random file. It is evaluating a local artefact inside its own trust hierarchy, and that changes the default response from caution to compliance. The important failure mode is that trust is being transferred from the agent's own task context to attacker-shaped instructions without a new authorisation event. The result is persistence across sessions, because the malicious skill can be loaded again in future work. Practical implication: govern skill registration and trusted locations as privileged identity surfaces, not as ordinary developer files. See the Agentic AI Security Guide.

Practical implication: control which processes can write into trusted skill locations and review every new skill source.

Threat narrative

Attacker objective: The attacker wants the agent to execute instructions that serve the adversary's goals while appearing to be normal developer assistance.

1. Entry begins with a compromised or unvetted repository on a developer endpoint, allowing attacker-controlled code to reach the agent's normal workflow.
2. Credential-harvested context comes from reading the local VSCDB, where prompts, responses, secrets, and project details are stored in user-readable form.
3. Escalation occurs when the harvested context is used to synthesize a custom skill and write it into a trusted skills location the agent will later load.
4. Impact follows when future agent sessions accept the planted skill as legitimate guidance and carry out attacker-shaped actions inside the developer workflow.

Breaches seen in the wild

• Firebase misconfiguration exposure 2024: Missing Firebase security rules on 916 websites exposed 125 million user records and 19.87 million plaintext passwords; a quarter were fixed.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Agent history is now identity evidence: the local store is not just telemetry. It contains the prompts, secrets, and workflow context that let an attacker tailor a payload so precisely that even a suspicious reviewer can struggle to distinguish it from a legitimate convention. That makes session history a high-value governance object, not a convenience cache. Agentic AI Identity Guide belongs in any programme that allows agents to reuse local context across tasks.

Trusted skill locations have become privileged writing surfaces: when an attacker can write a skill into a location the agent already treats as trusted, they bypass the normal skepticism applied to ordinary files. The control gap is not merely code execution, but trust inheritance without fresh authorisation. This is the same problem class as any privileged configuration surface that can alter future behaviour without re-validation.

Code-reviewable attacks still outpace code-review mental models: the article's Rice's theorem point matters because it shows why perfect static inspection is impossible for this class of attack. If the malicious behaviour depends on runtime context, imported packages, or session state not fully available at analysis time, then the defender cannot rely on reading code alone. That forces governance to move from artefact review to runtime and session governance.

Agent steering is the agentic equivalent of supply-chain trust poisoning: the planted skill does not merely exploit a bug in one component. It contaminates the trust hierarchy the agent uses to decide what is safe to follow. That is why agentic programmes need to treat context injection, local state access, and trusted artefact registration as one problem, not three separate ones.

Read next: Agentic AI Identity Guide

What this signals

Trusted artefact registration is becoming a new identity control point: programmes that already govern credentials, secrets, and privileged accounts now need the same discipline for agent skills and plugins. The important question is not whether the file is executable, but whether it can alter future agent behaviour without fresh validation. That shifts policy from event review to lifecycle governance.

Session history will become a primary investigation source for agentic environments because it captures the context an attacker needs to craft believable steering payloads. Security teams should expect the most effective attacks to look like normal work until the full chain is reconstructed. The practical response is to align logging, sandboxing, and trusted-location governance so that session state is both least-privileged and reviewable.

For practitioners

• 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.
• Evaluate detections at the session level Correlate repository access, local database reads, file writes, and later skill loading as one chain, because none of those events is sufficiently malicious in isolation.

Key takeaways

• Agent steering is dangerous because it weaponizes the trust relationships around an AI agent, not just the code it is asked to run.
• The attack chain in this article depends on repository provenance, local session history, and trusted skill locations working together.
• Defenders need session-level correlation and stricter control over trusted artefact writing, because isolated alerts do not reveal the malicious intent.

Related NHI Mgmt Group resources: Agentic AI Security Guide · Agentic AI Identity Guide · Zero Trust for AI Agents · MITRE ATT&CK Guide for Defenders

Key terms

• Agent Steering: Agent steering is the practice of redirecting an AI agent when it starts moving toward a risky or incorrect outcome. Instead of stopping everything, the control supplies missing context, pauses unsafe steps, and helps the agent re-plan toward the intended objective. It is useful when intent can be corrected without losing the task.
• Trusted Skill Directory: A location where an AI agent loads skills or instructions that it already considers authoritative. In agentic environments, this becomes a privileged execution surface because writing to it can influence future behaviour without a fresh approval step. That makes it closer to a governance boundary than an ordinary folder.
• Session-level trust: A security model that evaluates whether a live session should continue to be trusted after authentication has already succeeded. In travel and hospitality, it uses behavior, device context, and transaction signals to decide whether access should remain valid as the user moves through booking, loyalty, and support workflows.
• Local State Store: A on-device database or file set that holds an agent's prompts, responses, and workflow context. It is operationally useful because it preserves context across tasks, but it also becomes sensitive identity evidence when attacker code can read it and tailor payloads from the information it contains.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.