AI models are improving at offensive security workflows

At a glance

What this is: Xbow's white paper argues that model capability gains in offensive security workflows have accelerated enough to change how practitioners think about evaluation and runtime control.

Why it matters: For IAM, PAM, and AI security teams, this matters because offensive capability in models can change how quickly misuse, credential abuse, and security testing behaviours emerge inside governed environments.

Context

AI models are increasingly being evaluated not just for general usefulness, but for how they behave inside security workflows. That matters because offensive capability is a governance problem as much as a technical one: once a model can reason through exploitation steps, teams need a way to assess, constrain, and monitor that behaviour before it is embedded in production use.

Xbow's white paper focuses on the first half of 2026 and on model performance across price bands, which is the right lens for practitioners. The issue is not a single model or a single benchmark, but the broader signal that offensive security capability is becoming more accessible across the market, which raises the bar for AI governance, test discipline, and runtime controls.

Key questions

Q: How should security teams evaluate AI models for defensive cyber work?

A: Use representative tasks, not generic prompts. Score the model on accuracy, runtime cost, latency, and completion reliability against the actual workflows you expect it to support, then decide whether the result is good enough for triage, investigation, or analyst assistance. A benchmark only matters if it reflects your operational boundary.

Q: Why do models with stronger offensive capability create governance risk?

A: Because the model may be reasoning about attack steps while the surrounding environment grants tool access, data reach, and execution rights. That combination can turn capability into action, so governance must cover both model behaviour and the privileges attached to the workflow.

Q: What breaks when model tool access is broader than necessary?

A: The boundary between analysis and action becomes too thin. A model that can call sensitive tools or touch production systems can move from simulated testing into real-world impact, which increases blast radius, complicates review, and makes attribution of actions harder.

Q: What should security teams do when an AI agent starts using new workflows?

A: Treat new workflow reach as a governance change, not a minor configuration update. Revalidate the agent's scope, the permissions it inherits, the data it can touch, and the logs needed to prove what happened during runtime.

Technical breakdown

Why offensive security workflow evaluation is different from general AI testing

Offensive security workflows combine reconnaissance, hypothesis generation, tool use, and iterative reasoning under constraints. That is materially different from testing a model on static Q&A or even generic coding tasks, because the model has to maintain context while pursuing a goal across multiple steps. In practice, that means benchmarks need to measure chain quality, not just isolated answer correctness. For security teams, the relevant question is whether the model can sustain effective adversarial reasoning in a live environment, including when prompts, tools, or guardrails change mid-task.

Practical implication: evaluate models against multi-step security tasks, not only single-turn prompts.

How price-band comparisons change model risk assessment

Comparing models across price categories is useful because it exposes whether offensive capability is confined to premium systems or is spreading downward into more accessible tiers. That matters for procurement and governance, since lower-cost models are easier to embed broadly and may be harder to monitor consistently. A model that performs well in offensive workflows at a lower price point can increase the number of places where security teams need policy, logging, and supervision. The governance issue is distribution, not just peak capability.

Practical implication: assess access controls and monitoring by deployment tier, not just by model brand.

What runtime supervision has to cover in AI-assisted security work

Runtime supervision has to go beyond prompt filtering and focus on what the model is allowed to attempt, which tools it can call, and what evidence is retained for review. Offensive workflows are especially sensitive because a model can shift from analysis into execution-like behaviour quickly if tool access is too broad. In identity terms, that creates a governance overlap with NHI and agentic AI security: the model may be the decision-maker, but the surrounding privileges, credentials, and workflows determine the blast radius. Security teams should treat this as a control-plane problem, not a content-moderation problem.

Practical implication: pair model evaluation with tool-scoping, credential scoping, and audit logging.

NHI Mgmt Group analysis

Offensive model capability is now a governance problem, not just a lab curiosity. When frontier models improve in security workflows, the risk shifts from theoretical misuse to practical deployment decisions. Security teams must decide where AI can reason, where it can act, and where it must remain supervised, or the environment will define those boundaries for them.

Capability spread across price bands creates a broader control problem. If offensive performance is not limited to the most expensive systems, then more teams can deploy capable models without mature oversight. That widens the number of possible control failures, especially where procurement, sandboxing, and telemetry are weaker than the model's practical capability.

AI security now intersects directly with NHI governance. A model that can participate in offensive workflows still depends on tool credentials, service access, and runtime permissions. That means the surrounding identity model becomes part of the security boundary, and unmanaged delegation can turn an AI system into a privilege amplifier.

Model evaluation needs to become a standing control, not a one-time benchmark. Offensive capability changes as models, tools, and prompt patterns evolve. The defensible position is continuous reassessment of what a model can do inside a real workflow, with governance tied to the privileges and data it can reach.

What this signals

The key programme shift is to evaluate model capability at the point of use, not only during procurement. Once offensive reasoning can be embedded inside workflows, policy has to define tool scope, evidence capture, and human approval boundaries before deployment expands.

Runtime authority gap: the control failure is not simply that a model can generate harmful output, but that it may hold enough delegated access to turn output into action. That makes identity, approval, and logging controls part of AI governance, not separate disciplines.

For practitioners

• Define offensive-workflow evaluation criteria Test models on multi-step security tasks that include reasoning, tool selection, and context retention, not just isolated prompts.
• Scope tool and credential access tightly Limit the APIs, data sources, and execution rights available to any model that can participate in security workflows.
• Require audit trails for model actions Log prompts, tool calls, outputs, and human approvals so security teams can reconstruct what the model attempted and why.
• Reassess controls by deployment tier Review how lower-cost models are governed across teams, because accessibility can matter more than headline model capability.

Key takeaways

• Xbow's research points to a practical increase in offensive AI capability, which changes the security question from possibility to governance.
• The hardest risk is not model output alone, but model output combined with tool access, credentials, and execution rights.
• Teams need repeatable evaluation and runtime controls that reflect how models actually behave inside security workflows.

Key terms

• Offensive Security Workflow: A sequence of security tasks that mirrors attacker behaviour, such as recon, chaining findings, or testing exploit paths. In AI evaluations, the important question is not whether a model can answer about attacks, but whether it can sustain useful reasoning across multiple steps in a realistic workflow.
• Runtime Supervision: Continuous observation of what an identity or agent actually does while it is operating. For NHI governance, runtime supervision helps detect scope creep, unusual tool chaining, and behaviour that is technically permitted but operationally unsafe.
• Delegated Access: Delegated access is permission granted to one identity to act on behalf of another user, service, or system. In NHI environments, this usually appears in OAuth-connected apps and automation tooling. It is powerful, but it must be tightly scoped and reviewed because it can persist long after the original business need ends.
• Configuration Drift: Configuration drift is the gradual divergence between a system's intended secure state and the settings it actually runs with over time. In SaaS, drift often appears when admins change sharing, logging, or access controls under pressure and never return to validate the result.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. Explore the course when your programme needs a common baseline for governing machine identity and AI-driven access.