Because vectors describe where a behaviour points in activation space, not whether the network implements that behaviour with separate machinery. Two behaviours can be mathematically different and still rely on the same weight matrices. If those matrices are modified, both behaviours can change, even when the vectors look unrelated.
Why This Matters for Security Teams
Orthogonal refusal vectors can look reassuring because they suggest a clean separation between a model’s “safe” and “unsafe” behaviour. The problem is that vector geometry does not prove implementation isolation. If the same layers, attention paths, or feed-forward weights still shape both behaviours, a change intended to improve one refusal mode can degrade another, or create a new bypass. That is exactly why governance guidance such as the NIST AI Risk Management Framework emphasises measurable risk treatment, not just interpretability claims.
For security teams, the operational question is whether the refusal signal is robust under prompt variation, model updates, fine-tuning, and tool access. In agentic systems, a refusal vector may be only one layer of defense, while the surrounding orchestration still permits harmful action through a different pathway. That is why the OWASP Agentic AI Top 10 treats prompt injection, unsafe autonomy, and output handling as system risks rather than isolated model quirks. In practice, many security teams encounter “safe” behaviour only after a model update or jailbreak has already altered the refusal path, rather than through intentional isolation testing.
How It Works in Practice
Orthogonal vectors are useful for analysis, but they do not imply that the model contains separate safety machinery. A refusal direction may correlate with a specific concept in activation space, yet the actual decision can still depend on shared parameters that also support helpfulness, tool selection, or planning. If those parameters are reused, then the behaviour is entangled even when the vectors appear mathematically distinct.
Practically, teams should test the system at multiple layers:
- Probe the refusal behaviour across paraphrases, multilingual prompts, and multi-turn context.
- Check whether fine-tuning changes unrelated outputs, which can reveal shared parameter dependence.
- Validate whether the model still refuses when tool calls, retrieval, or system prompts alter the execution path.
- Measure whether the safety signal survives quantisation, distillation, or adapter merging.
This is where alignment work from the NIST AI 600-1 Generative AI Profile and threat modeling through the MITRE ATLAS adversarial AI threat matrix become important. They encourage teams to evaluate model behavior, attack paths, and failure modes as part of the whole pipeline, not as a single explainability result. The key point is that orthogonality can indicate separability in representation, but safe isolation requires evidence of controlled execution boundaries, resilient training, and consistent refusal under adversarial conditions. These controls tend to break down when safety is implemented as a lightweight representation overlay on top of a shared base model because the underlying weights still govern multiple behaviours.
Common Variations and Edge Cases
Tighter refusal gating often increases complexity and latency, requiring organisations to balance stronger blocking against model usefulness and operational cost.
There is no universal standard for proving that a refusal vector is truly isolated. Current guidance suggests treating orthogonality as a hypothesis, not a guarantee. That matters most in environments that rely on adapters, retrieval augmentation, or agentic tool use, where safety can be bypassed by shifting the task from generation to planning or action selection. The control surface is larger than the vector itself.
Edge cases also appear when safety is tested only in the base model but not after deployment changes. Fine-tuning, preference optimisation, and prompt-template edits can all move the decision boundary without obviously changing the refusal vector. In agentic workflows, the model may “refuse” text generation while still authorising a tool call or producing a partial response that creates downstream risk. The CSA MAESTRO agentic AI threat modeling framework is relevant here because it pushes teams to examine how agent goals, tools, and guardrails interact under real operational pressure. The practical test is not whether a vector points in a clean direction, but whether the system remains safe when that direction is perturbed, composed, or circumvented.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10, MITRE ATLAS and CSA MAESTRO address the attack and risk surface, while NIST AI RMF and NIST AI 600-1 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST AI RMF | Addresses risk measurement and governance for AI behaviours that are not truly isolated. | |
| NIST AI 600-1 | GenAI profile is relevant for evaluating refusal reliability across deployment conditions. | |
| OWASP Agentic AI Top 10 | Agentic AI risks include unsafe autonomy and guardrail bypass beyond simple vector isolation. | |
| MITRE ATLAS | Adversarial AI tactics help model how safety behaviours can be evaded or degraded. | |
| CSA MAESTRO | Threat modeling for agentic systems fits cases where safety depends on shared execution paths. |
Use AI RMF to validate safety claims with testing, monitoring, and accountable risk treatment.
