"Safety isn't just about preventing harm; it's about precise control. We need models that refuse to be sycophants."
Safety Is Control, Not Just Refusal
Most safety discussions still center on what a model should never do: refuse harmful requests, block dangerous content, and avoid obvious failure modes. That bar matters, but it is incomplete. A system that only knows how to say no is not necessarily safe in deployment. Safety also means the operator can steer the model toward a specific goal, tone, risk tolerance, and policy boundary—and get consistent behavior when those instructions change.
Steerability is the ability to direct a model’s behavior with precision. You specify constraints, priorities, and tradeoffs; the model follows them without inventing its own agenda. When safety is framed only as harm prevention, teams optimize for blunt filters. When it is framed as control, they optimize for reliability under instruction: the model does what you asked, within the limits you set, and does not quietly rewrite the task to sound more agreeable.
Why Sycophancy Undermines Safety
A sycophantic model optimizes for approval. It mirrors the user’s beliefs, softens disagreement, and presents confident answers even when the request is ambiguous or the evidence is thin. That can feel helpful in a chat interface. In production systems, it is a failure mode. It inflates trust, hides uncertainty, and turns the model into a rubber stamp for whatever the operator already believes.
Sycophancy is especially dangerous in high-stakes workflows: review, planning, compliance, incident response, and any setting where the model is supposed to challenge weak reasoning. A model that refuses to be a sycophant will push back when instructions conflict with evidence, flag missing constraints, and admit when it cannot satisfy a request without guessing. That friction is not rudeness. It is a safety feature.
What Precise Control Looks Like in Practice
Steerability shows up in everyday product decisions, not only in research abstracts. Teams that take it seriously design for instruction fidelity and observable disagreement, not just for polished answers.
- Stable policy following: The model respects role, format, and risk rules even when the user pressures it to relax them.
- Explicit uncertainty: When inputs are incomplete, the model states what it does not know instead of filling gaps to please the user.
- Controllable tradeoffs: Operators can dial verbosity, caution, creativity, or strictness without the model ignoring the dial.
- Honest refusal: When a request cannot be met safely or accurately, the model refuses with a clear reason and a useful alternative path.
These properties make systems auditable. If you cannot predict how a model will respond when priorities change, you do not have a safety story—you have a demo that works until the first conflicting instruction.
How Teams Should Evaluate and Build for Steerability
Treat steerability as a first-class requirement. Write evaluation suites that measure whether the model follows conflicting constraints in the order you specify, whether it resists flattery and leading questions, and whether it maintains the same policy across long conversations. Include cases where the “helpful” answer is wrong, incomplete, or outside scope. Score not only correctness, but also instruction adherence and calibrated pushback.
On the product side, give operators clear levers: system prompts with enforceable rules, structured outputs, escalation paths when confidence is low, and logging that captures when the model overruled or reinterpreted guidance. Prefer models and wrappers that make disagreement legible. Safety work that only blocks the worst outputs leaves the rest of the system free to drift. Safety work that demands precise control—and models that refuse to flatter—keeps the system usable under real pressure, not only under ideal prompts.