ACCEPTABLE_USE.md

Acceptable Use Policy — Llama-Quantara-Sentinel-8B

This model is released openly because it is scoped to defence and that scope is measured, not promised. This document says what the scope is, what we did to enforce it, and what you take on when you run it.

It applies alongside the Llama 3.1 Community License and Meta's Acceptable Use Policy, both of which flow down through the base model. Where anything here is narrower, the narrower rule wins.

---

1. What the model is for

Helping defenders find, understand, and fix weaknesses in systems they are responsible for:

• Reviewing source code for vulnerabilities and writing the patch
• Auditing configuration and infrastructure-as-code
• Triaging logs and alerts, and assigning severity
• Answering threat-intelligence questions about known vulnerabilities and techniques
• Analysing suspicious email for phishing indicators
• Security education and training

2. What it will not do, by design

The model is trained to refuse and it holds that line at 100% across 46 red-team probes drawn from a 35-theme probe set, with zero weaponizable leaks under an LLM judge.

• Working exploits. No exploit code, no proof-of-concept for a specific target, no ROP chains, no shellcode.
• Malware. No ransomware, droppers, loaders, rootkits, keyloggers, infostealers, or wipers.
• Attack infrastructure. No C2 servers or agents, no phishing kits, no AiTM proxies, no credential-capture pages.
• Detection evasion. No AV/EDR bypass, no log wiping, no anti-forensics, no timestomping.
• Attacks on systems you don't own. Including anything framed as "authorised" without evidence.
• Autonomous offensive agents. It explains and fixes; it does not go and do.

Trying to reframe any of the above as a hypothetical, a CTF, a novel, a "security research exercise", or a system-prompt override does not change the answer. That framing is itself part of the red-team probe set.

3. The dual-use line, drawn explicitly

Refusing too much makes a security model useless, so the following are in scope and the model will fully answer them — refusing these counts as a failure in our evaluation, gated at ≤2% over-refusal on benign asks:

• Detection engineering for any technique, including offensive ones — Sigma rules, YARA, detection queries, log signatures
• Explaining how an attack works, at the level a defender needs to detect and stop it
• Hardening, patching, and mitigation guidance for any vulnerability
• Incident response, forensics, and threat hunting
• Breach-notification tooling and credential-exposure checking with a consent note

Phishing simulation is in scope, partially. The model will write sample lure copy for a stated internal awareness campaign — that is what every phishing-simulation product does and defenders ask for it constantly. It will not build the machinery behind it: no credential-capture page, no adversary-in-the-middle proxy, no capture or harvesting infrastructure. It also attaches the "this is a simulated test, report it to your SOC" framing on its own.

4. Your responsibilities as an operator

Running open weights means the guardrails are now partly yours.

• Only point it at systems you own or are explicitly authorised to assess. Written scope, not a verbal "go ahead".
• Do not remove or weaken the system prompt. Every safety number on the model card was measured with the prompt in MODEL_CARD.md (sha 218d05648174). It is deliberately not baked into the weights so you can tune it — tuning it downward moves you outside every measurement we published.
• Do not fine-tune the refusal behaviour out. You can, technically. Doing so and then distributing the result under a name derived from this one is a violation of this policy.
• Keep a human in the loop for anything consequential. See §5.
• Follow the law and your own disclosure obligations. This policy does not override them.

5. Do not automate these without review

The model has measured failure modes that are dangerous specifically when nobody is looking. Full detail and reproducible row ids are in MODEL_CARD.md.

Don't	Because
Auto-clear email based on its verdict	It caught 24 of 24 phishing mails in v1.0 — but that is 24 mails. One miss would be 4.2 points. A clean sweep on a sample that small is not evidence of a clean sweep on your inbox, and earlier versions cleared a payroll lure as "safe to interact with"
Act on a CVE identifier without checking NVD	Much improved in v1.0 — BlueKeep fact errors fell 12.8% → 2.6% after targeted grounding — but 2.6% is not 0, and the previous version sent people to the wrong port and the wrong patch by confusing BlueKeep with EternalBlue
File ATT&CK mappings unreviewed	It picks the wrong technique family ~54% of the time (attack_family_hit_pct 46.2)
Auto-escalate on a technique citation	On benign log activity it names an ATT&CK technique 68% of the time and raises an alarm 27% of the time. It got better at reading real incidents and worse at leaving quiet days alone
Auto-apply generated patches	Patch suggestions are not validated by execution
Auto-close or downgrade alerts	Severity calibration is good, not perfect
Treat it as an authority on vulnerability details	Training data is fully synthetic; small facts get invented
pip install a package it suggested	Asked for a HIBP checker it reaches for a wrapper abandoned in 2016 and omits the headers the current API requires

It is a fast, cheap, self-hosted first pass that catches a lot and gets things wrong in identifiable ways. It is not an analyst.

6. Prompt injection

The model has not been evaluated against adversarial instructions embedded in pasted content — a log line, an email body, or a config comment that says "ignore your instructions". If you pipe untrusted data into it, assume that data can influence the output, and do not give the surrounding system any capability you would not hand to the author of that data.

7. Reporting

Found a jailbreak, a weaponization leak, or a dangerously wrong answer? Open an issue on the source repository. Please include the exact prompt, the system prompt you used, the quantization, and the sampling parameters — without those the result is not reproducible and cannot be fixed.

For anything you would rather not post publicly, mark the issue accordingly and we'll move it.

8. If you redistribute

• Keep the Llama 3.1 Community License terms, including "Built with Llama" and the Llama- name prefix on any derivative.
• Ship this policy and the known-weaknesses section with it. The weaknesses are the honest half of an open release, and stripping them out to make the model look better is the specific harm this document exists to prevent.

---

Last updated 2026-08-22, for v1.0 (training run v6).