By NHI Mgmt Group Editorial TeamBased on Tego AI: “Same Words, Different Doors: Notes on Fable 5’s Safety Mechanism and Its Position-Sensitive Routing” (August 15, 2026)

TL;DR: A server-side safety layer in Fable 5 can reroute risky requests to a weaker model, refuse opaque prompts, and make the same text behave differently depending on where it appears in the conversation, according to Tego AI analysis. That kind of position-sensitive routing changes how teams should think about AI governance, because context, not just content, now determines output and fallback behaviour.


At a glance

What this is: This is an analysis of Fable 5’s server-side safety routing, which can hand a conversation to a weaker model or refuse it based on where risky content appears.

Why it matters: It matters because AI governance controls must now account for position-sensitive behaviour, not just prompt content, when deciding how models answer, refuse, or fall back.


Context

Fable 5’s safety layer is not a simple blocklist. It is a routing mechanism that decides, during a conversation, whether the higher-capability model answers directly, falls back to a weaker model, or refuses the turn altogether.

That matters for AI governance because the same content can produce different outcomes depending on whether it appears in the latest user turn, a prior assistant turn, a system prompt, or a tool result. In other words, the control point is not only what was said, but where it was said in the request path.


Key questions

Q: How should teams validate position-sensitive AI safety routing?

A: Test the same content in multiple locations within the conversation, including the newest user turn, earlier assistant output, system instructions, and tool results. If the routing outcome changes with placement, your governance model must treat prompt position as a controlled variable, not a cosmetic detail. That is the only way to know whether the system is stable enough for production use.

Q: Why does fallback routing create governance risk for AI systems?

A: Fallback routing changes the capability profile of the answer without ending the interaction, so the control is no longer just allow or deny. That creates audit and assurance complexity because the same request can be served by different model strengths depending on how the router classifies it. Teams need to govern capability downgrades explicitly, not assume all responses are equivalent.

Q: What breaks when AI safety decisions depend on conversational position?

A: A single static prompt policy no longer guarantees a single outcome. If the newest user turn, prior assistant output, or tool result can change the verdict, then the governance assumption of stable input equivalence fails. That affects testing, incident review, logging, and approval workflows because the control result is now path-dependent, not text-dependent alone.

Q: How should security teams handle tool outputs in AI routing controls?

A: Treat tool outputs as first-class input to the safety layer, because they can influence routing just like a user message. That means tool content needs the same scrutiny as prompt content, especially when it can inject security-sensitive language or transformed text. Governance fails if tool output is assumed to be harmless context rather than evaluated content.


Technical breakdown

How position-sensitive routing works in a model gate

The article describes a server-side classifier that evaluates incoming conversation content and decides whether to route a request to the primary model, hand it to a fallback model, or stop with a refusal. The interesting part is that the decision is not purely content-based. The same phrase can trigger differently depending on whether it sits in the newest user message, earlier context, a system instruction, or a tool result. That makes the router behave less like a static policy and more like a conversational traffic controller that weighs recency, placement, and content together.

Practical implication: Model governance teams should test AI routing with the same text in multiple conversation positions, not just as isolated prompts.

Why fallback routing is not the same as refusal

A fallback route preserves the interaction by handing the turn to another model, while refusal ends the turn with no substantive answer. Those are distinct governance outcomes. Fallback means the system is deliberately choosing a narrower capability profile for the same request, often because the content hit a high-risk category. Refusal means the platform or router decided that even the fallback path should not proceed. For practitioners, that difference matters because logging, user messaging, billing, audit trails, and downstream workflow handling all need to treat these states differently.

Practical implication: Separate fallback handling from refusal handling in policy, telemetry, and user experience design.

Why conversation position changes the control outcome

The article’s core finding is that identical wording can produce different results based on where it appears in the conversation. A sentence in a fresh user turn may trip the gate, while the same sentence in prior assistant output or buried context may not. That means the classifier is not just scanning for risky keywords. It is also sensitive to conversational position, which creates a governance problem for any workflow that assumes prompt content is stable regardless of placement. The same applies to tool outputs, which are part of the evaluated surface.

Practical implication: Treat prompt position as a governance variable and include it in red-team and validation testing.


Threat narrative

Attacker objective: The objective is to influence which model answers, or to provoke refusal, by exploiting how the routing layer evaluates conversational position and content.

  1. Entry occurs when a user or tool surface introduces content that the routing classifier deems high risk, including content placed in the newest turn or embedded in a tool result.
  2. Escalation occurs when the gate chooses a fallback model or a refusal path based on that placement, changing the capabilities available to the requester mid-conversation.
  3. Impact occurs when the system delivers different answers for the same text, or stops the session entirely, creating inconsistent governance and review outcomes.

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

Position-sensitive routing is an identity governance problem, not just a model-safety feature. The article shows that the same text can be treated differently depending on where it sits in the conversation. That means the real control boundary is the request surface, not the prompt string alone. For practitioners, the implication is that governance has to model conversational context as part of authorisation and review.

The assumption that content controls are location-agnostic breaks here. Traditional moderation assumes the same input yields the same verdict wherever it appears. Fable 5 does not behave that way. A phrase in the latest user turn, a prior assistant message, a system block, or a tool result can produce different routing outcomes, so the governance assumption of stable input equivalence fails.

Fallback routing creates a new control class: capability downgrading. The system does not merely block or allow. It can answer through a weaker model, which means policy now governs degrees of response capability rather than binary access. That shifts AI oversight from denial logic to bounded execution logic, which is a materially different operating model for security teams.

Opaque inputs expose the limits of explainable moderation. The article’s encoded-prompt example suggests that unreadable or transformed text can push the system into a stricter category or refusal state. For identity and AI governance teams, that means the classifier is not only judging semantics but also confidence about what it can safely interpret. The practical implication is that transform-safe handling becomes part of governance design.

What this signals

Position-sensitive routing will force AI governance teams to move beyond prompt review. The operational question is no longer only whether a model saw risky content, but where that content entered the conversation and which surface carried it. That means governance controls need to inspect user turns, assistant memory, system instructions, and tool outputs as separate risk-bearing channels.

Capability downgrading is becoming a governance pattern of its own. Once a system can route from a stronger model to a weaker one instead of refusing, teams have to define what counts as acceptable degraded service. That is a policy question as much as a technical one, because the business may accept a fallback answer while still needing assurance that the routed model remains within approved use cases.


For practitioners

  • Test routing against conversation position Run the same prompt as the latest user message, prior assistant output, system content, and tool output, then compare the routing result.
  • Separate fallback and refusal telemetry Record fallback, refusal, and normal-answer states as distinct outcomes in logs, audit trails, and alerting so downstream systems do not collapse them into one event type.
  • Review tool-output surfaces as governed input Treat MCP or other tool results as evaluated content, not just metadata, because the classifier may react to text that arrives through tool channels.
  • Validate encoded and transformed prompts Check how the routing layer handles base64, wrapped, quoted, or otherwise transformed text before allowing it into production workflows.

Key takeaways

  • Fable 5’s router shows that AI safety controls can be position-sensitive, not just content-sensitive.
  • Fallback to a weaker model is a distinct governance outcome from refusal and needs separate policy handling.
  • Practitioners should test the same prompt across multiple conversation surfaces before trusting production routing behaviour.

Related NHI Mgmt Group resources: AI Governance Guide · AI Guardrails and AI Firewalls Guide · AI Security Maturity Model


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 addresses the attack surface, NIST AI RMF and NIST CSF 2.0 set the technical controls, and ISO/IEC 42001:2023 defines the regulatory obligations.

FrameworkControl / ReferenceRelevance
OWASP Agentic AI Top 10ASI03 — Identity & Privilege AbuseThe article centres on a runtime routing layer that changes model capability based on classified risk.
Recommendation — Map routing outcomes to ASI03 and govern when a stronger or weaker model is allowed to answer.
NIST AI RMFMANAGE — ManageThe article is about operational control of AI behavior under changing context and risk conditions.
Recommendation — Define and monitor model-routing controls under the MANAGE function so degraded responses are explicitly governed.
ISO/IEC 42001:2023AI Management SystemThe topic concerns governance of AI behavior, oversight, and controlled fallback handling.
Recommendation — Document routing rules, fallback handling, and oversight responsibilities inside the AI management system.
NIST CSF 2.0PR.AA-05 — Access Permissions, Entitlements and AuthorizationsThe router effectively changes what capability is authorised to answer a request.
Recommendation — Treat model-routing decisions as authorisation outcomes and review whether access entitlements match risk.

Key terms

  • Position-Sensitive Routing: A control pattern where the system’s response changes depending on where content appears in the conversation, not just what the content says. In AI governance, this means the request path itself becomes part of the risk decision, because system prompts, user turns, assistant memory, and tool outputs can be weighted differently.
  • Fallback Model: A fallback model is an approved secondary model used when the primary model refuses, becomes unavailable, or cannot complete the task. It must be selected and governed deliberately, because fallback changes output quality, cost, and trust boundaries, not just availability.
  • Streaming Refusal: A platform response in which the system stops generation and returns a refusal state instead of a completed answer. In AI governance, refusal is a distinct control outcome from fallback because it closes the interaction entirely and often requires separate logging, user messaging, and workflow handling.
  • Tool Output Surface: The content returned by an external tool and injected into the model’s context for evaluation. In governed AI systems, tool output is not just metadata, because it can influence routing, safety decisions, and downstream generation in the same way as user-entered text.

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 governance in your organisation, it is worth exploring.
NHIMG Editorial Note
Published by the NHIMG editorial team on October 22, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org