Fleet Threat Modeling

R — Repudiation (Audit)

• Can an agent deny performing an action?
• Are all state-modifying operations logged?
• Is the trail tamper-resistant?

I — Information Disclosure

• Can an agent see data they shouldn't?
• Are errors leaking internal state?
• Are secrets (tokens, keys) properly scoped?

D — Denial of Service

• Can an agent flood the system?
• Are there rate limits on tool calls?
• Can a single task block the orchestrator?

E — Elevation of Privilege

• Can an agent perform actions beyond their role?
• Are role boundaries enforced at the tool level?
• Can contribution tasks be self-approved?

Process

Step 1: Map the Attack Surface

For the feature or component under review:

1. What are the entry points? (APIs, tool calls, IRC messages, file reads)
2. What data flows through? (task data, credentials, user content)
3. What are the trust boundaries? (agent → MCP → MC, agent → gateway)
4. What assets are at risk? (task data, credentials, fleet state)

Step 2: Apply STRIDE

For each entry point, walk through STRIDE. Not everything applies to everything — focus on what's realistic:

Step 3: Produce Specific Requirements

For each threat identified:

1. What: the specific vulnerability
2. Where: the specific code/component
3. Impact: what happens if exploited
4. Control: the specific mitigation
5. Verification: how to test the control works

Step 4: Classify Severity

Output: Security Contribution

When contributing to a task via fleet_contribute:

## Security Requirements for: {task_title}

### Threat Summary
{1-2 sentences: what's the risk profile}

### Requirements
1. [CRITICAL] {specific control}
   - Threat: {STRIDE category}: {specific threat}
   - Where: {file/endpoint/component}
   - Verify: {how to test}

2. [HIGH] {specific control}
   ...

### Trust Boundaries
- {boundary}: {what crosses it, how to protect}

### Out of Scope
- {what was assessed and found acceptable, so the engineer doesn't waste time}

Common Mistakes

1. Generic requirements — "validate all inputs" tells the engineer nothing
2. Missing the real threat — spending time on XSS in an internal CLI tool
3. Over-classifying — not everything is Critical
4. Ignoring the fleet context — agents are NOT external attackers, but behavioral drift IS a real threat (see fleet-elevation/20 anti-corruption)
5. Blocking instead of guiding — security_hold is for confirmed risks, not theoretical concerns