Claude Fable 5 shows the harness matters more than model hype

At a glance

What this is: Pixee’s roundup of first Claude Fable 5 and Mythos 5 tests says the decisive security control is the harness around the model, not the model’s raw capability.

Why it matters: That matters to IAM, PAM, and AI security teams because model routing, tool access, and containment now function like identity controls for AI systems and can determine what an agent can see or do.

By the numbers:

• Anthropic says its router fires in fewer than 5% of sessions, so most use hits the full model.
• Jamieson O'Reilly’s testing found the public model routed 100% of offensive work to Opus 4.8 across 181 agentic turns.
• Anthropic’s external red-team logged more than 1,000 hours and reported no universal jailbreaks.

👉 Read Pixee’s analysis of Claude Fable 5, Mythos 5, and AI security harnesses

Context

Claude Fable 5 is a reminder that AI security is now a control-plane problem as much as a model problem. When a frontier model is paired with routing, guardrails, and a separate containment harness, the real question becomes which decisions the surrounding system allows, blocks, or downgrades.

For identity and access teams, that puts AI agents, model endpoints, and workflow hooks into the same governance conversation as service accounts and privileged automation. The article is about model testing, but the operational lesson is broader: context, tool access, and escalation boundaries are the controls that determine whether an AI system can act safely at runtime.

The starting position is typical for frontier AI deployments, where teams focus on model quality first and only later discover that governance lives in the wrapper layer.

Key questions

Q: How should security teams govern AI models that can call tools and access data?

A: Security teams should govern AI models as non-human identities with named owners, limited scope, short-lived credentials, and continuous authorization. The critical shift is to treat every tool call, data read, and update path as a privileged action that can be logged, revalidated, and revoked. Without that discipline, model risk becomes identity risk.

Q: Why do authorization bugs remain hard for AI-assisted security testing to catch?

A: Because authorization failures are usually about relationships, ownership, and business context rather than obvious code patterns. AI can help surface suspicious flows, but it still needs the surrounding application logic to decide whether an access path is legitimate. Human review and strong object-level controls remain essential.

Q: What breaks when an AI harness is too permissive?

A: The system can overreach beyond its intended task, reach data it should not see, or trigger actions that cause operational harm. In practice, a weak harness turns model capability into an uncontrolled access problem. The failure is not only technical. It is governance failure, because scope, escalation, and stopping rules were never enforced tightly enough.

Q: How should teams respond when AI testing shows a model is capable but constrained?

A: Use the finding to validate the containment design, not to relax controls. If the harness is doing the right job, the model’s raw capability should not translate into unrestricted action. Keep the boundary tight, verify downgrade paths, and make sure privileged workflows require explicit governance.

Technical breakdown

Why the harness around an AI model matters

A harness is the surrounding control layer that decides what prompts reach the model, which tools it can use, what outputs are trusted, and whether risky requests are routed elsewhere. In this article, Anthropic’s router and Project Glasswing containment approach show that model capability alone does not determine operational risk. The system-level design matters because the same model can behave very differently depending on whether it is allowed to browse, execute code, or retain context across turns. That is why AI security increasingly overlaps with privilege management and policy enforcement.

Practical implication: Treat the harness as a governed access layer and review tool permissions, routing rules, and containment boundaries before expanding model use.

Why IDOR and authorization logic remain the hard class

The testers reported that injection bugs fell to every configuration, while IDOR and authorization logic remained the frontier. That is consistent with a class of weaknesses that depends on context, not syntax, because the model must understand object ownership, business rules, and hidden relationships. In other words, AI can help find obvious exploitable patterns, but access-control reasoning still breaks when the application logic is distributed across services or depends on implicit trust. This is where AI-assisted security work still needs human validation and strong authorization design.

Practical implication: Prioritise authorization review and object-level access checks rather than assuming model-assisted testing will catch logic flaws.

How containment harnesses change AI security operations

Containment harnesses shift AI from an open-ended helper into a constrained system with bounded inputs and outputs. That can include sandboxed execution, policy-based downgrades for sensitive requests, and separate flows for offensive or defensive tasks. The key point is that the model may be capable of more than the harness permits, which is a deliberate governance choice. For security teams, this means the deployment architecture is now part of the risk decision, not just the procurement decision. If the harness is weak, the model inherits broad, unmanaged authority.

Practical implication: Map every model integration to the tools, data, and actions it can reach, then test containment as aggressively as the model itself.

Threat narrative

Attacker objective: Use the AI system to find or exploit vulnerabilities while bypassing controls that should constrain model behaviour.

1. Entry occurs through AI prompts or workflows that route security-relevant tasks into the model environment.
2. Escalation is limited or enabled by the harness, which decides whether the model can access tools, context, or offensive capabilities.
3. Impact depends on whether the surrounding system lets the model discover vulnerabilities, misuse authorization logic, or trigger downstream actions.

NHI Mgmt Group analysis

The security question has shifted from model capability to controlled authority. This article shows that the meaningful risk is no longer whether a model can reason about attacks, but whether the harness gives it usable authority over tools, data, and workflow state. That is a governance problem, not a benchmark problem. For AI security programmes, the control surface now includes routing, sandboxing, and permission boundaries, which should be assessed alongside model performance.

AI agent identity is becoming a practical governance issue, not a theoretical one. When a model is wrapped in a harness and given delegated tools, it behaves more like a constrained non-human actor than a standalone application. That brings the identity and privilege question into scope: what is the system allowed to touch, and under what policy? The right lens is identity and access governance for AI workloads, including least privilege, ephemeral access, and traceable delegation.

Authorization logic remains the hardest attack class because it lives in context, not syntax. The testers’ observation that IDOR and authorization bugs were the frontier matches what defenders already see in real incidents. These failures are difficult because they depend on object relationships, business workflows, and trust assumptions that AI can surface but not safely resolve on its own. Practitioners should treat context-heavy authorization as a design and review problem, not a scanning problem.

Harness-first security is the named concept this article reinforces. The durable control is the layer around the model that constrains what it can see, decide, and execute. That concept matters because it aligns AI governance with established security discipline: policy enforcement, access control, logging, and containment. Teams that keep treating model selection as the main control will miss the actual failure point.

Frontier AI is accelerating the need for delegated-access governance across IAM and PAM. The article’s deeper implication is that AI systems now sit on the same spectrum as privileged automation, and they need comparable guardrails. That means reviewable delegation, scoped tooling, and strong containment, not broad trust in the model itself. Practitioners should evaluate AI deployments through an authority lens, not just a capability lens.

What this signals

Harness-first governance is becoming the practical baseline for AI security. Teams should expect the conversation to move away from model benchmarking and toward authority design, where the real question is what the system can touch. That means model endpoints, connectors, and workflow hooks now need the same kind of scrutiny identity teams apply to privileged accounts and service credentials.

AI agent identity will matter wherever delegation becomes persistent. Once a model can act through tools and stateful workflows, it starts to resemble a governed non-human identity rather than a transient interface. Programmes that already manage service accounts, secrets, and privileged workflows can extend those controls to AI systems, with policy, auditability, and containment as the core requirements.

The near-term signal for practitioners is that security testing will increasingly separate capability from authority. A model may be able to identify flaws, but without careful access design the surrounding system can still overreach, exposing data or creating unsafe execution paths.

For practitioners

• Define harness ownership for every model integration Assign a named owner for routing, sandboxing, tool access, and output handling for each AI integration. The owner should be able to explain which actions the model can trigger, which data it can see, and which requests are downgraded or blocked.
• Inventory delegated tools and implicit privileges List every API, connector, repository, and execution environment the model can reach, then remove anything that is not required for the use case. Treat these connections like non-human identity privileges and review them on the same cadence as service account access.
• Test authorization logic separately from model prompts Build red-team scenarios that focus on object ownership, record scoping, and workflow abuse rather than only injection payloads. The goal is to verify that the application rejects improper access even when the model appears persuasive or context-aware.
• Constrain offensive and defensive workflows differently Use separate policy paths for security testing, incident response, and general productivity tasks so sensitive actions cannot inherit broad model permissions. Keep the most privileged workflows inside a tighter containment boundary with explicit approval and full logging.

Key takeaways

• The central risk is no longer model intelligence alone, but the authority granted by the surrounding harness.
• Early testing suggests classic injection flaws are easier than context-heavy authorization failures, which remain the hardest class to automate safely.
• AI security programmes should govern delegated tools, routing, and containment with the same discipline used for privileged access.

Key terms

• Agent Harness: The agent harness is the runtime layer that wraps a model and turns it into an acting system. It usually includes the loop, tools, context handling, permissions, hooks, and logs. In security terms, it is often the real place where privilege sits and where identity evidence must be governed.
• Authorization Logic: Authorization logic is the decision-making layer that determines whether a subject can perform a specific action on a resource. In mature architectures, it is separated from business logic so that access rules can be updated, reviewed, and governed independently of application code.
• Delegated Agent Authority: The permission granted to an AI agent to act on behalf of a human user or another agent, inheriting some or all of their access rights. Delegated authority must be explicitly scoped, time-limited, and auditable.
• Containment harness: A containment harness is a restricted deployment wrapper that limits what an AI model can do if it is prompted into risky behaviour. It can include sandboxing, policy enforcement, separate execution paths, and strict logging to prevent unbounded actions.

What's in the full article

Pixee's full analysis covers the operational detail this post intentionally leaves at the framework level:

• The tester-by-tester breakdown of what Fable 5 and Mythos 5 could and could not do in real offensive and defensive workflows.
• The containment and routing details behind Project Glasswing, including how the harness changes model behaviour in practice.
• The specific bug classes that still resist AI-assisted discovery, especially IDOR and authorization logic failures.
• The vendor and practitioner discussion around what to watch as public CVEs emerge from the first wave of Glasswing-related findings.

👉 Pixee’s full post covers the tester notes, containment harness details, and the bug classes that still resist automation.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It is designed for practitioners who need to apply identity controls to modern automation and AI-driven systems.