safety-guard

Safety Guard

Summary

Safety Guard skill domain covering defense operations.

Domain: defense

Use Cases

1. Scope Enforcement — Verify every command and target stays within authorized engagement boundaries before execution
2. Dangerous Command Interception — Block or require confirmation for destructive commands (rm, format, drop table, mass delete)
3. Rate Limiting — Prevent excessive requests that could trigger target IPS/IDS alerts or cause denial of service
4. Incident Response — Provide structured response procedures when a safety violation or unexpected event occurs
5. 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:

Dangerous Command Patterns

The following command patterns trigger enhanced safety checks:

Block (Guard Mode)

Pause (Freeze Mode)

Warn (Careful Mode)

Rate Limiting Guidance

Per-Target Rate Limits

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:

1. Stop current operation
2. Log the incident with timestamp
3. Continue testing after a brief pause
4. Note in final report

Level 2: Service Impact

Target service degraded or temporarily unavailable, unexpected data exposure.

Response:

1. Stop ALL operations immediately
2. Log the incident with full evidence
3. Notify operator within 5 minutes
4. Wait for operator decision before continuing
5. 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:

1. Stop ALL operations immediately
2. Disconnect from target network if applicable
3. Log ALL evidence immediately (before cleanup)
4. Notify operator IMMEDIATELY
5. Do NOT attempt to fix or cover up
6. Preserve all logs and evidence
7. Full incident report required before any further testing

Integration with Other Skills

Detection Methods

Safety Guard Service Audit

• Safety bypass attempts: Patterns indicating attempts to bypass safety checks (jailbreak signatures).
• False negative rates: Safety guard approving known-malicious content.
• Latency anomalies: Safety guard slower than baseline; service degradation.

SIEM Detection Rules

• Splunk SPL: index=safety guard.action="*" | stats count by action, reason | sort -count
• Custom safety metrics: Per-rule precision/recall tracking.

Defense Evasion Techniques

Safety Guard Bypass

• 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
• Integration: All skills (pre-action safety checks), autonomous-loops (scope lock enforcement, rate limiting), terminal-ops (pre-execution safety verification), docker-patterns (localhost-only binding verification)

Cross-Skill Pipeline

[any skill] → safety-guard → [proceed / freeze / block]
                   ↓
              autonomous-loops (abort conditions)
                   ↓
              chronicle (incident logging)

Quality Gate

• Pre-condition: Every operation passes through scope check and danger pattern matching
• Post-condition: Operation classified as safe (proceed), risky (freeze for confirmation), or dangerous (blocked)
• Verification: No operation executes without passing safety classification