AI Prompts Library

Review this agent execution sandbox. Assume the agent will eventually run adversarial code, either because a user asked it to or because injected content told it to.

Assess:
1. FILESYSTEM: what can it read outside the workspace? Write? Are credentials, SSH keys, cloud metadata or environment files reachable?
2. NETWORK: outbound allowed? To where? Can it reach internal services, cloud metadata endpoints, or exfiltrate to an arbitrary host?
3. PROCESS: can it spawn long-running processes, escape the process tree, or survive the session?
4. RESOURCE LIMITS: CPU, memory, disk, execution time. What happens when it hits them?
5. SECRETS: what is in the environment? Anything that should not be?
6. PERSISTENCE: can state written in one run be read in the next, and should it be?
7. HOST BOUNDARY: container, VM, or neither? Be honest about what a container does and does not isolate.

Rank findings by severity and give the concrete fix for each.

Sandbox setup:
[DESCRIBE]

Assess whether we should self-host [MODEL] instead of using a hosted API.

Cover, with numbers:

1. HARDWARE: minimum viable configuration at each quantisation level, and what quality you lose at each. VRAM, system RAM, and whether it fits on one node.
2. THROUGHPUT: realistic tokens per second on that hardware, at batch size 1 and under concurrency.
3. TOTAL COST OF OWNERSHIP: hardware or instance cost, power, and the engineering time to run it. Compare against the hosted API bill at my volume, and state the break-even request volume.
4. WHAT YOU GIVE UP: no managed uptime, no automatic model updates, you own the incident response.
5. WHAT YOU GAIN: data never leaves, fixed cost, no rate limits, ability to fine-tune.
6. VERDICT with the break-even point stated explicitly.

Volume:
[REQUESTS PER DAY, AVERAGE TOKENS]
Constraints:
[COMPLIANCE, TEAM SIZE, EXISTING INFRA]

You are a disaster recovery specialist. Create a comprehensive DR plan for the described system.

**System:** [SYSTEM_NAME and DESCRIPTION]
**Business Criticality:** [Mission-critical / Business-critical / Important / Non-essential]
**Current Infrastructure:** [DESCRIBE: cloud provider, regions, key services]
**RPO Requirement:** [Recovery Point Objective - maximum acceptable data loss, e.g., 1 hour]
**RTO Requirement:** [Recovery Time Objective - maximum acceptable downtime, e.g., 4 hours]
**Compliance:** [ANY_REQUIREMENTS]

**Generate a Disaster Recovery Plan:**

1. **Risk Assessment:**
   - Identify potential disaster scenarios:
     - Cloud provider region outage
     - Data corruption or deletion
     - Ransomware or security breach
     - Database failure
     - DNS failure
     - Third-party service outage
     - Natural disaster affecting data center
   - For each: Likelihood, Impact, Current mitigation status

2. **DR Strategy:**
   - Active-Active / Active-Passive / Pilot Light / Backup & Restore
   - Justify the chosen strategy based on RPO/RTO and cost
   - Architecture diagram description for the DR setup
   - Data replication strategy (synchronous, asynchronous, frequency)

3. **Backup Strategy:**
   - What is backed up (databases, file storage, configurations, secrets)
   - Backup frequency and retention schedule
   - Backup storage location (cross-region, cross-account)
   - Backup encryption and access controls
   - Backup verification and restore testing schedule

4. **Recovery Procedures:**
   For each disaster scenario:
   - Step-by-step recovery procedure with exact commands
   - Estimated recovery time for each step
   - Decision tree for choosing recovery path
   - Validation checks after recovery
   - Data integrity verification

5. **Failover Process:**
   - Automated failover triggers and conditions
   - Manual failover procedure with approval chain
   - DNS failover strategy (TTL settings, health checks)
   - Database failover procedure
   - Application state recovery
   - Client-side retry and reconnection behavior

6. **Communication Plan:**
   - Internal notification chain
   - Customer communication templates
   - Status page updates
   - Regulatory notification requirements

7. **Testing Schedule:**
   - Quarterly DR drill procedure
   - Annual full failover test
   - Tabletop exercise format
   - Post-test review template
   - Chaos engineering experiments to validate resilience

8. **Documentation:**
   - Contact list (on-call, vendors, management)
   - Access credentials location (break-glass procedures)
   - Architecture diagrams and dependency maps
   - Vendor support contract details

**Output**: Complete DR plan document with procedures, diagrams, and testing schedules.