Usage Policy

1. How screening works

Before a request reaches any model, our gateway screens the user-authored text of the request for clearly harmful cyber-attack intent. System prompts, developer instructions, and assistant messages are not screened — only the text you write.

Screening looks for actionable, unauthorized framings — a request that asks for offensive capability against systems or people. It does not block security terms alone: words like “exploit”, “password”, or “injection” are common in legitimate security work and are not violations by themselves.

Requests are screened with bounded resource limits. Requests too large to screen (over 40,000 characters of user text, or an excessively nested structure) are rejected before dispatch with a clear error and are never charged, and never counted as a violation.

2. Blocked categories — high confidence

Requests matching these categories are blocked regardless of framing:

• Ransomware and destructive malware. Building, coding, or deploying ransomware, crypto-lockers, or file-encrypting malware.
• Malware and spyware creation. Creating keyloggers, remote access trojans, botnets, command-and-control infrastructure, backdoors, rootkits, spyware, stealers, or worms.
• Security-tool evasion. Bypassing, evading, or disabling antivirus, EDR, Windows Defender, AMSI, or similar endpoint protection.
• Credential harvesting. Harvesting, stealing, dumping, or exfiltrating passwords, credit card data, cookies, session tokens, browser data, or two-factor codes.
• Phishing and credential traps. Creating phishing pages, spear-phishing content, fake login pages, or credential-harvesting sites.
• Attacking specific targets. Hacking, breaching, or gaining unauthorized access to a specific website, server, network, account, database, or device — including social-media accounts, Wi-Fi networks, routers, or phones.
• Explicitly unauthorized intrusion. Any request that explicitly states it targets a system without permission, authorization, or the owner’s knowledge.
• Unauthorized surveillance. Spying on, monitoring, or tracking people, systems, or communications without authorization.

3. Blocked categories — medium confidence

Requests matching these categories are blocked unless the request is framed defensively or educationally:

• Working exploit development. Writing or providing working, functional, or ready-to-use exploits, payloads, shellcode, or privilege-escalation scripts.
• Targeted CVE exploitation. Building exploits or proofs-of-concept intended to achieve code execution or unauthorized access on a target.
• SQL injection attacks. Crafting SQL injection attacks to dump databases, extract data, or bypass authentication on a specific target.
• Cross-site scripting attacks. Building XSS payloads to steal cookies or sessions, or to bypass filters on a specific target site.
• Brute-force and credential stuffing. Building brute-forcers, password crackers, or credential-stuffing tools aimed at accounts, services, or networks.
• WAF and authentication bypass. Circumventing web application firewalls, Cloudflare, CAPTCHAs, rate limits, or two-factor authentication.
• Intrusion persistence. Lateral movement, privilege escalation, persistence mechanisms, pass-the-hash, or maintaining access to compromised systems.
• Covert data exfiltration. Smuggling or hiding data through DNS, covert channels, or past data-loss prevention and firewalls to avoid detection.
• Social engineering. Crafting social-engineering attacks, pretexts, vishing, smishing, or impersonating support, staff, or executives.

4. Defensive and educational use is allowed

The following framings are explicitly permitted and are not violations:

• Protecting, preventing, defending, securing, hardening, mitigating, detecting, patching, or fixing against attacks
• OWASP references, security audits, secure coding, and vulnerability management or remediation
• CVE analysis, mitigation, detection rules, write-ups, and advisories
• Educational framings: explaining concepts, understanding how attacks work in principle, coursework and study
• Capture the flag (CTF), hackathons, lab exercises, and exam preparation
• Your own systems, authorised testing, explicit permission, bug bounty participation, and responsible disclosure
• Defensive and blue-team work: incident response, forensics, threat modelling, SIEM and SOC analysis
• Writing tests, linting, static analysis, and security code review

High-confidence operational attacks (section 2) are blocked even with a defensive framing.

5. Provider refusals

Model providers enforce their own usage policies in addition to this one. When a provider refuses a request for policy reasons, that refusal is final for the request: our gateway does not re-dispatch the same request to another provider or model. Repeated attempts to obtain the same refused output may be blocked.

6. Violations and suspensions

High-confidence violations are blocked and recorded against your key. Suspensions escalate per key: 30 minutes for the first violation, 1 hour for the second, and 24 hours for the third and subsequent violations. Violation records decay after 7 days without further violations.

Blocked requests are not charged. Suspensions apply to the key that made the request, not your other keys.

Screening failures, timeouts, and oversized requests never count as violations and never cause suspensions.

7. Rate and concurrency limits

Each key is subject to the rate limit and concurrency limit set at issuance (default 40 requests per minute, 10 simultaneous requests). Exceeding them returns a retryable rate-limit error and is not a violation.

8. Changes

We may update this policy at any time to reflect changes in enforcement, security, or law. Changes are announced at the time they take effect through our official channels. Enforcement changes apply to requests made after the change.