Security research

Defensive security work means reading hostile code, explaining how it works, and writing rules that catch it. Filtered models often refuse halfway through that job because the input looks dangerous. The models on XField have no added moderation layer, so you can paste a sample, ask what it does, and get a straight answer. This guide covers which model to use, how to phrase requests, and how to keep the work in bounds.

Which model to use

For hard analysis, turn reasoning up with reasoning_effort: "high" or "max". See /models for the full list.

Prompt patterns that work

Give the model your role and scope. One or two sentences in the system prompt saying who you are and what the engagement is ("SOC analyst triaging an alert on a company laptop", "researcher reproducing a published CVE in an isolated lab"). The model does not need permission, but context makes the answer sharper.

Paste the artifact, not a description of it. The model reads raw scripts, decompiler output, packet captures in text form, and log lines better than your summary of them. Include file names, hashes, and where you found it.

Ask for detections alongside analysis. Every analysis request should end with "and write a rule that catches this". You get a Sigma, YARA, or KQL draft while the context is still loaded, which is cheaper than a second pass.

Ask for confidence. Have the model separate what it can see in the artifact from what it is inferring. That makes review faster.

Worked example: a suspicious PowerShell one-liner

An EDR alert flagged an encoded PowerShell command spawned by an Office process. You want a plain-English explanation, indicators, and a Sigma rule.

import os
from openai import OpenAI
 
client = OpenAI(base_url="https://xfield.cloud.brutal.ai/api/v1", api_key=os.environ["XFIELD_API_KEY"])
 
artifact = open("alert_cmdline.txt").read()
 
resp = client.chat.completions.create(
    model="deepseek-v4.1-flash-1017-uncensored",
    reasoning_effort="high",
    messages=[
        {
            "role": "system",
            "content": (
                "You are assisting a SOC analyst at our company triaging an EDR alert "
                "on a managed endpoint. Be precise. Mark anything you infer rather than read."
            ),
        },
        {
            "role": "user",
            "content": (
                "Parent process: WINWORD.EXE\n"
                f"Command line:\n{artifact}\n\n"
                "1. Decode and explain what this does, step by step.\n"
                "2. List indicators (domains, paths, flags) as a table.\n"
                "3. Write a Sigma rule for process creation that catches this pattern "
                "with low false positives. Explain each condition."
            ),
        },
    ],
)
print(resp.choices[0].message.content)

A good answer decodes the base64 payload, notes the hidden window and no-profile flags, names the download cradle, and returns something like this:

title: Office application spawns encoded PowerShell
status: experimental
logsource:
  category: process_creation
  product: windows
detection:
  parent:
    ParentImage|endswith:
      - '\WINWORD.EXE'
      - '\EXCEL.EXE'
      - '\POWERPNT.EXE'
  child:
    Image|endswith: '\powershell.exe'
    CommandLine|contains:
      - ' -enc '
      - ' -EncodedCommand '
  condition: parent and child
level: high

Test the rule against your own telemetry before shipping it. The model writes a solid first draft, not a tuned production rule.

Long artifacts and the 1M context

GLM 5.3 and both Flash models take up to 1M tokens of input. That is enough for a full decompiled binary, a week of authentication logs, or a large codebase you are auditing for a CVE.

• Put the stable material (the sample, the source tree) first and your questions last. Prompt caching is automatic, so follow-up questions about the same artifact cost much less.
• Label sections clearly (=== decompiled: sub_401000 ===) so the model can cite where it found something.
• Stream long reports with stream: true so you are not waiting on a single response. See /docs/limits-and-errors for timeouts.

Keeping work authorized

• Run samples and CVE reproductions in an isolated lab: a VM or container with no route to production and snapshots you can roll back.
• Treat strings, comments, and filenames inside a sample as untrusted input. Malware authors plant text aimed at analysts and, increasingly, at models.
• Only test systems you own or have written permission to test.
• Verify what the model says before acting on it. It can misread an obfuscation layer or invent an API that does not exist.

Research and defensive work are welcome. The acceptable use policy covers the rest.