Be Ready Before the Attack: A Practical Guide to Self-Hosting an Open Model for Cyber Defense

Jeff Boudier

jeffboudier

Follow

Why this matters now

On July 16, 2026, Hugging Face disclosed a security incident that was different from anything the team had handled before: the intrusion was driven end to end by an autonomous AI agent system, and it was detected and dissected largely with AI on the defense side. The attacker ran a swarm of tens of thousands of automated actions at machine speed, exactly the "agentic attacker" scenario the industry has been forecasting.

Buried in that disclosure is a lesson every enterprise security team should act on right now. When Hugging Face went to analyze the attack, the first attempt used frontier models behind commercial APIs. It did not work. Forensic analysis means submitting large volumes of real attack commands, exploit payloads, and command-and-control artifacts, and those requests were blocked by the providers' safety guardrails, which cannot tell an incident responder apart from an attacker.

The work got done instead on GLM 5.2, an open-weight model, running on Hugging Face's own infrastructure. That choice had a second benefit: no attacker data, and none of the credentials it referenced, ever left the environment.

The takeaway for defenders is direct. Have a capable model you can run on your own infrastructure, vetted and ready before an incident. It solves two problems at once:

1. No guardrail lockout. Your responders can analyze real malicious payloads without a hosted provider refusing the request at the worst possible moment.
2. No data exfiltration. Attacker artifacts, logs, and the credentials they touched stay inside your security perimeter.

This is not an argument against safety measures on hosted models. It is an argument for having a self-hosted fallback that is already tested and warm when you need it. This guide shows you how to set one up.

The good news is that you do not have to build any of this plumbing yourself. Thanks to Hugging Face's partnerships with Dell, Microsoft, and AWS, deploying GLM 5.2 into infrastructure you manage (on-premise or in your own cloud tenancy) is now a few clicks and a copy-paste, with the containers, runtimes, and security scanning already handled for you.

Why GLM 5.2

GLM 5.2 is the model Hugging Face reached for during the incident, and it is a strong fit for security forensics work:

• Open weights, MIT license. No regional limits and no usage policy that can block your responders mid-investigation. You control the deployment end to end.
• Solid 1M-token context. Incident analysis means feeding in enormous action logs (the Hugging Face investigation reconstructed a timeline from more than 17,000 recorded events). A large, stable context window lets you correlate across a full attack timeline rather than analyzing it in fragments.
• Strong reasoning and agentic scores. GLM 5.2 posts competitive numbers on reasoning and agentic benchmarks, which is what you want for triaging telemetry, extracting indicators of compromise, and separating genuine impact from decoy activity.

The rest of this guide focuses on getting GLM 5.2 running where your security team can actually use it. The good news is that Hugging Face makes this genuinely easy: through its partnerships with Dell, Microsoft, and AWS, the same open model deploys into infrastructure you manage without you having to assemble drivers, serving runtimes, or security tooling by hand. We start with on-premise deployment for Dell customers, then cover deploying the same model inside your own cloud tenancy on Microsoft Foundry or AWS SageMaker.

"But is an open model good enough for this?"

This is the objection worth addressing head on, because the whole point is to have a fallback that is genuinely capable, not a consolation prize. Forensic analysis of an agentic attack leans on three things: reasoning over messy evidence, tool and agent orchestration, and reading exploit and terminal activity. Those map directly to published benchmarks, and GLM 5.2 holds its own against the frontier hosted models your team would otherwise be locked out of.

Scores as published on the GLM 5.2 model card. Higher is better.

The pattern is the important part. On the tool-use and reasoning tasks that forensics actually depends on, GLM 5.2 sits right in the mix with the closed frontier models, ahead of Gemini 3.1 Pro on tool orchestration and terminal work, and ahead of GPT-5.5 on reasoning-with-tools. It trails Claude Opus 4.8 by a few points on most rows, but here is the thing: during an incident, the frontier model you cannot use is worth zero, because its guardrails refuse the payloads you need to analyze. A slightly lower benchmark score that you can actually run on your own hardware, against real attacker data, beats a higher score you get locked out of at 2am. Capability you control wins.

Option 1: On-premise deployment with Dell Enterprise Hub

For the strongest data isolation, run the model on hardware you own. The Dell Enterprise Hub is a portal built through a collaboration between Dell Technologies and Hugging Face that makes this straightforward. Instead of assembling drivers, serving runtimes, and configurations yourself, you get containers that are pre-tested and optimized for specific Dell platforms, so what you deploy is known-good on day one.

The security posture is a good match for this use case. Every model in the catalog is scanned for malware and unsafe serialization formats, the container images are signed with SHA384 checksums for integrity verification, and the whole thing plugs into Hugging Face Enterprise features like Single Sign-On, fine-grained access controls, and audit logs. The model runs entirely inside your environment, which is the entire point when the data you are feeding it is attacker payloads and harvested credentials.

GLM 5.2 FP8 is available in the catalog here: dell.huggingface.co/models/zai-org/GLM-5.2-FP8. It is validated on the Dell PowerEdge XE9680 (NVIDIA H200), XE9680 (AMD MI300X), and XE9785 (AMD MI355X).

Step by step

1. Log in. Go to the Dell Enterprise Hub and sign in with your Hugging Face account.

2. Open the model. Navigate to the GLM 5.2 FP8 model page and review the model card, which is written for enterprise use.

3. Pick your platform. Click Deploy, then select the Dell platform that matches the hardware you have (for example, XE9680 with NVIDIA H200, or XE9680 with AMD MI300X). The Hub gives you the tested configuration for that exact platform.

4. Copy the deployment command. The Hub generates a ready-to-run Docker command for your chosen platform. It looks like this:

   docker run --gpus all --shm-size 1g -p 8080:80 \
     -v <DOWNLOAD_DIR>:/data/ \
     -e HF_HUB_CACHE=/data/ \
     -e MODEL_ID=<MODEL_ID> \
     registry.dell.huggingface.co/enterprise-dell-inference-<model>:<tag>
   

   Copy the exact command shown in the Hub for GLM 5.2 rather than the placeholder above, since it will carry the correct image, tag, and model settings for your platform.

5. Run it on your Dell server. Paste the command into a terminal on your Dell Linux system. The container bundles the serving runtime and all dependencies, so there is nothing else to install. For scaled or multi-node setups, the Hub also provides Kubernetes deployment instructions, and you can mount pre-downloaded weights from a shared filesystem such as NFS.

6. Call the endpoint. Once running, the model is served behind an OpenAI-compatible API on port 8080. Any tooling that already speaks the OpenAI Messages API can point at it with no code changes, which makes it easy to wire into your existing security tooling or a prototype built against a hosted API.

That is the whole flow. The full documentation lives at dell.huggingface.co/docs.

Now unplug the metaphorical network cable in your head and notice what you have: a capable model, running on your own metal, that your incident responders can point at raw attacker artifacts without anything leaving the building and without a guardrail refusing the request.

Option 2: Deploy the same model in your own cloud tenancy

Not every team runs on-premise hardware. If your security perimeter is a cloud tenancy you control, you can deploy the same GLM 5.2 model there through Hugging Face's cloud service provider integrations. The key property still holds: the model runs inside your account, on your infrastructure, so attacker data and credentials stay within your governance boundary rather than being sent to a third-party API.

Microsoft Foundry. Hugging Face open models deploy into Foundry Managed Compute, where the weights are pre-staged in Azure and the serving runtime is built and scanned by Microsoft, running behind the same endpoint, identity, billing, and observability surfaces as your other Foundry workloads. To deploy GLM 5.2, open the model with the Foundry deployment flow at huggingface.co/zai-org/GLM-5.2-FP8?foundry=true, then follow the deployment wizard in the Foundry portal to select an accelerator (options include NVIDIA H100 and AMD MI300X) and create a managed compute endpoint. The result is a secure REST endpoint you own, inside your Azure subscription.

Amazon SageMaker. You can deploy the same model into your own AWS account through SageMaker JumpStart using the SageMaker Python SDK. Open the model with the SageMaker deployment flow at huggingface.co/zai-org/GLM-5.2-FP8?sagemaker_deploy=true, copy the generated snippet, and run it from a SageMaker notebook. The pattern looks like this:

import sagemaker
from sagemaker.huggingface import HuggingFaceModel

role = sagemaker.get_execution_role()

# Deploy GLM 5.2 straight from the Hub into your AWS account
huggingface_model = HuggingFaceModel(
    env={"HF_MODEL_ID": "zai-org/GLM-5.2-FP8"},
    role=role,
)

predictor = huggingface_model.deploy(
    initial_instance_count=1,
    instance_type="ml.p5.48xlarge",  # size to the model
)

Copy the exact snippet and instance recommendation from the model page rather than the illustrative code above, since the Hub tailors the runtime and sizing to the model. When you are done, remember to delete the endpoint (predictor.delete_endpoint()) so you stop paying for idle GPUs.

In both cases you get the same defensive benefit as the on-premise route: a capable model, running inside your own perimeter, ready before an incident and free of the guardrail lockout that blocks hosted APIs from analyzing real attack data.

The bottom line

The July 2026 incident showed that AI-driven attacks are no longer theoretical, and that defenders analyzing them at machine speed hit a wall with hosted models: guardrails that cannot tell a responder from an attacker, and a data boundary you do not want attacker artifacts crossing. A self-hosted open model solves both.

The mistake to avoid is treating this as something to figure out during an incident. Stand it up now, while things are calm. Vet GLM 5.2 on your Dell hardware or in your cloud tenancy, confirm your responders can feed it real payloads, wire it into your tooling, and keep it warm. When the alert pages someone at 2am on a weekend, the model is already there, already tested, and already inside your walls.

Security is never finished. Being ready before the attack is the part you can control.

Deploy GLM 5.2 on Dell hardware: dell.huggingface.co/models/zai-org/GLM-5.2-FP8 · Documentation: dell.huggingface.co/docs · Read the incident disclosure: huggingface.co/blog/security-incident-july-2026