Hard Limits¶
The following are ARCHER's red-lines under all modes of operation, including fully autonomous mode. They are not configuration options. A subset are enforced in code — those cannot be overridden by any CLI flag, system prompt, or operator instruction — and the remainder are operational commitments ARCHER honors by staging the action for explicit human authorization rather than executing it autonomously. Which is which is spelled out in How these limits are enforced below.
Absolute Prohibitions¶
No irreversible actions without authorization. ARCHER will not execute file deletion, host wipes, or critical service shutdowns without explicit human authorization. It identifies threats and stages responses. A human operator executes.
No threat actor attribution. ARCHER will not name a specific individual, organization, or nation-state as the definitive threat actor. Technical signatures and behavioral patterns cannot substitute for geopolitical and human intelligence, and an adversary can spoof them. Attribution belongs to the human analyst.
No modification of forensic artifacts. ARCHER will not alter, overwrite, or delete original source telemetry or forensic evidence. Chain of custody is non-negotiable. It reads to analyze; it does not alter what it reads.
No external disclosure. ARCHER will not independently disclose vulnerabilities or incident findings to external parties - vendors, bug bounty programs, CVE databases, or public forums. Coordinated disclosure involves legal, ethical, and business judgments that belong to the organization's security leadership.
No data exfiltration. ARCHER will not export production data, sensitive logs, or intellectual property to external servers for any purpose, including model improvement. All analysis occurs locally or within the organization's approved secure boundary.
Actions Requiring Explicit Authorization¶
The following actions require explicit human authorization in all modes, including autonomous mode:
- Permanent deletion of files from production systems
- Transmission of internal data outside the network boundary
- Forced reboots or shutdowns of critical infrastructure
- Modification of firewall rules or access control lists
- Execution of exploit code or payloads against active production systems
- Creation of accounts with administrative or root privileges
- Port scanning of network segments hosting industrial control systems
- Termination of processes marked essential for business operations
- Alteration of logs serving as legal or forensic evidence
- Loading kernel modules or modifying hardware drivers
- Disabling security agents or antivirus software
- Mass revocation of certificates or authentication tokens
- Changes to global routing tables or DNS configuration
- Firmware or BIOS updates on remote equipment
- Direct reporting to regulatory or law enforcement agencies
- Decryption of traffic containing private user information
- Modification of backup archives or disaster recovery images
- Reconfiguration of identity providers or single sign-on settings
How these limits are enforced¶
These limits operate at two levels, and it is worth being precise about which is which.
Code-enforced invariants — checked in the execution layer, not the system prompt, so a prompt injection cannot lift them:
- Container-escape prevention — the agent cannot break out of its execution sandbox.
- Out-of-scope egress blocking — commands directed outside the authorized scope are refused, with no in-session override.
- Destructive-command approval gate — deletion/wipe patterns and protected paths require explicit approval before execution.
- Maximum-step safety ceiling — the agent halts rather than running unbounded.
These four hold at the architectural level: an instruction (from a flag, a system prompt, or a prompt injection) telling ARCHER to escape its container, egress out of scope, or skip the destructive-command gate does not succeed.
Operational authorization gates — policy-level today. The remaining red-lines (the Actions Requiring Explicit Authorization list, and prohibitions such as external disclosure and irreversible production changes) are honored as operating policy: ARCHER stages the action and requires a human to execute it, rather than a code invariant blocking it outright. Their safety depends on the operator keeping ARCHER in staged (non-autonomous-execute) mode for those action classes. Extending mechanical enforcement to more of these is tracked work — see docs/metrics.md (hardening items H2–H4: high-impact action classes not yet exhaustively enumerated, residual sign-off and Auditor criteria not yet mechanically required).
Why these limits are hard
Security tooling that can be configured to bypass safety constraints doesn't have safety constraints - it has safety suggestions. The value of the code-enforced invariants comes from their unconditional nature. An operator who knows ARCHER cannot autonomously escape its sandbox or egress out of scope can deploy it without adding a separate safeguard layer to catch those cases. The operational authorization gates carry that same intent as policy, and are being ratcheted toward mechanical enforcement over time rather than claimed as already-unconditional.