Cyber defense
When a coding model refuses your own security work: using the Defense section responsibly
Security work on your own systems should not stall because a model refused it. Most coding models are cautious with anything that looks like an attack, and that caution can get in the way of ordinary application security
Security work on your own systems should not stall because a model refused it. Most coding models are cautious with anything that looks like an attack, and that caution can get in the way of ordinary application security work. free-pi is adding an opt-in Defense section to its model picker for this. This post explains what it is for, when to use it, and the ground rules.
The problem
Ordinary AppSec tasks can look alarming to a general-purpose model:
- Writing a proof of concept so you can show your team that a bug is real.
- Explaining how an injection flaw in your own handler would be exploited, so you can fix it properly.
- Checking your own login flow for weak points.
- Reading a binary you are licensed to analyze, to see what it does.
When a model declines these, the defender gets less help than an attacker would. You lose time, and you end up rewording requests.
What the Defense section is
Defense is a section of the /model picker for signed-in GitHub users. You opt in by choosing a model from it. The first model is Defense Flash: a reasoning model with tool use and a 1M-token context window, chosen for lawful security work that general models often refuse. It is billed from your normal free-pi credits like any other model.
The picker is built from the server's model list, so the section appears only when your free-pi version and the server both include it. If you do not see it, update with npx free-pi-cli and look again.
We have not published tests of Defense Flash, so we do not know how it behaves on your tasks. Try it on your own work and judge it yourself. It is a tool for defenders and does not change what you are allowed to do.
Ground rules
Use it only for:
- Systems and code you own.
- Employer or client systems where you have written permission to test.
- Bug bounty targets, inside the program's stated scope and rules.
- Software you own or may lawfully analyze, using
/reverse-engineer-anything(native binaries, JS and Electron apps, APKs, .NET assemblies and websites).
Do not use it against anyone else's systems. Laws such as the US Computer Fraud and Abuse Act and the UK Computer Misuse Act apply to you whatever model you pick, and a program's scope list is a boundary, not a suggestion. If you are unsure whether you are authorized, find out first.
Habits that keep your work safe
- Say the context. Start with who owns the system and what you are allowed to do, for example "This is my own staging app; I want to confirm whether this endpoint exposes other users' records, and then fix it."
- Ask for the fix. Aim every session at finding and fixing. Ask for the minimal patch and a test that fails before it and passes after.
- Run risky tests in an isolated environment. Use a local container or a disposable staging copy, never production, and keep real credentials out of it. free-pi has no OS sandbox of its own for normal sessions.
- Check the output. A model can be confidently wrong. Reproduce a claimed flaw yourself before you report it, and review every generated patch.
- Keep a scope note. For bounty work, paste the program's scope into the session and keep to it.
Pairing it with the audit method and REA
free-pi bundles the audit method and reference checklists from the security-audit skill (see our guide to auditing your own repo). It runs in a single agent, so validate each finding yourself. /reverse-engineer-anything gives the agent reverse-engineering tools for software you may lawfully analyze. The Defense section is where you look for a model when a general one declines the lawful part.