Why an abliterated model matters for offensive work

A general purpose assistant stops in the middle of ordinary security work. Ask it to explain the SQL injection in a login form you were hired to test, to write a proof of concept for an IDOR you already found, or to read shellcode out of a sample in your lab, and the reply is often a refusal or a short lecture. The task was in scope. The tool was the problem.

NotHoly serves abliterated open-weight models that do not carry that reflex. The question reaches the model and the model answers. What abliteration is explains the method; this piece is about why it changes the work.

#What abliteration does

Abliteration removes the refusal direction from an existing model's weights and leaves the rest in place. A 2024 study by Arditi and colleagues traced most refusals in open models to a single direction in the activations, and found that removing it lowers the reflex to decline without retraining the model (the paper). The models page states the result in one line: every model in the catalog is an abliterated open-weight model whose refusal behavior was taken out by editing its weights. The base of each one is named there, so you always know which open model you reached.

The effect is fewer dead ends on work that was never in question. A pentester reading a client's code, a bug bounty hunter writing a payload for a program that pays for it, a reverse engineer explaining a disassembly, an analyst triaging a sample: none of them is helped by a model that argues about whether the request is permitted. Scope comes from your contract, your client and your program's rules, and the model stays out of that decision.

#It is still a model

Removing the refusal does not make the output true. These models hallucinate, name a CVE that does not apply, and write code that does not build, like any model. The models page says to check the output like any other source, and that holds. NotHoly publishes no benchmark of its own and promises no correctness. The surfaces around the model exist for that reason: the chat shows the page it read, the knowledge base keeps a licence and attribution on every passage, and a CVE record carries the date each source was fetched. Read an answer as a lead you confirm, not a finding you ship. What we hold and what we do not is written down.

#Send it the question that got refused

The models take an OpenAI-compatible request. Point the base URL at NotHoly, read a model ID from the catalog, and ask.

curl https://api.notholy.com/v1/chat/completions \
  -H "Authorization: Bearer $NOTHOLY_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model": "MODEL_ID", "messages": [{"role": "user", "content": "Explain the IDOR in this endpoint and write a proof of concept."}]}'

The same question runs in the chat, in the terminal and in the editor extension, against the same catalog.

#Where it fits

It fits reverse engineering, pentest, bug bounty, red team, OSINT, phishing for an engagement, malware analysis and vulnerability research. These are the questions a security model should take and a general assistant often will not. The model reasons over what you bring it: the code, the disassembly, the sample, the page you already pulled.

#Where it does not fit

It does not fit if you want a model that declines anything sensitive on its own. It does not move the responsibility for how you use an answer, and NotHoly's servers never scan or send traffic to a target. The weights are not ours and we do not retrain them, so a base model's gaps and biases travel with it. An abliterated model can still hedge or refuse now and then, because the method lowers the reflex rather than removing the knowledge behind it. It is also not anonymous: an account needs a working e-mail, and the chat keeps your conversations unless you open an ephemeral one.

If your work keeps stopping at a wall that has nothing to do with scope, the wall is the tool. Put a small amount on pricing and send it the request that got turned down.