This is the first part of a series on agent steering. Here we make the case for it as a tactic, in later parts we weaponize it end to end.

Agent Steering as an Attack Tactic

A core functionality in agentic systems, especially coding agents, is agent steering - pointing an agent at a goal by injecting context, rules files, project conventions, steering docs, skills the agent auto-loads. It is not a bug or a side effect, but rather the core interface. We hand agents a goal in natural language and a body of trusted instructions and references, and the agents work out the steps. Steering, as a mechanism, is how agentic systems are meant to work, and coding agents use it constantly to give themselves the right context at the right moment.

The same mechanism that makes agents powerful also makes them vulnerable.

Before agents, software was deterministically configured to run a specific workflow, with each step predefined by design. AI agents introduced a different approach: instead of hard-coding behavior, users provide the context, instructions, references, and constraints that shape how the agent reasons and acts. As a result, the agent’s behavior is increasingly influenced by the information it consumes, making the steering layer both a source of flexibility and a potential attack surface.

Which is exactly why it is dangerous in the wrong hands. The tactic we are describing is adversarial agent steering: an attacker gains some level of access to an agentic system and uses that same steering surface to drive the agent toward goals that are not aligned with those of  the user. The agent keeps running on behalf of the user, doing what looks like its job, while serving someone else's intent. Nothing is exploited in the traditional sense. The attacker is using the feature.

What sets it apart is the level of abstraction. An execution path is a fixed sequence the attacker must spell out - steering needs only a stated goal, and the agent improvises the steps, picks the moment, and uses its own trust to carry them out. Prompt injection, RAG poisoning, and hidden-instruction attacks on config and rules files (demonstrated against coding agents and now cataloged in MITRE ATLAS) are not steering themselves, they are vectors that get attacker-controlled content into context. Steering is about what that content tells the agent to do once it is there. An execution path defines the command to run, while steering defines the goal to pursue and leaves the steps to the agent.

Ordinary Attacks vs. Agent Steering

So what is the difference between an "ordinary" attack and an agent steering based attack?

Ordinary attacks - Say an attacker manages to get code execution on a developer machine where an agentic system such as Cursor or Claude Code is running. The attacker can run a script to harvest secrets, map privilege-escalation misconfigurations, and probe for lateral-movement opportunities. All of those are valid paths and all of them carry real risk to the organization. But they are detectable, and most orgs know how to defend against them.

Agent steering attack - Agentic systems on the same machine introduce a different risk class, one where the attacker harnesses the agent itself to do these tasks. Using the agent rather than a script or binary buys the attacker three things at once: the agent already runs as trusted, it can reach a goal by improvising around roadblocks instead of following a fixed payload, and its actions blend into the legitimate work it was installed to do. That combination is why it deserves to be named on its own.

Where it sits on the kill chain

Calling something a "new tactic" invites a fair question from anyone who reads ATT&CK for a living: is this a new tactic, or a new technique under an existing one?

The honest answer is that the objectives are not new. A steered agent is still after credential access, exfiltration and lateral movement. Those tactics already exist. What’s new is the execution model. Almost every technique cataloged today carries a buried assumption: the adversary authors the steps. They write the script, compile the binary and stage the payload. Agent steering breaks that assumption. The adversary authors a goal, and a trusted, highly capable system on the endpoint authors the steps.

The closest existing analog is Living off the Land - abusing tools that are already present and trusted so nothing foreign has to be dropped onto the machine. Agent steering is the next turn of that screw. The agent is not a fixed trusted binary you invoke with known arguments; it reasons, plans, and adapts toward whatever goal it has been handed. We can call it “living off the agent”. That is why we treat it as its own tactic in our analysis rather than another row under an existing technique: the defender's model of "find the attacker's tool and the attacker's steps" does not have a tool or a fixed set of steps to find.

The trust assumption

The assumption is that an agent is doing the bidding of the user. It runs under the user's own account and, as a result, is treated as trusted, with the user accountable for whatever it does. That assumption isn't entirely true, but it's where things start. An agent attempting to exfiltrate secrets can try different routes if it's blocked and, more importantly, it can wait for the right moment. Agents are outcome-driven, so they work around roadblocks to reach their goal: waiting for an MFA flow to complete, or pulling credentials right after a deploy step has touched the cloud. A steered agent can reach an exfiltration goal that would otherwise take a carefully crafted piece of malware.

The interesting question is not whether an attacker can get content onto the machine. It is: once it's there, how does that content climb from something the agent reads with suspicion to instructions it treats as the operator's own? That climb is where the tactic begins.

Climbing the trust hierarchy

Agentic systems classify input with different levels of trust. A user prompt is assigned higher trust than a webpage the agent reads. The whole game is to get attacker-controlled content evaluated at the top of that gradient rather than the bottom.

Skills are an effective way to do it, because the trust gradient on skills is higher than on most files on the system. A skill is a reusable instruction bundle, a frontmatter block with a name and a description, then a markdown body, that the agent auto-loads into its context window when the description matches what the user just asked. Cursor implements this at .cursor/skills/<name>/SKILL.md  at the project level, and crucially also at the global ~/.cursor/skills/ directory that applies system-wide across every project on the machine. Cursor even loads skills from other agents' directories such as ~/.claude/skills/ for compatibility, widening the reach further. Claude Code has the equivalent concept under its own skills directory, and Anthropic ships the format officially.

Once loaded, a skill's contents sit in the prompt at operator-level trust, treated like a user prompt with no provenance check. A few properties make that trust especially useful to an attacker:

System-wide: A skill written to a global skills directory loads on every project the developer works on, breaking out of the boundary of the initial repository and reaching across the developer's endpoint.

Persistent: Once written, the skill stays on disk and keeps loading in every future session, surviving reboots and even the removal of the original repository.

Specific: The attacker writes the skill's description, and that description is what the agent's auto-selector reads to decide when to load it. A well-targeted skill can evade malicious-skill detection and even pass human review, because it fits the environment and the work being done.

Flexible: A skill's body is just free-form Markdown, so it can carry any multi-step procedure, read this file, call this endpoint, run this command, written to look like a normal team convention, harnessing all the capabilities of a highly capable agent to do the attacker's bidding.

Why this is hard to detect

Here is the part that should bother defenders. Walk back through the actions a steered agent takes and grade each one in isolation. Reading a file is benign. Loading a skill whose description matches the task is the skill feature working as designed. Running a command the loaded instructions called for: normal agent behavior. There is no single step you can point to and call malicious, because the maliciousness does not live in any step. It lives in the relationship between the goal that was planted and the actions taken to satisfy it.

That is the uncomfortable conclusion. If you score individual actions, you will clear every one of them. The attack is only legible when you reason about intent across the whole session, the unit that actually carries the attacker's goal. The individual action is the wrong unit of analysis. The session is the right one.

In the next part of this blog, we weaponize this: we’ll take the trust we just described and add the precision that makes a planted skill land where a generic injection would be refused, then run the full attack end to end and look at exactly what telemetry does, and does not, fire. Stay tuned.