What do security teams get wrong about banning AI models?

Why This Matters for Security Teams

Banning a single AI model can create a false sense of control because the underlying risk is not the brand of model, but the task an attacker can still perform with comparable capabilities elsewhere. Security teams often focus on blocking one service, while attackers shift to another hosted model, a local runtime, or even a chain of smaller tools that still supports reconnaissance, reasoning, and exploit development. That is why the control problem is closer to workflow disruption than platform denial, a point reinforced by the patterns seen in the DeepSeek breach and other NHIMG research. The right question is not whether a model is allowed, but whether the surrounding identity, data, and execution path can be constrained. Security teams that miss this often discover the gap after abuse is already underway, rather than through planned policy review. In practice, many security teams encounter model misuse only after an attack workflow has already been adapted to a different toolchain.

How It Works in Practice

A more effective control model starts with the workflow, not the model name. If an adversary can use any sufficiently capable model to analyse logs, summarise exposed code, generate payloads, or automate probing, then blocking one vendor does little unless the organisation also constrains the supporting data paths, API keys, browser sessions, and execution permissions. The NIST Cybersecurity Framework 2.0 remains useful here because it pushes teams toward asset visibility, governance, and continuous risk treatment rather than one-off product bans. Operationally, teams should ask:

• What data can the model or agent reach?
• Which identities or tokens let it call tools, search repositories, or exfiltrate results?
• Can the same job be completed through another model, local inference stack, or workflow automation?
• Are logging and detection tuned to the attacker workflow, not just the endpoint used?

This is where NHI governance matters. If an AI agent or automation path is involved, the identity that matters is the workload identity, not the model label. Controls such as short-lived credentials, scoped tokens, and tool-level authorization reduce the blast radius even when the model itself changes. Guidance from The State of Non-Human Identity Security shows why this discipline is necessary: many organisations still lack confidence in securing NHIs, which means model bans without identity controls leave the real exposure intact. These controls tend to break down in shadow AI environments where users can switch to unsanctioned local models, unmanaged SaaS copilots, or personal automation accounts because policy enforcement is outside central visibility.

Common Variations and Edge Cases

Tighter model restrictions often increase user friction and can push activity into unmanaged channels, so organisations must balance prevention against the risk of blind spots. Best practice is evolving, but current guidance suggests that blocking high-risk models is only defensible when paired with compensating controls on identity, egress, and data access. That means environment-specific policy, not a universal blacklist. There are legitimate exceptions. Some regulated environments may restrict specific models because of data residency, vendor risk, or unacceptable content handling. Even then, the restriction should be treated as one layer in a broader control stack, not the entire strategy. If a development team can run an open-source model locally, or if a browser-based copilot can access the same repository, the attacker’s capability remains available. This is why frameworks increasingly emphasise continuous evaluation and workflow-aware governance. The emerging lesson from NHIMG research and broader guidance is that the threat is not “the model” in isolation, but the chain of identities, prompts, tools, and outputs that turns capability into abuse. Organisations that only ban the front door usually leave the side door open.

Related resources from NHI Mgmt Group

• What do teams get wrong about training-data security for AI models?
• What do security teams get wrong about audio attacks on AI models?
• What do security teams get wrong about defense-in-depth policy checks?
• What do security teams get wrong about Electron app vulnerabilities?