CLI Trader
Validation & Infrastructure All Markets

Agent Trading Guardrails

Paste into Claude, ChatGPT, or any coding agent

This skill provides the comprehensive safety architecture for autonomous trading agents. When an AI agent is making trading decisions — whether fully autonomous or semi-autonomous — this skill defines the guardrails that prevent catastrophic losses, ensure human oversight, and maintain operational integrity. Every autonomous trading system MUST implement these guardrails before going live. This skill extends the agent-specific limits in Risk Management with a full operational safety framework.

When to Use This Skill

  • When designing or deploying an autonomous trading agent
  • When configuring API key permissions for a trading bot
  • When setting up kill switches and automatic halt conditions
  • When defining human-in-the-loop approval gates
  • When coordinating multiple agents that may trade the same assets
  • When monitoring agent performance for strategy drift
  • When reviewing agent audit trails
  • When recovering from a kill switch activation
  • When evaluating whether an agent should be granted more autonomy

What This Skill Does

  1. Risk Limit Architecture: Defines per-trade, daily, weekly, and total exposure caps for autonomous agents
  2. API Key Scoping: Specifies exact permissions, restrictions, and IP whitelisting for exchange API keys
  3. Kill Switch Design: Implements automatic halt conditions with specific triggers and escalation procedures
  4. Human Approval Gates: Defines when and how to require human sign-off on agent decisions
  5. Multi-Agent Coordination: Prevents conflicting trades and manages shared state between multiple agents
  6. Performance Monitoring: Tracks Sharpe ratio, strategy drift, and anomaly detection in real-time
  7. Audit Trail Requirements: Specifies what to log and how to review agent activity
  8. Recovery Procedures: Defines the process for resuming operations after a kill switch triggers

How to Use

Agent Setup

Set up trading guardrails for an autonomous agent trading BTC/ETH on Binance with a $50,000 allocation

Kill Switch Configuration

Configure kill switches for my trading bot — what conditions should trigger an automatic halt?

API Key Scoping

What permissions should my Binance API key have for an autonomous agent? How do I scope it safely?

Multi-Agent Coordination

I have 3 agents (momentum, mean-reversion, arbitrage) — how do I prevent them from conflicting?

Post-Incident Recovery

My agent hit the kill switch after a 6% drawdown. What's the recovery procedure?

Data Sources

With MCP/CLI tools connected:

  • Binance MCP (TermiX, snjyor) — API key management, position monitoring, order history
  • Bybit MCP — API key scoping, position tracking, risk parameters
  • OKX MCP — Sub-account management, API key permissions, trading limits
  • Empyrical MCP — Performance metrics (Sharpe, Sortino, max drawdown, VaR, Calmar ratio)
  • All exchange MCPs — Real-time P&L, position data, order status for monitoring

Without tool access: Ask the user to provide:

  1. Exchange(s) being used and API key permissions currently set
  2. Agent’s trading strategy description and asset universe
  3. Portfolio allocation to the agent
  4. Current agent configuration (limits, parameters)
  5. Historical agent performance data (if available)
  6. Number of agents and their strategy types (if multi-agent)

Proceed with guardrail design using provided data. Recommend specific configurations.

Methodology

Step 1: Agent Risk Limit Architecture

Define the layered risk limits that constrain agent behavior. These limits are HARD CAPS — the agent must not exceed them under any circumstances.

RISK LIMIT HIERARCHY (Agent-Specific):

  Account Level ─────────── Max total agent allocation from portfolio
    └── Agent Level ──────── Max per-agent allocation
         └── Daily Level ──── Max daily loss / max daily trades
              └── Trade Level ── Max per-trade risk / max position size

Risk Limit Configuration Table:

Limit CategoryConservative AgentModerate AgentAggressive Agent
Max portfolio allocation10%25%50%
Max per-trade risk0.25% of allocation0.5% of allocation1.0% of allocation
Max single position size3% of allocation5% of allocation10% of allocation
Max open positions358
Max daily loss1% of allocation2% of allocation3% of allocation
Max daily trades51550
Max daily volume5% of allocation10% of allocation20% of allocation
Max weekly loss3% of allocation5% of allocation8% of allocation
Max monthly loss5% of allocation10% of allocation15%
Max leverage1x (none)2x3x
Max correlated exposure5% of allocation10% of allocation15% of allocation

Limit Enforcement Rules:

  1. Limits are checked BEFORE every order is submitted
  2. If any limit would be breached by a proposed trade, the trade is BLOCKED
  3. Blocked trades are logged with the specific limit that was hit
  4. After a daily limit is hit, the agent MUST NOT open new positions until the next trading day (UTC reset)
  5. After a weekly limit is hit, the agent enters “monitor only” mode for the remainder of the week

Step 2: Scoped API Key Design

API keys are the agent’s access credentials to exchanges. Misconfigured keys are a security risk and a financial risk.

API Key Permission Matrix:

PERMISSION LEVELS:

LEVEL 1: READ-ONLY (for monitoring/analysis agents)
  ✅ View balances
  ✅ View positions
  ✅ View order history
  ✅ View market data
  ❌ Place orders
  ❌ Cancel orders
  ❌ Transfer funds
  ❌ Withdraw funds

LEVEL 2: TRADE-ONLY (for execution agents — RECOMMENDED)
  ✅ View balances
  ✅ View positions
  ✅ View order history
  ✅ View market data
  ✅ Place orders (spot + futures)
  ✅ Cancel orders
  ❌ Transfer funds between accounts
  ❌ Withdraw funds
  ❌ Create sub-accounts
  ❌ Modify API key settings

LEVEL 3: FULL ACCESS (NEVER use for agents)
  ✅ Everything
  ⛔ DO NOT USE — withdrawal access should NEVER be given to an autonomous agent

API Key Security Checklist:

MANDATORY SECURITY MEASURES:

1. IP WHITELISTING
   - Whitelist ONLY the specific IP(s) where the agent runs
   - For cloud agents: use static IP (Elastic IP on AWS, Reserved IP on GCP)
   - Never use 0.0.0.0/0 (allow all IPs)
   - Review whitelist monthly

2. KEY ROTATION
   - Rotate API keys every 90 days
   - After any security incident: rotate immediately
   - After any team member departure: rotate immediately
   - Keep old keys disabled (not deleted) for 30 days for audit

3. SEPARATE KEYS PER AGENT
   - Each agent gets its own API key pair
   - Never share keys between agents
   - Label keys clearly: "agent-momentum-btc-prod" not "key1"

4. SUB-ACCOUNTS (where supported)
   - Create a dedicated sub-account per agent (Binance, OKX, Bybit support this)
   - Transfer only the agent's allocation to its sub-account
   - Agent cannot access main account funds

5. SECRET STORAGE
   - Store API secrets in environment variables or secret manager
   - NEVER in source code, config files, or logs
   - NEVER in plain text on disk
   - Use: AWS Secrets Manager, GCP Secret Manager, HashiCorp Vault, or .env with restricted permissions

Exchange-Specific Key Scoping:

ExchangeSub-Account SupportIP WhitelistTrade-Only KeyWithdrawal Lock
BinanceYesYes (required)YesYes (separate toggle)
BybitYes (Unified)YesYesYes
OKXYes (Sub-account)YesYesYes
CoinbaseNo (use portfolio)YesYesYes (vault)

Step 3: Kill Switch Design

Kill switches are automatic halt mechanisms that stop agent trading when dangerous conditions are detected.

Kill Switch Trigger Categories:

CATEGORY 1: PERFORMANCE-BASED TRIGGERS (agent is losing money)

| Trigger | Threshold | Action |
|---------|-----------|--------|
| Per-trade loss | > 2× expected loss | Log warning, continue |
| Session drawdown | > 3% of allocation | HALT agent, notify human |
| Daily loss limit | Reached daily cap | HALT for remainder of day |
| Consecutive losses | 3 in a row | PAUSE 1 hour, notify human |
| Consecutive losses | 5 in a row | HALT agent, require human review |
| Weekly loss limit | Reached weekly cap | HALT for remainder of week |
| Sharpe degradation | Drops below 0.5 (rolling 30d) | Alert human, reduce size by 50% |
| Win rate collapse | Drops below 30% (rolling 20 trades) | HALT, strategy may be broken |

CATEGORY 2: MARKET-CONDITION TRIGGERS (market is abnormal)

| Trigger | Threshold | Action |
|---------|-----------|--------|
| Volatility spike | > 3 std dev move in 1 hour | PAUSE, wait for vol to normalize |
| Flash crash | > 10% price drop in 5 minutes | HALT, do not trade falling knife |
| Liquidity drought | Spread > 5× normal | PAUSE until spread normalizes |
| Funding rate extreme | |FR| > 0.1% per 8h | Reduce size by 50%, alert |
| Correlation breakdown | Portfolio correlation spikes >0.95 | HALT, risk model assumptions violated |

CATEGORY 3: SYSTEM/INFRASTRUCTURE TRIGGERS (something is broken)

| Trigger | Threshold | Action |
|---------|-----------|--------|
| API error | 3 consecutive errors | HALT immediately |
| API latency | Response > 5 seconds | PAUSE, retry with backoff |
| Data feed stale | No price update > 30 seconds | PAUSE until feed resumes |
| Order rejection | 2 consecutive rejections | HALT, investigate |
| Balance mismatch | Calculated vs actual > 1% | HALT, reconcile |
| Clock drift | System time off by > 2 seconds | HALT, fix time sync |

CATEGORY 4: EXTERNAL EVENT TRIGGERS (known risk events)

| Trigger | Condition | Action |
|---------|-----------|--------|
| Major economic release | FOMC, CPI, NFP (scheduled) | PAUSE 30 min before to 30 min after |
| Exchange maintenance | Announced downtime | CLOSE positions before, HALT during |
| Black swan news | Manual trigger by human | HALT immediately |

Kill Switch State Machine:

NORMAL OPERATION
  │
  ├── [Warning trigger] → LOG + ALERT (continue trading at reduced size)
  │                          │
  │                          └── [Second warning] → ESCALATE to PAUSE
  │
  ├── [PAUSE trigger] → HALT new orders, keep existing positions
  │                          │
  │                          ├── [Condition clears within 1h] → RESUME at 50% size
  │                          │
  │                          └── [Condition persists >1h] → ESCALATE to HALT
  │
  └── [HALT trigger] → CLOSE all positions, HALT all activity
                           │
                           └── [Human review required] → RECOVERY PROCEDURE

Step 4: Human-in-the-Loop Approval Gates

Define exactly when an agent must stop and ask a human for permission.

Mandatory Approval Events:

ALWAYS REQUIRE HUMAN APPROVAL:

1. FIRST TRADE EVER
   - Agent's very first live trade must be human-approved
   - Confirms system is working correctly before autonomous operation

2. NEW ASSET
   - First time trading any asset the agent hasn't traded before
   - Prevents agent from wandering into unfamiliar markets

3. LARGE POSITION
   - Any trade > 2% of agent's allocation (or 1% for conservative)
   - Prevents oversized positions from a single decision

4. LEVERAGE INCREASE
   - Any use of leverage > 2x
   - Any increase in existing leverage position

5. STRATEGY DEVIATION
   - Trade that doesn't match the agent's defined strategy parameters
   - Example: Momentum agent wanting to mean-revert, or vice versa

6. AFTER KILL SWITCH
   - First 3 trades after any kill switch activation
   - Ensures the issue that caused the halt is truly resolved

7. UNUSUAL MARKET CONDITIONS
   - VIX > 30 (or crypto equivalent: BTC 30d realized vol > 80%)
   - Trading during or immediately after black swan events

8. WITHDRAWAL / TRANSFER
   - NEVER automated — always human-only
   - Agent should never have withdrawal permissions

Approval Request Format (Agent to Human):

## AGENT APPROVAL REQUEST

| Field | Value |
|-------|-------|
| Agent | [agent-name] |
| Reason | [why approval is needed] |
| Action | [BUY/SELL] [size] [asset] at [price] on [exchange] |
| Strategy Signal | [brief description of why the agent wants this trade] |
| Risk Assessment | [risk % of allocation, stop-loss, R:R] |
| Current P&L | [daily/weekly/total agent P&L] |
| Open Positions | [count and total exposure] |

**Approve (Y) / Reject (N) / Modify (M)?**

Timeout Rules:

  • If no human response within 15 minutes: trade opportunity expires, agent moves on
  • If no human response within 1 hour on a HALT approval: agent stays halted
  • Emergency: Agent can close existing positions to reduce risk without approval (but not open new ones)

Step 5: Multi-Agent Coordination

When multiple agents operate on the same portfolio or market, coordination prevents conflicts.

Conflict Prevention Rules:

RULE 1: NO OPPOSING POSITIONS
  - If Agent A is LONG BTC, Agent B cannot go SHORT BTC
  - Check: Before opening, query all agent positions via shared state
  - Resolution: Later agent's order is blocked, notification sent to both agents

RULE 2: AGGREGATE EXPOSURE LIMITS
  - Sum of all agents' exposure in a single asset < max single-asset limit
  - Sum of all agents' total portfolio heat < max total heat
  - Each agent sees: its own limits AND the aggregate limit

RULE 3: SHARED POSITION REGISTRY
  - Central registry of all agent positions, updated in real-time
  - Each agent queries the registry before trading
  - Format:
    {
      "agent": "momentum-btc",
      "asset": "BTC/USDT",
      "side": "LONG",
      "size": 0.5,
      "entry": 67000,
      "stop": 64000,
      "timestamp": "2025-01-15T10:30:00Z"
    }

RULE 4: EXECUTION QUEUE
  - If two agents try to trade the same asset within 5 seconds: queue second order
  - Prevents competing for the same liquidity / moving the market against themselves
  - Priority: Risk-reducing orders > New positions > Position increases

RULE 5: NET EXPOSURE MONITORING
  - If Agent A is long 1 BTC and Agent B is long 0.5 BTC:
    Net portfolio BTC exposure = 1.5 BTC
  - This net exposure must be within portfolio-level limits
  - A "portfolio supervisor" agent or process should monitor net exposure

Multi-Agent Architecture:

                    ┌──────────────────┐
                    │  Human Operator   │
                    └────────┬─────────┘
                             │ Approval gates
                    ┌────────▼─────────┐
                    │  Portfolio       │
                    │  Supervisor      │ ← Monitors net exposure, enforces limits
                    └────────┬─────────┘
                             │
              ┌──────────────┼──────────────┐
              │              │              │
    ┌─────────▼────┐ ┌──────▼──────┐ ┌─────▼──────────┐
    │ Agent:       │ │ Agent:      │ │ Agent:         │
    │ Momentum     │ │ Mean-Rev    │ │ Arbitrage      │
    │ BTC/ETH      │ │ Alts        │ │ Cross-exchange │
    └──────┬───────┘ └──────┬──────┘ └──────┬─────────┘
           │                │               │
    ┌──────▼────────────────▼───────────────▼──────┐
    │           Shared Position Registry            │
    │   (All agents read/write positions here)      │
    └──────────────────────────────────────────────┘

Step 6: Agent Performance Monitoring

Continuously monitor agent performance to detect strategy drift, degradation, or failure.

Real-Time Monitoring Metrics:

METRIC 1: ROLLING SHARPE RATIO
  Calculate: 30-day rolling Sharpe = Mean(daily returns) / StdDev(daily returns) × √252

  | Sharpe | Status | Action |
  |--------|--------|--------|
  | > 2.0 | Excellent | Continue, consider increasing allocation |
  | 1.0-2.0 | Good | Continue normal operation |
  | 0.5-1.0 | Mediocre | Alert human, review strategy |
  | 0-0.5 | Poor | Reduce allocation by 50%, review |
  | < 0 | Negative | HALT agent, mandatory strategy review |

METRIC 2: WIN RATE TRACKING
  Calculate: Rolling 20-trade win rate

  Expected: Within 1 std dev of backtest win rate
  Alert: If current win rate < (backtest win rate - 15 percentage points)
  Halt: If current win rate < 25% (over 20 trades)

METRIC 3: STRATEGY DRIFT DETECTION
  Compare current trading behavior to strategy definition:
  - Average hold time: within 2× of expected? (e.g., momentum agent holding >10 days = drift)
  - Asset selection: trading only approved assets?
  - Entry signals: consistent with strategy logic?
  - Position sizes: within defined limits?

  Drift Score = Number of deviations / Total decisions
  Alert: Drift Score > 10%
  Halt: Drift Score > 25%

METRIC 4: DRAWDOWN TRACKING
  Peak-to-trough drawdown updated in real-time

  | Drawdown | Action |
  |----------|--------|
  | 0-3% | Normal |
  | 3-5% | Alert human, reduce new position sizes by 25% |
  | 5-8% | Halt new trades, keep existing positions with tight stops |
  | 8-10% | Close 50% of positions, enter recovery mode |
  | > 10% | FULL HALT — close all positions |

METRIC 5: ANOMALY DETECTION
  Flag any of these as anomalies:
  - Trade size > 3× average trade size
  - Holding period > 3× average holding period
  - Entry outside normal strategy parameters
  - Rapid-fire trades (>5 in 10 minutes) when strategy is not scalping
  - P&L swing > 3 std dev in a single trade

Step 7: Audit Trail Requirements

Every agent action must be logged for post-incident review and continuous improvement.

Mandatory Log Events:

EVENT LOG SCHEMA:

{
  "timestamp": "ISO-8601",
  "agent_id": "momentum-btc-01",
  "event_type": "trade|signal|risk_check|kill_switch|error|approval",
  "details": {
    // Event-specific fields
  },
  "portfolio_state": {
    "total_value": 50000,
    "open_positions": [...],
    "daily_pnl": -150,
    "daily_pnl_pct": -0.3
  }
}

REQUIRED EVENTS TO LOG:

1. SIGNAL GENERATION
   - What signal was generated, what data it was based on
   - Signal strength/confidence score

2. RISK CHECK
   - Every risk-management gate check: pass or fail
   - Which specific limits were checked and their values

3. ORDER SUBMISSION
   - Full order details: asset, side, size, type, price, exchange
   - Pre-trade portfolio state

4. ORDER FILL
   - Fill price, quantity, fees, slippage
   - Post-trade portfolio state

5. KILL SWITCH EVENT
   - Which trigger fired and its value vs threshold
   - Actions taken (pause, halt, close positions)
   - Portfolio state at trigger time

6. HUMAN APPROVAL
   - What was requested and why
   - Human response (approve/reject/modify)
   - Time to response

7. ERROR
   - API errors, data feed errors, calculation errors
   - Error handling action taken

8. DAILY SUMMARY (automatic at UTC midnight)
   - Trades executed, P&L, current positions
   - Risk metrics (Sharpe, drawdown, win rate)
   - Any alerts or incidents

Log Retention:

  • Hot storage (queryable): 90 days
  • Cold storage (archived): 3 years minimum
  • Critical events (kill switches, errors): permanent

Step 8: Recovery Procedures

After a kill switch triggers, follow this structured recovery process.

RECOVERY PROCEDURE (after kill switch activation):

PHASE 1: IMMEDIATE (0-1 hour)
  1. Confirm all agent orders are cancelled
  2. Record final portfolio state
  3. Identify which kill switch triggered and why
  4. Assess if the trigger was a true threat or false positive
  5. Notify human operator with full incident details

PHASE 2: INVESTIGATION (1-24 hours)
  1. Review audit trail for the 24 hours leading to the incident
  2. Identify root cause:
     - Market condition (external) → wait for normalization
     - Strategy failure (internal) → strategy needs revision
     - System error (technical) → fix before restarting
     - Data issue (input) → validate data sources
  3. Document findings in incident report

PHASE 3: RESOLUTION (24-72 hours)
  1. Fix identified issues (if any)
  2. If strategy failure: run backtest on recent data to confirm
  3. Update kill switch thresholds if false positive
  4. Adjust risk limits if strategy underperformed

PHASE 4: RESTART (after human approval)
  1. Human explicitly approves restart
  2. Agent resumes in REDUCED MODE:
     - Position sizes at 50% of normal
     - Daily loss limit reduced by 50%
     - First 3 trades require human approval
  3. After 5 profitable trades in reduced mode:
     - Increase to 75% of normal limits
  4. After 10 profitable trades at 75%:
     - Return to normal limits
  5. If another kill switch fires during recovery:
     - Return to Phase 1
     - This is a second incident → consider strategy redesign

RECOVERY TIMELINE:
  Performance trigger → 24-48 hour recovery minimum
  Market condition trigger → Resume when conditions normalize
  System error trigger → Resume after fix verified in paper trading
  Consecutive kill switches (2 in 7 days) → Mandatory 7-day pause + strategy audit

Anti-Patterns

DO NOT do these — they cause agent failures and losses:

  1. Running agents without kill switches: An agent without kill switches is a ticking time bomb. Every agent must have performance-based, market-condition, and system triggers.

  2. Giving agents withdrawal permissions: NEVER. An agent with withdrawal access is a security disaster. API keys must be trade-only with IP whitelisting.

  3. Skipping paper trading: Deploying an agent directly to live trading without paper trade validation is gambling. Minimum 100 paper trades with positive expectancy before live.

  4. No human oversight: Even “fully autonomous” agents need a human who reviews daily summaries and can pull the plug. True zero-oversight is irresponsible.

  5. Shared API keys: Each agent must have its own API key. Sharing keys makes it impossible to audit, attribute, or independently halt specific agents.

  6. Ignoring strategy drift: An agent that slowly changes its behavior (holding longer, sizing larger, trading new assets) without detection will eventually blow up. Monitor drift scores.

  7. Resuming at full size after a halt: After a kill switch, always resume at reduced size. Going from halt to full size is like a driver going from 0 to 100 mph after an accident.

  8. No aggregate exposure monitoring in multi-agent setups: If Agent A and Agent B both go long BTC independently, you may have 2x the intended BTC exposure without knowing it.

Validation Checkpoints

Agent Deployment Checklist

  • Risk limits defined for all levels (per-trade, daily, weekly, monthly)
  • API key created with TRADE-ONLY permissions (no withdrawal)
  • IP whitelist configured for agent’s deployment environment
  • API key stored in secret manager (not in code or config files)
  • Kill switches configured for all 4 categories (performance, market, system, external)
  • Human approval gates defined for all mandatory events
  • Audit logging implemented for all required event types
  • Paper trading completed (minimum 100 trades, positive expectancy)
  • Recovery procedure documented and tested
  • If multi-agent: shared position registry operational

Runtime Validation

  • All risk limits checked before every order
  • Kill switch conditions evaluated continuously
  • Performance metrics (Sharpe, win rate, drawdown) updated in real-time
  • Strategy drift score calculated and monitored
  • Audit log writing confirmed (no silent failures)
  • Human operator reachable for approval requests

Post-Incident Validation

  • Incident report completed with root cause analysis
  • Kill switch thresholds reviewed and adjusted if needed
  • Recovery mode parameters set (50% size, approval gates)
  • Human approval received for restart
  • Paper trading confirms fix (if strategy/system issue)

Example

User: “Set up trading guardrails for an autonomous momentum agent trading BTC and ETH on Binance with a $50,000 allocation.”

Analysis:

## Agent Guardrail Configuration: Momentum-BTC-ETH

### Risk Limits (Moderate Profile)
| Limit | Value |
|-------|-------|
| Total allocation | $50,000 (25% of assumed $200K portfolio) |
| Max per-trade risk | 0.5% = $250 |
| Max single position | 5% = $2,500 |
| Max open positions | 4 (2 BTC + 2 ETH) |
| Max daily loss | 2% = $1,000 |
| Max daily trades | 10 |
| Max daily volume | 10% = $5,000 |
| Max weekly loss | 5% = $2,500 |
| Max monthly loss | 10% = $5,000 |
| Max leverage | 2x |
| Max correlated exposure | BTC + ETH combined < 80% (they correlate at 0.85) |

### API Key Configuration (Binance)
- Permission: TRADE-ONLY (read + spot + futures, NO withdraw)
- IP whitelist: [agent-server-static-IP]
- Sub-account: "agent-momentum-01" with $50,000 transferred
- Key label: "agent-momentum-btc-eth-prod"
- Rotation schedule: Every 90 days (next: [date])
- Secret storage: AWS Secrets Manager

### Kill Switch Configuration
| Trigger | Threshold | Action |
|---------|-----------|--------|
| Session drawdown | > $1,500 (3%) | HALT, notify human |
| Daily loss | > $1,000 (2%) | HALT for day |
| Consecutive losses | 3 in a row | PAUSE 1 hour |
| Consecutive losses | 5 in a row | HALT, require review |
| Volatility spike | BTC or ETH > 3σ move in 1h | PAUSE |
| API errors | 3 consecutive | HALT immediately |
| Spread widening | > 0.1% on BTC/USDT | PAUSE |
| Sharpe (30d) | < 0.5 | Alert, reduce 50% |
| Win rate (20 trades) | < 30% | HALT |

### Human Approval Gates
- First trade: REQUIRED
- New asset (anything besides BTC, ETH): REQUIRED
- Position > $2,500 (5% of allocation): REQUIRED
- Leverage > 2x: REQUIRED
- After any kill switch: first 3 trades REQUIRED
- BTC 30d vol > 80%: all trades REQUIRED
- Timeout: 15 minutes (trade opportunity expires)

### Monitoring Dashboard
- Rolling 30d Sharpe: target > 1.0
- Rolling 20-trade win rate: target > 45%
- Max drawdown tracking: current peak-to-trough
- Strategy drift score: updated daily
- Daily P&L notification: sent at 00:00 UTC

### Audit Trail
- All events logged to: /var/log/agent-momentum-01/
- Daily summary emailed to: [operator-email]
- Retention: 90 days hot, 3 years cold
- Critical events: permanent retention

### Recovery Procedure (if kill switch fires)
1. All orders cancelled automatically
2. Human notified via [Telegram/Slack/email]
3. Incident investigation within 24 hours
4. Restart requires human approval
5. Resume at 50% size ($125 per-trade risk)
6. Normal size after 5 consecutive profitable trades

RECOMMENDATION: Run 100 paper trades first. If 30d paper Sharpe > 1.0
and max paper drawdown < 5%, proceed to live at 50% allocation ($25K),
then scale to full $50K after 30 live trading days with positive results.