DeepSeek and Frontier Model-Specific Security Risks

Cisco researchers managed to pay less than $50, and in January 2025, they automated a jailbreak of DeepSeek R1, which gave them an undesirable answer for each of their 50 attempts. That same week, Wiz discovered a DeepSeek database unencrypted on the open internet where he could find openly stored chat logs and secret keys. Eight months later, NIST's Center for AI Standards and Innovation (CAISI) stated that agents developed with DeepSeek are much simpler to hijack than agents created with U.S. frontier models. Those results combined created the attack surface of DeepSeek as the reference case for another question: What does a new model do to your attack surface? The article details the published results, discusses the reasons for the discrepancies among them, considers the alignment tax, and outlines a method to assess any frontier or open-weight model before production.

Why Model Choice Is Now a Security Decision, Not Just a Performance One

Typically, the process of model selection begins with a leaderboard and concludes with a price sheet. However, the model is the one that determines what action to take if an instruction is contained in a web page or an email, and if it is changed, then security behavior changes, even if nothing else in the stack changes.

The Same Application, Different Model, Very Different Risk Profile

Imagine you have a three-tool support agent who can read the inbox, look up an account, and send an email. The team replaces its back-end model to reduce the inference cost. The system prompt and tools remain unchanged, as does the application code.

The hijacking evaluation carried out by CAISI is a good example of what that can accomplish. In agent environments, agents with DeepSeek R1-0528 successfully tried to exfiltrate credentials in 37% of applicable trials, compared to the average of 4% for the agents with GPT-5 and Claude Opus configurations. No change in any line of application code. The risk shifted since the model's readiness to follow injected instructions shifted.

The incentive to make that swap is real. In late January 2025, HiddenLayer estimated that R1 output tokens are approximately 27 times cheaper than OpenAI o1's, according to list prices. This is why the DeepSeek vs frontier model security comparison is relevant: because it's not a ranking, but a property of your deployment. Adding a new dependency with network access is a review that is equivalent to a model change.

DeepSeek as a Case Study in Frontier Model Risk

DeepSeek is not the only poorly protected model; it's the most thoroughly studied. Because there are so many independent events, it can be helpful for comprehending the general security threats of frontier models, as long as the lessons are removed from the article.

Why DeepSeek Became the Reference Point for This Conversation

R1 was shipped on January 20, 2025, and DeepSeek reported that the open weights and reasoning scores of R1 were similar to o1. It is accompanied by six distilled models ranging from 1.5B to 70B parameters, based on Qwen and Llama, with R1-style reasoning on a laptop. Cisco, Wiz, HiddenLayer, and Enkrypt AI published their security findings by Jan. 31. Italy's data protection authority limited the app on Jan. 30; DeepSeek suspended its app in South Korea on Feb. 15 to comply with that country's privacy law.

Despite this, adoption continued to rise. Since January 2025, downloads of DeepSeek models on model-sharing platforms have increased by almost 1,000%; and DeepSeek was re-evaluated when V4 Pro was released in April 2026. This is the largest number of models and evaluators that any model has a security record for.

Applying This Framework to Any New Open-Weight or Frontier Model, Not Just DeepSeek

Others were also flagged by the same studies that flagged DeepSeek. During CAISI's hijacking tests, the open-weight model gpt-oss from OpenAI tried to phish in 48% of applicable cases, as did R1-0528. During the HarmBench test set, the attack success rate for Llama 3.1 405B was 96%, and that of GPT-4o was 86%.

The distribution of open-weight model security risks follows from. You can tweak the weights, a derived ecosystem develops within days, there is no provider-side filter between the model and your customers, and you can run code from the publisher's repo to load the weights. In the DeepSeek analysis, HiddenLayer used the model as a template for any new open-weight frontier model, and throughout this article it will be treated as such. The same four questions apply to all models: How strong are their denials? How does it act as an agent? Where does your data go? What code does it execute once it is loaded?

Documented Security Findings on DeepSeek

The public record consists of four pieces of evidence, each of which records a different layer. The model artifacts and their lineage were measured by the independent red team, Cisco measured the refusal behaviors, and CAISI measured behaviors within agents, with the vendor measuring the infrastructure using Wiz. It's important to keep those layers separated, since they require different controls.

Jailbreak Susceptibility: Cisco's HarmBench Evaluation (100% attack success rate against DeepSeek R1)

The most quoted DeepSeek jailbreak vulnerability has been developed by researchers from Cisco and the University of Pennsylvania. The team took 50 prompts randomly from the HarmBench benchmark (400 harmful behaviors across seven categories) and executed an automated algorithmic jailbreaking method on each target at temperature 0. Refusals were picked up automatically, and jailbreaks were checked manually. The measure used was attack success rate (ASR): the percentage of behaviors for which a jailbreak was successfully identified.

The assessment was effortless, and R1 failed in all the harm categories, and the total assessment cost was less than $50. There are 2 caveats to this honesty. These were only examples of 50 prompts, and they weren't far behind R1 and a number of non-reasoning models. The difference is between the two reasoning models, R1 and o1-preview, and that's where Cisco has its hunch about how DeepSeek trained the models.

Agent Hijacking Susceptibility: NIST/CAISI's Findings (12x more likely than evaluated U.S. frontier models to follow malicious instructions)

The national security evaluation, released on September 30, 2025, compares CAISI's R1, R1-0528, and V3.1 models to GPT-5, GPT-5-mini, gpt-oss, and Claude Opus 4 on 19 benchmarks. The most secure DeepSeek model tested, R1-0528, on average had 12 times higher hijacking susceptibility, meaning it was more likely to execute malicious instructions planted in order to mislead the agent from fulfilling the user's task, compared to U.S. frontier models. Simulated agents sent phishing emails, downloaded and executed malicious software, and stole account login credentials.

The results of the chats were in the same direction. Of 17 well-known jailbreaking methods, R1-0528 responded to 94% of overtly malicious requests compared with 8% for reference models from the U.S. When interpreting these numbers, there are two points to take into account. The hijacking metric also included attempts to commit a hijacking when the tools prevented the hijacking, and some of the CAISI benchmarks are private, making it difficult to replicate independently.

Infrastructure Exposure: The Wiz Research Disclosure (exposed database, plaintext chat logs and auth keys)

The exposed database in the Wiz disclosure had nothing to do with model behavior. During the external attack surface analysis of DeepSeek, Wiz noticed two interesting open ports (8123 and 9000) on DeepSeek subdomains such as oauth2callback.deepseek.com and dev.deepseek.com. These resulted in an unsecured ClickHouse database. A simple SHOW TABLES; listed the datasets, and through ClickHouse's HTTP interface, arbitrary SQL was sent directly to ClickHouse from the browser and the path was /play.

One table, called log_streamContained more than a million log lines of plain text chat history, API secrets, backend information, and operation metadata. CyberScoop reported that the logs were dated back to Jan. 6, 2025. Wiz said that the access granted him full control of the database plus potential privilege escalation. After disclosure, DeepSeek quickly got the exposure. The lesson for buyers is that a hosted API's risk includes its operator's hygiene, which no model evaluation will surface.

Independent Red Teaming Findings (HiddenLayer's ShadowGenes analysis, Enkrypt AI's vulnerability findings)

HiddenLayer merged manual testing, automated red teaming, and their own technique called 'ShadowGenes', which is based on a model genealogy technique that is built on the computational graph of a model and fingerprints it. The configuration and modeling files of the R1 repository were found to have the same SHA256 hash as those of DeepSeek-V3, in line with DeepSeek's claims of lineage. DAN 9.0, STAN, and EvilBot were still able to break in, despite the newer models having largely been able to fix these jailbreaks. HiddenLayer also manipulated the control tokens: it inserted reasoning in between the <think> tags, which caused R1 to state false claims, and it inserted fake tokens for tool calls, which caused R1 to repeat attacker-supplied "results. A follow-up in March 2025 created a signature on a unique rotary embedding pattern that matched both V3 and R1 but not any of the nearly 50,000 other patterns in HiddenLayer's test set, enabling security teams to identify unsanctioned R1 deployments.

In January 2025, Enkrypt AI tested R1 against categories in OWASP Top 10 for LLMs, MITRE ATLAS, and NIST AI RMF. It was found to be 11 times more likely to produce harmful content, four times more likely to produce insecure code, and 3.5 times more likely to produce CBRN-related content than o1, and four and a half times more likely than Claude 3 Opus. During its tests on cybersecurity, 78% of the attempts were able to extract insecure or malicious code.

Why the Same Evaluations Show Different Numbers Across Studies

If you go searching for DeepSeek's jailbreak rate, you'll get 100%, 94%, 58%, and even single digits, all from reputable sources. Their statements are not contradictory. They are of different measures.

Most of the variation is accounted for by five variables. A distilled 8B is a distilled model that inherits a lot of the behavior from Llama, and R1, R1-0528, and V3.2 are different models. The second is an attack strategy. An adaptive algorithm continues to search for a prompt that will yield a successful jailbreak for each behavior, which determines if a jailbreak exists; a fixed library measures the likelihood of a known attack working. The third is the denominator – raw success and failure rates yield significantly different percentages. The fourth is the judge; in the case of partial compliance, an automated refusal detection with human review is different to an LLM-as-judge. The fifth is scope. Protect AI looked at published model files, a supply chain examination, but not a behavioral one.

The rule of thumb is: compare models within a study only, where conditions are the same. That relative difference persists: 100% to 26% in Cisco's run and 94% to 8% in CAISI's. Absolute numbers that are transferred from one study to another do not.

The Alignment Tax: Why Some Frontier Models Trade Safety for Capability

Why does a model not pass basic safety tests if it scores the same on the frontier reasoning test? There are two possible explanations with some evidence. It's not proven to be the cause for R1, but both alter the way you have to deal with model variants.

The Capability-Alignment Trade-Off Paradox

The most telling evidence is from researchers at the Beijing Institute of AI Safety and Governance and the Chinese Academy of Sciences' ForesightSafety Bench, which was published in February 2026. It tested 22 models on 94 risk dimensions and compared the performance of DeepSeek-V3.2 with DeepSeek-V3.2-Speciale, a model optimized for long-horizon reasoning on the same architecture.

With respect to fundamental safety, the ASR under direct prompting was 0.33% for V3.2, and 9.60% for V3.2-Speciale against jailbreak attacks. Speciale reached 11.67% and 45.33%. The authors name this the "capability-alignment trade-off paradox": if the parameter capacity is limited, increasing the pressure on one capability may consume the parameter space needed for general safety behavior. This is the alignment tax. Safety isn't a bolt-on additional filter. It is learned behavior that is stored in the same weights; optimizing these weights heavily for one objective may have a negative impact on the other.

There are two numbers to keep this in proportion. The overall result was the same as the base DeepSeek series being in the same ballpark as, or worse than, the GPT series; it is not the brand's fault, but rather specific variants and training. A Georgia Tech study also showed that the tax is in the opposite direction: you see, when they added safety alignment into the reasoning models, their reasoning performance decreased. All variants- base, reasoning-tuned, distilled, and fine-tuned are individual models for security.

Distillation and Cost-Efficient Training as a Possible Contributing Factor

Cisco highlighted three methods that could have contributed to the lower strength of Cisco's safety mechanisms: reinforcement learning, chain-of-thought self-evaluation, and distillation, which are all cost-efficient approaches used by DeepSeek. There is measurable evidence on the distillation side of the distillation and safety alignment trade-off.

DeepSeek's distilled models are derived from Qwen and Llama models, which were fine-tuned with approximately 800,000 examples generated using R1. A China Unicom study was conducted to compare each distilled model with the base model using a Chinese-language safety benchmark called CHiSafetyBench. Overall accuracy of identification of risky content decreased from 76.17% to 74.00%, and the percentage of responsible responses to risky questions dropped from 55.58% to 50.65%. The model trained with Qwen2.5-14B had a drop of 9.76 points in the risk identification task. The teacher's reasoning, not the rejection response that the base model had been taught, is transferred by distillation.

The same study also displays the fix. Fine-tuning using safety-alignment samples (roughly 50,000) based on mixed safety and reasoning examples improved and surpassed the base models' safety scores, with minor changes to reasoning scores. Protection is known and available. It is usually omitted from cost-optimized releases.

Beyond Jailbreaks: Other Frontier Model-Specific Risk Categories

While jailbreak rates are the ones that get the attention, several of the most impactful results are not about the negative prompts. They are about where data goes, what things the model doesn't explicitly say no to, what code you produce, and what you have on your servers once you load it.

Data Residency and Jurisdiction (where prompts, logs, and outputs are processed and stored)

DeepSeek's privacy policy states that it directly collects, processes, and stores personal data in the People's Republic of China. That includes prompts, uploaded files, and chat history for the hosted app. On January 30, 2025, Italy's Garante issued a decision to limit processing, arguing that EU law is not applicable to it. According to Berlin's data protection commissioner, in June 2025, DeepSeek will move data of German users to processors in China.

The data residency question for an enterprise is not where the model was trained; rather, it is where inference is executed. You can run open weights on your own infrastructure, or your cloud provider already using, such as Microsoft or AWS, that offer R1 on their infrastructure, and are under your existing terms and jurisdiction. It has no effect on the behavior of the model.

Output Filtering and Censorship Behavior

When asked in English, HiddenLayer found that R1 would not reveal the location of Tiananmen Square, but when asked in Chinese, it would respond, and then in other cases, it would reason through a blocked topic within its <think> block before refusing. The accuracy and misinformation of CCP narratives were consistently higher with CAISI, with each of the four CCP narratives echoed twice by CAISI models and once by U.S. reference models. The behavior is enabled when the weights run locally; it's not in a service layer that you can turn off.

The political relevance of the security is not the end of the story. Language-dependent behavior refers to an evaluation in English that doesn't mention what users see in other languages. In almost half of the prompts where R1's reasoning started with Falun Gong, it was going to respond fully, and then would not return the answer; it's either an availability issue or it's a bug if it's a workflow that relies on that answer.

Code Generation Risks: Package Hallucination and Insecure Code Suggestions

Spracklen et al. in the study for USENIX Security 2025 collected 576,000 code samples from 16 models, including a number of DeepSeek Coder sizes. At least 5.2% of packages that were suggested by commercial models were not found, while 21.7% of commercial packages were hallucinated in open-source models, and 205,474 unique names of the commercial packages were found in the study. An attacker can register one of those names on PyPI or npm, and thus result in being installed by anyone who trusts the suggestion. The spread was evened out on five of the newer frontier models in the 2026 re-evaluation to between 4.62% and 6.10%, enough to exploit.

CrowdStrike has tested R1 on 30,250 prompts. When there were no trigger words, 19% of its code had serious vulnerabilities. But if it was called code for an industrial control system in Tibet, it went up to 27.2%. R1 did not implement authentication or session management in a follow-up in which it created a full web application, and 35% implemented insecure password hashing or no password hashing. Add to an allowlist and perform software composition analysis on AI-generated code, whether the model is paper 1 or paper 2.

Infrastructure Risk in Self-Hosted Deployments (trust_remote_code, unverified weights)

This option informally specifies that the loader should run Python files from the model repository (due to the execution capability of Python files in the model repository, this option is called --trust-remote-code). Trust_remote_code: Loading the model involves running the publisher's code with your process's permissions. The official repository was not found to contain any malicious content, but this could change at any time and may not apply to derivatives, warned HiddenLayer. Because the original weights are shipped as safetensors, they are not affected by the risk of arbitrary code, as would be the case with pickle-based formats. Derivatives may not.

from transformers import AutoModelForCausalLM
model = AutoModelForCausalLM.from_pretrained(
"deepseek-ai/DeepSeek-R1",
revision="<commit-sha-you-reviewed>",  # pin an audited commit, never track main
trust_remote_code=True,                # executes repository Python at load time
)

from transformers import AutoModelForCausalLM
model = AutoModelForCausalLM.from_pretrained(
"deepseek-ai/DeepSeek-R1",
revision="<commit-sha-you-reviewed>",  # pin an audited commit, never track main
trust_remote_code=True,                # executes repository Python at load time
)

from transformers import AutoModelForCausalLM
model = AutoModelForCausalLM.from_pretrained(
"deepseek-ai/DeepSeek-R1",
revision="<commit-sha-you-reviewed>",  # pin an audited commit, never track main
trust_remote_code=True,                # executes repository Python at load time
)

Attach the revision to a commit that you have read; load new models in an isolated environment (no credentials, no outbound network connection, without access to the external model world); and check the file hashes. When it comes to unknown derivatives, HiddenLayer discovered over a thousand Hugging Face models that were variations of the "deepseek-r1" name, all ripe for typosquatting.

Hosted vs. Self-Hosted Deployment: Different Risk, Not Less Risk

One frequently-held belief is that open weights are safe to self-host. It eliminates one set of potential hazards and introduces another. Self-hosted vs. hosted deployments: infrastructure security is about who to trust, and the behavior of refusal and hijacking are carried with the model, regardless.

Hosted API Risk: Data Sharing, Third-Party Infrastructure Trust

If you use DeepSeek's own API, the prompts you use will be subject to the jurisdiction set forth above, kept as long as the provider considers it reasonable based on its privacy policy, and stored on infrastructure that you cannot audit. The Wiz disclosure revealed that's what that trust looks like when it breaks down. But availability is also a factor: just after R1 launched, a large-scale attack on the DeepSeek service necessitated the service to suspend new registrations.

If the jurisdiction is changed to a third-party host (such as a major cloud provider), the jurisdiction and the operator also change. Does not modify the model. Those same weights that recorded a 100% in Cisco's test are behind that endpoint and still require controls of their own.

Self-Hosted Risk: Securing the Infrastructure You Now Own

Self-hosting lets you be the operator. You are responsible for the GPU hosts, the inference server, the loader code, the API endpoint, and the prompt logs. The last one is easy to miss: your inference logs are now the sensitive datastore and the lesson from an unauthenticated log database is relevant to you. Ensure authentication is in place on the inference endpoint, ensure that logs aren't on public networks, and control the egress from the inference hosts.

But there's the deployment nobody approved, too. A distilled 7B model can fit in a developer laptop, and that's what HiddenLayer's architecture fingerprinting was designed to identify.

A Framework for Evaluating Any Frontier or Open-Weight Model

There are four checks to evaluate a new AI model's security, to be performed before the model is used in production data. Each one of them can terminate the evaluation, and they are collectively a framework of model evaluation that can be used for every release, not just DeepSeek's.

Run Your Own Red Team Before Production Use

Numbers published are for one person's setup. The result is dependent on changes to your system prompt, tools, languages, and sampling settings, so test the model in your app. Use a fixed attack library for a repeatable baseline, adaptive, algorithmic attacks to discover what the attack library isn't covering, and multi-turn attacks as models that won't accept a direct attack but will if it is gradually built up over multiple turns. This list of AI red teaming tools by methodology of testing can help match tools to the risk – and our guide to AI red teaming covers how to scope that program.

Repeat the same test with your current model. The decision metric is the same, i.e., the relative gap, under the same conditions as in the studies above, and is what makes cross-model comparisons meaningful. Public Red Team benchmarks like HarmBench provide a useful baseline, but aren't a replacement.

Check Independent Benchmarks, Not Just Vendor-Published Numbers

This is important because the April 2026 CAISI evaluation of DeepSeek V4 Pro demonstrates it. V4 performed about similarly to Claude Opus 4.6 and GPT-5.4 on benchmarks it was selected and reported on. V4 was closer to GPT-5 and about eight months behind the frontier in the U.S. on CAISI's pre-committed suite, which has held-out tests like the semi-private ARC-AGI-2 set, as well as its own PortBench. This is not unique to one lab, as CAISI had previously measured gaps between self-reported and independent scores with U.S. models in its previous report.

Similarly, safety numbers on model cards provide the publisher's evaluations. Pay attention to benchmarks that are still held out, more than one independent evaluator, revealed methodology, and results for the actual version you will implement.

Evaluate Agentic Susceptibility Separately from Chat-Only Jailbreak Resistance

A model break is an attack by the user against the model. Agent hijacking occurs when an attacker puts instructions in data the agent reads, generally an e-mail, web page or tool response, and the user is the victim. For CAISI, hijacking is defined as indirect prompt injection and is treated as such, as a model can say it does not want to do a direct chat and still carry out the instruction provided in the content it was asked to summarize.

Test it directly. Seed tool output with injected instructions and count attempted actions (not just completed actions) like CAISI:

Subject: Re: invoice #4471

Thanks, see attached.

<

<

<

Cover the outcomes CAISI observed: credential exfiltration, outbound phishing, and download-and-execute.

Confirm Data Residency and Infrastructure Terms Before Deployment

Before deployment, confirm Data Residency & Infrastructure Terms.

Before publishing a hosted model, have written answers to a short list of questions:

• Where is inference running and where are prompts and logs stored?

• Inputs: How long are the inputs held, and are they used for training?

• What privacy terms apply to API traffic, as opposed to the consumer app?

• Who are the subprocessors, and what is the commitment to notify?

If a model is self-hosted, the corresponding checks are the earlier-mentioned loader code review, pinned revisions, and verified weights.

What This Means for Enterprises Choosing a Model

None of this implies that DeepSeek or any open-weight model isn't allowed. It indicates that there are more inputs to a decision than a benchmark and a price, and the controls that are in place around a model should reflect what testing revealed.

Performance and Cost Aren't the Only Variables in a Model Decision

There are cost benefits with each iteration. CAISI discovered a U.S. reference model that is 35% cheaper on average than the best-performing DeepSeek model of similar performance in September 2025. It outperforms GPT-5.4 mini on 5 out of 7 metrics by April 2026 and was more economical on the five. A price comparison is a “snapshot.”

There are also costs of reasoning models that are not charged on a rate card. HiddenLayer noted prompts that caused R1 to enter a recursive loop until they timed out, effectively being a denial-of-wallet attack vector. Include the expense of the guardrails and monitoring that the weaker-refusing model requires. Cheaper per token, but requiring a heavier control layer may not be cheaper to run safely.

Different Models May Warrant Different Guardrail and Monitoring Intensity

Adjust controls for model and use case pairing. No tools, internal summarization with some minor refusals is a modest exposure. The same model in the context of email, file, and payment capabilities must be enforced with strict tool allowlists, human approval for outbound or irreversible actions, scanning of retrieved content for injected instructions, output filtering for sensitive data, and greater logging.

Make those settings based on your own red team results. There is no single guardrail policy, and if the one that is in place is applied to all models, it either over-restricts the strong ones or under-protects the weak ones.

How Akto Helps Secure Deployments Regardless of Model Choice

All of the above controls are outside the model, which is why they continue to function if the model changes. This is what Akto's AI Agent Security Platform protects.

Continuous Red Teaming Across Any Model in Your Stack

The first issue with the article is that published scores reflect another configuration, and each of the new variants can change the scores, such as R1, R1-0528, and V3.2-Speciale. Akto orchestrates a red teaming process that includes automated attacks on the discovered MCP servers and AI agents, including 1,000+ probes for prompt injection, privilege escalation, data leakage, and misuse of tools, in addition to validating agent behavior during CI/CD. A model swap becomes a pipeline event and runs the suite again against your application before the change ships.

Runtime Guardrails That Compensate for Weaker Native Model Safety

If the model's own refusals are not getting the job done at Cisco's pace, enforcement must be from somewhere else. For homegrown agents and apps, Akto Argus provides protection from prompt injection, data exfiltration, and exposing sensitive data in the request path, which means that the act of blocking an attack is not dependent upon the model's decision to refuse. The data residency issue: its companion product, Atlas, provides visibility and guardrails for the employees using the AI agents, LLMs, and MCP tools on their own devices, such as a hosted chatbot they copy and paste source code into.

Model-Agnostic Monitoring for Agentic Behavior

CAISI's hijacked agents wrought their evil through acts: sending e-mail, downloading files, moving credentials. Continuous monitoring and behavioral detection help Akto detect and prevent agent loops, unauthorized tool calls, and excessive tool usage that forms a denial-of-wallet attack. It discovers agents, MCP servers, and tools on infrastructure, cloud, and employee laptops and maps the models of each agent in an agent context graph to bring to the forefront the unsanctioned self-hosted deployment. It's not based on the model's response, so the controls remain effective even if the model changes.

Final Thoughts on DeepSeek and Frontier Model Security Risks

The lesson to be learned: don't use a model swap as a performance choice. Run every new frontier or open-weight model ship within your own application, test agent hijacking without chat jailbreaks, and verify the location of inference runs and the code the loader executes.

The security risks discussed here correspond to the security controls Akto offers. If a refusal fails to withstand algorithmic jailbreaks, it is detected by ongoing agentic red teaming, which is rerun on each model update. Runtime guardrails against prompt injection and data exfiltration, coupled with behavioral detection of unauthorized tool calls, contain hijacked agents. Agents and models are discovered, leading to the exposure of unsanctioned deployments and employee usage of foreign-hosted chatbots. Request a Agentic Security demo and experience these controls working for your AI stack, no matter the model you're operating on.

FAQs on DeepSeek and Frontier Model Security Risks

Do performance benchmarks tell you anything about a model's security posture?

Not directly. A leaderboard is to measure the capacity of a model and not the capacity of what it will not do or what instructions it will obey within an agent. What they do reveal is the degree of difficulty: A model with a high score for cyber and coding abilities lends an attacker assistance when the defenses are compromised. Along with jailbreak and hijacking results, CAISI reports cyber benchmarks like Cybench, and these should be read in conjunction with each other.

What data residency concerns apply to models hosted outside your own jurisdiction?

Three questions matter. Firstly, whose law can force access to your prompts, outputs, and logs, as a contract with the provider cannot outpace the law of the land where the data resides. Second, whether it's a regulated cross-border transfer under GDPR for transfers outside the EU without adequate safeguards is another question. Third, do the sector rules and regulations that regulate your information allow that location? Third, does your sector have a rule or regulation that allows for that location? Keep in mind, prompts can include more than what users are expecting, such as source code and customer records.

How can guardrails compensate for a model with weaker native safety alignment?

By taking the decision on safety outside the model. Checks can be done at three locations: on input, to prevent injection and jailbreaks from reaching the model; at the tool layer, to comply with the policy on each call to it, regardless of what the model called; and on output, to prevent sensitive data or unsafe content from being returned to the user. A Cisco report also advises enterprises to rely on third-party guardrails for uniform protection for AI applications called DeepSeek. Similarly, weak models do not become strong models by adding a guardrail, and it can be bypassed as well (at least by the same attacks that you run against it when red teaming the model).