Steering inside the forward pass: representation control without retraining

The problem: rules written in the chat

When you write "never share restricted fields" into an assistant's instructions, that rule becomes plain text in the same stream as everything the model reads. Your instruction and a clever counter-argument in a customer's email have identical standing — both are just words competing for the model's attention, and the newer words often win.

Written rules also teach shallow habits. A model can learn to say "I can't help with that" without actually holding the boundary — it complies until someone phrases the request differently.

Representation engineering — this study's method — moves the rule out of the chat and into the model's working memory. As the model forms an answer, its internal layers carry a kind of running sketch of what it is about to say. It turns out that properties like "stays in scope," "honest," or "refuses harmful requests" correspond to real, measurable directions in that sketch — directions we can push.

The method: a dial inside the model

Instead of retraining weights or writing longer system prompts, the protocol works in three stages:

1. Find the direction of the rule

Offline, we run paired examples through the untouched model — answers that stay inside the boundary versus answers that leak past it. The difference between how the model's working memory behaves on each is a direction we can measure once and reuse. Researchers call it a steering vector (v); think of it as the bearing that points toward "stays in scope."

2. Nudge the working memory, not the weights

While the model writes, we add a little of that direction into its working memory at every step: h′ = h + α · v. It is one elementary addition inside the machine — so cheap it is effectively free, and nothing in the input stream can argue with it.

3. Apply pressure only when needed

Push the dial too hard on every word and the model stiffens — it repeats itself or refuses harmless questions. So the dial is adaptive: a small gate watches each step and applies pressure only where a boundary decision is actually being made (the method is called Token-level Adaptive Routing, or TARo). Routine wording flows through untouched.

4. One model, many rulebooks

Because the dial is applied while the model runs, each request can carry its own mix of settings — a clinic tenant's scope-and-caution, a finance desk's precision-and-compliance, an EU subsidiary's privacy posture — all served by the same model on the same hardware. The rulebook travels with the request, not with the weights.

A limit written in the prompt is a suggestion the model weighs against the next sentence. A limit in the model's working memory is part of how the answer is made.

How we test it

We run the dial protocol on both rigs to measure overhead and multi-tenant scaling:

Rig A — the office workstation

• Hardware: Apple M4 Max with 64 GB shared memory, plus a consumer GPU workstation (RTX 4090, 24 GB).
• Model stack: Open 7B and 14B models with measurement hooks on their middle layers — where the dial acts.
• The dial bank: Fifty pre-computed rule directions stored in under 4 MB of memory; the adaptive gate is a small fused routine that checks each step.
• What we watch for: Whether the hooks add jitter between words on local hardware, and whether switching rulebooks between requests is truly zero-cost.

Rig B — the server GPU

• Hardware: NVIDIA H100 with 80 GB high-speed memory, running vLLM continuous batching.
• Model stack: 32B and 70B models where each request in a shared batch carries its own dial settings as metadata.
• Execution: Custom GPU kernels apply the per-request nudge inside the same memory pass the model already performs — no round-trips, no stalls.
• What we watch for: Whether writing speed stays flat as the shared batch grows from 1 to 128 concurrent tenants, each with different rulebooks.

What we watch

Four observables tell us whether the dial holds the boundary — and whether it breaks anything else:

1. Does the nudge survive to the final answer: We track how strongly the steering direction persists through the model's layers, confirming the middle-layer push still shows up in the finished text rather than being washed out downstream.
2. Is the model still fluent: At every step we log how uncertain the model is about its next word and how far its choices drift from the untouched model — catching repetition or collapse early.
3. Can attacks cancel the dial: We run multi-turn framing attacks and long distracting documents designed to push the model against the dial — and measure whether the adaptive gate tightens automatically.
4. Do dials interfere: When a request carries three settings at once (say, scope + caution + tone), we check whether turning one up weakens the others.

What success looks like

Four quantitative targets across both rigs:

• Nearly free to serve: The dial adds no more than 1.5% to response speed on the office rig and under 0.8% on the server at 64 concurrent tenants.
• A measurable safe corridor: For each model we identify a dial range where the boundary holds on ≥ 95% of probes while general fluency degrades by less than 15% on standard language benchmarks.
• Adaptive beats static: The adaptive gate cuts off-target failures — stiffened phrasing, false refusals of harmless requests — by at least 60% versus a fixed dial at the same compliance level.
• Rulebooks compose: Up to three dials applied to one request each keep at least 90% of their standalone effect — no separate models required.

Key references