Most AI security tools wrap a general-purpose model and hope prompt engineering keeps it from refusing to analyze dangerous code. Cosine’s Argus Red takes a different path: they post-trained a model specifically to perform offensive security testing instead of refusing it. The result is a CLI agent with two distinct modes (read-only scan and live pen test) and an authorization gate that sits between them.
The standard RLHF refusal training that makes models safe for general use also makes them useless for offensive security work. Argus Red’s approach exposes the architectural trade-offs when you train a model to do things most models are trained not to do.
Two Modes, One Model
The CLI offers two distinct operating modes:
Security Scan (read-only)
Analyzes code for vulnerabilities without touching live systems. Free to run with an active Cosine subscription ($20/month). Outputs a Markdown report with location, severity, cause, and fix direction for each finding.
Pen Test (active)
Attempts exploits against real systems. Gated behind written authorization, not a paywall. This is where the post-training matters: the model needs to generate working exploit payloads, not refuse to help.
The authorization gate is the critical boundary. Most tools either refuse offensive actions entirely or rely on prompt engineering to coax a general model into helping. Argus Red trains the model to perform offensive work, then gates access to that capability at the orchestration layer.
Post-Training for Offensive Capabilities
Standard RLHF trains models to refuse dangerous requests. That refusal behavior is baked into the weights. You can sometimes bypass it with prompt tricks, but the model is fighting you the whole time.
Post-training for offensive security flips this. The model learns to:
- Generate exploit payloads that actually work
- Reason about attack surfaces without hedging
- Propose privilege escalation paths
- Write code that intentionally violates security boundaries
This is not simply fine-tuning on exploit databases. It’s training the model to think like a penetration tester, which means teaching it to do things most models are explicitly trained not to do.
The trade-off: you get a model that’s genuinely useful for offensive security work, but you also get a model that can’t rely on refusal behavior as a safety mechanism. The safety boundary moves from the model layer to the authorization layer.
Architecture: Gating Offensive Actions
The research material indicates written authorization is required but does not specify the implementation mechanism (API token, signed document, email confirmation, etc.). This remains an implementation detail Cosine has not publicly disclosed.
What we know from the CLI documentation: the authorization check happens before the pen test session starts, not during execution. The model doesn’t decide whether to refuse. The orchestration layer decides whether to allow the session to start. Once the session is authorized, the model operates without refusal behavior.
Here’s illustrative pseudocode for how such a gate might work:
// Illustrative pseudocode, not Argus Red's actual implementation
interface PenTestSession {
authorization: WrittenAuthorization;
scope: SystemScope;
auditLog: AuditStream;
sandboxConfig: SandboxLimits;
}
async function initPenTest(config: PenTestConfig): Promise<PenTestSession> {
// 1. Verify written authorization exists
const auth = await verifyAuthorization(config.authToken);
if (!auth.valid || !auth.coversScope(config.targetScope)) {
throw new UnauthorizedError("Pen test requires written authorization");
}
// 2. Initialize audit stream
const auditLog = await AuditStream.create({
sessionId: generateSessionId(),
authorization: auth,
targetScope: config.targetScope,
startTime: Date.now()
});
// 3. Configure sandbox boundaries
const sandbox = {
networkAccess: config.networkAccess || "sandboxed",
fileWrite: config.fileWrite || "sandboxed",
terminalAccess: config.terminalAccess || "disabled"
};
return {
authorization: auth,
scope: config.targetScope,
auditLog,
sandboxConfig: sandbox
};
}Sandbox Configuration and Permission Boundaries
The CLI exposes three permission toggles before any scan or test runs:
| Permission | Read-Only Scan | Pen Test Mode | Risk |
|---|---|---|---|
| Terminal Access | Disabled | Sandboxed or Enabled | Arbitrary command execution in test environment |
| Network Requests | Disabled | Sandboxed or Enabled | Live exploit attempts against target systems |
| File Write | Sandboxed | Sandboxed or Enabled | Payload persistence and evidence collection |
In read-only mode, the agent analyzes code but cannot execute commands or make network requests. In pen test mode, you explicitly enable the permissions needed for active testing.
The sandboxed option is the middle ground: network requests go through a proxy that logs all traffic, file writes go to a temporary directory, terminal access is limited to a container. This gives the agent enough capability to test exploits without full host access.
Audit and Observability for Offensive Actions
When an agent is trained to exploit systems, audit logging becomes critical. The audit stream is initialized before the agent accesses offensive capabilities, as shown in the CLI setup flow. You need to know:
- What authorization was used to start the session
- What targets were scanned or tested
- What exploits were attempted
- What data was accessed or exfiltrated (even in a test context)
- What credentials or tokens were generated
The output format matters too. Argus Red writes Markdown reports with grounded findings: location in code, severity, cause, and fix direction. The sample report shows this structure:
# Bank of Anthos: Security Audit Report
29,846 LOC / 391 files · 6 of 8 modules
## 1. Executive Summary
Overall risk rating: CRITICAL
Multiple critical and high-severity vulnerabilities:
- Forgeable tokens across every ledger service
- Disabled JWT signature verification in frontend
- Integer overflow in financial transaction validation
- SSRF and open redirect in OAuth consent flowThis is scannable by humans and parseable by CI systems. The report becomes the artifact that proves the test happened and documents what was found.
Architectural Considerations for Offensive Agent Gating
Training a model to perform offensive actions introduces architectural questions that need answers at the infrastructure layer:
Credential isolation between modes
The boundary between read-only and pen test modes needs clear separation. If credentials or tokens leak from one mode to another, the authorization gate becomes meaningless.
Authorization scope binding
Written authorization needs to be bound to specific targets, time windows, and session contexts. A reusable bearer token that works for any target defeats the purpose of the gate.
Audit stream integrity
The audit log needs to be tamper-resistant. If the agent has write access to its own logs, the audit trail cannot be trusted.
Model control flow isolation
The authorization gate needs to live outside the model’s reasoning loop. If the model can be prompted to bypass its own authorization checks, the gate is decorative.
These are not theoretical risks. They’re the standard problems you face when building any system that performs privileged operations based on external authorization.
Technical Verdict
Argus Red’s approach solves a real problem: general-purpose models are bad at offensive security work because they’re trained to refuse it. Post-training a model specifically for pen testing removes the refusal behavior and makes the agent genuinely useful for offensive work.
The trade-off is that you move the safety boundary from the model layer to the orchestration layer. The model won’t refuse to help you exploit a system. The authorization gate and audit logging become the only things preventing misuse.
This is the right architecture if you’re building offensive security tooling. It’s the wrong architecture if you’re building a general-purpose coding assistant that sometimes needs to analyze security issues. The model’s training determines whether safety lives in the weights or in the infrastructure around it.
For teams running regular pen tests or red team exercises, this is a useful tool. The read-only scan is safe to run in CI. The pen test mode requires the same authorization process you’d use for a human pen tester. The audit logs give you the paper trail you need when something goes wrong.
Use it when you need an agent to generate working exploits and you have a clear authorization process for who can run offensive tests. You will also need hard boundaries between read-only and active testing modes, plus audit infrastructure that logs every offensive action.
Avoid this approach when you only need static analysis or vulnerability scanning, cannot enforce authorization at the orchestration layer, cannot guarantee audit logs are tamper-proof, or need the model itself to refuse dangerous requests.
The authorization gate needs to be enforced by infrastructure that the model cannot access or reason about. This is standard practice for any privileged operation, but it’s worth stating explicitly when the model is trained to think like an attacker.