Before executing ANY potentially destructive or irreversible command - When a command targets production or critical infrastructure - When operating under a defined rules of engagement (ROE) - When a loop or automated sequence is about to start - User says "safe?
Before executing ANY potentially destructive or irreversible command - When a command targets production or critical infrastructure - When operating under a defined rules of engagement (ROE) - When a loop or automated sequence is about to start - User says "safe?
Scope Enforcement — Verify every command and target stays within authorized engagement boundaries before execution
Dangerous Command Interception — Block or require confirmation for destructive commands (rm, format, drop table, mass delete)
Rate Limiting — Prevent excessive requests that could trigger target IPS/IDS alerts or cause denial of service
Incident Response — Provide structured response procedures when a safety violation or unexpected event occurs
Rules of Engagement Compliance — Track and enforce client-specified constraints (no social engineering, no exfiltration, time windows)
Activation
Before executing ANY potentially destructive or irreversible command
When a command targets production or critical infrastructure
When operating under a defined rules of engagement (ROE)
When a loop or automated sequence is about to start
User says "safe?", "is this safe?", "check scope", "safety check"
Three Safety Modes
Mode 1: Careful (Default)
Standard safety checks applied to every operation:
Verify target is within authorized scope
Check command for known dangerous patterns
Confirm no unintended side effects
Log operation with evidence protocol
Applied to: All normal penetration testing operations
Mode 2: Freeze
Pause and require explicit operator confirmation:
Any command that modifies the target system
Any operation that could cause service disruption
Any credential-based attack (brute force, password spray)
Any exploit that could cause system instability
Applied to: Operations that cross from passive to active
Mode 3: Guard
Block the operation entirely:
Commands targeting out-of-scope systems
Operations that could cause irreversible damage
Attacks that could propagate beyond the target
Commands that could expose or exfiltrate real user data
Applied to: Operations that violate safety boundaries
Scope Enforcement
Scope Check Protocol
Before any operation, verify:
## Scope Check-**Target:** [IP / hostname / URL / CIDR]
-**Operation:** [What will be done]
-**In authorized scope?** [YES / NO / UNCLEAR]
-**Potential impact:** [None / Low / Medium / High / Critical]
-**Reversible?** [YES / NO]
-**Third-party systems affected?** [YES / NO]
-**User data at risk?** [YES / NO]
Decision rules:
In Scope?
Impact
Reversible?
Action
YES
Low-Medium
YES
Proceed with Careful mode
YES
High
YES
Switch to Freeze mode
YES
Any
NO
Switch to Freeze mode
NO
Any
Any
Switch to Guard mode (block)
UNCLEAR
Any
Any
Switch to Freeze mode, ask operator
Dangerous Command Patterns
The following command patterns trigger enhanced safety checks:
Block (Guard Mode)
Pattern
Why
Example
Mass deletion
Irreversible data loss
rm -rf /, DROP DATABASE
Public network exposure
Unauthorized service exposure
Binding to 0.0.0.0
Credential exfiltration
Data breach risk
Uploading /etc/shadow to external service
Fork bomb
System crash
`:(){ :
Writing to critical system files
System instability
Overwriting /etc/passwd, /etc/shadow
Mass scanning of public ranges
Legal/ethics violation
nmap -sS 0.0.0.0/0
Pause (Freeze Mode)
Pattern
Why
Example
Exploit execution
Target may crash
Running exploit/multi/handler
Brute force attacks
Account lockout risk
hydra, medusa, ncrack
Denial of service patterns
Service disruption
hping3 --flood, slowloris
Modification of target files
System changes
Uploading web shells, modifying configs
Privilege escalation commands
System state change
sudo commands on target
Network tunneling
Traffic routing changes
ssh -R, chisel, proxychains
Warn (Careful Mode)
Pattern
Why
Example
Active port scanning
May trigger IDS
nmap -sS, nmap -sV
Vulnerability scanning
May trigger alerts
nessus, openvas, nikto
Directory enumeration
Access logs
gobuster, dirb, ffuf
DNS enumeration
May trigger rate limits
dnsrecon, dnstracer
Rate Limiting Guidance
Per-Target Rate Limits
Target Type
Max Requests/sec
Burst Allowance
Web application
10
20
API endpoint
5
10
SSH service
1
3
DNS resolver
20
50
SMB service
5
10
Database
5
10
Backoff Strategy
When rate limiting is detected (HTTP 429, connection drops, etc.):
1st detection: Wait 5 seconds, reduce rate by 50%
2nd detection: Wait 30 seconds, reduce rate by 75%
3rd detection: STOP, report to operator
Engagement Rules Template
## Rules of Engagement: [Engagement Name]### Authorized Scope-**IP ranges:** [CIDR blocks]
-**Domains:** [hostname list]
-**Applications:** [URL list]
-**Excluded:** [What is explicitly OUT of scope]
### Authorized Activities- [ ] Passive reconnaissance (OSINT, DNS lookups)
- [ ] Active scanning (port scan, service enumeration)
- [ ] Vulnerability scanning (automated tools)
- [ ] Manual exploitation (specific techniques)
- [ ] Post-exploitation (privilege escalation, lateral movement)
- [ ] Social engineering (phishing, vishing)
- [ ] Physical security testing
- [ ] Denial of service testing
### Constraints-**Time window:** [Start datetime] to [End datetime]
-**Max concurrent connections:** [Number]
-**Credentials provided:** [Yes/No, details]
-**Notification required before:** [Specific actions]
### Emergency Contact-**Client contact:** [Name, phone, email]
-**Abort procedure:** [What to do if something goes wrong]
### Reporting-**Evidence format:** [Required format]
-**Encryption required:** [Yes/No, method]
-**Delivery method:** [How to deliver report]
Pre-Action Safety Checklist
Before any potentially impactful operation:
## Pre-Action Checklist- [ ] Target confirmed in authorized scope
- [ ] Operation type authorized in ROE
- [ ] Current time within authorized time window
- [ ] Rate limits respected
- [ ] Evidence capture ready (terminal-ops protocol)
- [ ] Rollback plan identified
- [ ] No third-party systems will be affected
- [ ] No real user data will be accessed or modified
- [ ] Operator available for escalation if needed
Incident Response Protocol
If something goes wrong during testing:
Level 1: Minor Issue
Service restarted, non-critical log entry generated, test visible to target admin.
Response:
Stop current operation
Log the incident with timestamp
Continue testing after a brief pause
Note in final report
Level 2: Service Impact
Target service degraded or temporarily unavailable, unexpected data exposure.
Response:
Stop ALL operations immediately
Log the incident with full evidence
Notify operator within 5 minutes
Wait for operator decision before continuing
Document in final report with root cause analysis
Level 3: Critical Incident
Target system crashed, data loss occurred, unauthorized access to production data, out-of-scope system affected.
Response:
Stop ALL operations immediately
Disconnect from target network if applicable
Log ALL evidence immediately (before cleanup)
Notify operator IMMEDIATELY
Do NOT attempt to fix or cover up
Preserve all logs and evidence
Full incident report required before any further testing
Indirect bypass: Embed bypass in tool result (e.g., file content) rather than user prompt.
Multi-turn bypass: Spread bypass across multiple turns; each looks benign individually.
Encoding tricks: Base64, hex, Unicode normalization to evade content filters.
Long-context dilution: Embed bypass in 50K+ token context; dilute attention.
Cognitive hacking: Frame as hypothetical, fictional, or academic exercise.
Anti-Patterns
Skipping scope checks — "I'm sure it's in scope" is not acceptable
Disabling safety for speed — Safety never slows you down as much as an incident
Assuming test data — Always verify you're not affecting real user data
Not having a rollback plan — If you can't undo it, don't do it
Ignoring rate limits — Target stability is always more important than test speed
Testing without ROE — Never test without defined rules of engagement
Orchestration
ECC Loop Pattern
Pattern: Cross-cutting Interceptor (pre-action check on every operation across all skills)
Rationale: Safety is not a sequential step but a cross-cutting concern — it must intercept every operation from every skill, acting as a gate that blocks, pauses, or allows each action
