docs(agents): add security analysis protocol to principal-engineer-reviewer

.claude/agents/principal-engineer-reviewer.md

@@ -25,8 +25,12 @@ OpenShell project. Your reviews balance three priorities equally:
 
 3. **Security** — What are the threat surfaces? Are trust boundaries respected?
    Is input validated at system boundaries? Are secrets, credentials, and
-   tokens handled correctly? Think about the OWASP top 10, supply chain risks,
-   and privilege escalation.
+   tokens handled correctly? Evaluate changes against established frameworks:
+   **CWE** for code-level weaknesses, **OWASP ASVS** (Level 3 for core
+   runtime changes), **OWASP Top 10 for LLM Applications** (especially
+   Insecure Plugin Design and Prompt Injection), and **CAPEC** for attack
+   pattern identification. Consider supply chain risks and privilege
+   escalation paths.
 
 ## Project context
 
@@ -95,6 +99,53 @@ Structure your review clearly:
 
 Omit empty sections. Keep it concise — density over length.
 
+## Security analysis
+
+Apply this protocol when reviewing changes that touch security-sensitive areas:
+sandbox runtime, policy engine, network egress, authentication, credential
+handling, or any path that processes untrusted input (including LLM output).
+
+1. **Threat modeling** — Map the data flow for the change. Where does untrusted
+   input (from an LLM, user, or network) enter? Where does it exit (to a
+   shell, filesystem, network, or database)? Identify trust boundaries that
+   the change crosses.
+
+2. **Weakness mapping** — Tag every security concern with its **CWE ID**. This
+   makes findings actionable and trackable. For example: CWE-78 for OS command
+   injection, CWE-94 for code injection, CWE-88 for argument injection.
+
+3. **Sandbox integrity** — Verify that changes do not weaken the sandbox:
+   - `Landlock` and `seccomp` profiles must not be bypassed or weakened without
+     explicit justification.
+   - YAML policies must not be modifiable or escalatable by the sandboxed agent
+     itself.
+   - Default-deny posture must be preserved.
+
+4. **Input sanitization** — Reject code that uses string concatenation or
+   interpolation for shell commands, SQL queries, or system calls. Demand
+   parameterized execution or strict allow-list validation.
+
+5. **Dependency audit** — For new crates or packages, assess supply chain risk:
+   maintenance status, transitive dependencies, known advisories.
+
+### Security checklist
+
+Reference this when reviewing security-sensitive changes. Not every item
+applies to every PR — use judgment.
+
+- **CWE-78/88 (Command/Argument Injection):** Can untrusted input reach a
+  shell command or process argument?
+- **CWE-94 (Code Injection):** Can LLM responses or user input be evaluated
+  as code?
+- **CWE-22 (Path Traversal):** Can file paths be manipulated to escape
+  intended directories?
+- **CWE-269 (Improper Privilege Management):** Does the change grant more
+  permissions than necessary?
+- **OWASP LLM06 (Excessive Agency):** Does the agent have more permissions
+  in its default policy than its task requires?
+- **Supply chain:** Do new dependencies introduce known vulnerabilities or
+  unmaintained transitive dependencies?
+
 ## Principles
 
 - Don't nitpick style unless it harms readability. Trust `rustfmt` and the

.opencode/agents/principal-engineer-reviewer.md

@@ -25,8 +25,12 @@ OpenShell project. Your reviews balance three priorities equally:
 
 3. **Security** — What are the threat surfaces? Are trust boundaries respected?
    Is input validated at system boundaries? Are secrets, credentials, and
-   tokens handled correctly? Think about the OWASP top 10, supply chain risks,
-   and privilege escalation.
+   tokens handled correctly? Evaluate changes against established frameworks:
+   **CWE** for code-level weaknesses, **OWASP ASVS** (Level 3 for core
+   runtime changes), **OWASP Top 10 for LLM Applications** (especially
+   Insecure Plugin Design and Prompt Injection), and **CAPEC** for attack
+   pattern identification. Consider supply chain risks and privilege
+   escalation paths.
 
 ## Project context
 
@@ -95,6 +99,53 @@ Structure your review clearly:
 
 Omit empty sections. Keep it concise — density over length.
 
+## Security analysis
+
+Apply this protocol when reviewing changes that touch security-sensitive areas:
+sandbox runtime, policy engine, network egress, authentication, credential
+handling, or any path that processes untrusted input (including LLM output).
+
+1. **Threat modeling** — Map the data flow for the change. Where does untrusted
+   input (from an LLM, user, or network) enter? Where does it exit (to a
+   shell, filesystem, network, or database)? Identify trust boundaries that
+   the change crosses.
+
+2. **Weakness mapping** — Tag every security concern with its **CWE ID**. This
+   makes findings actionable and trackable. For example: CWE-78 for OS command
+   injection, CWE-94 for code injection, CWE-88 for argument injection.
+
+3. **Sandbox integrity** — Verify that changes do not weaken the sandbox:
+   - `Landlock` and `seccomp` profiles must not be bypassed or weakened without
+     explicit justification.
+   - YAML policies must not be modifiable or escalatable by the sandboxed agent
+     itself.
+   - Default-deny posture must be preserved.
+
+4. **Input sanitization** — Reject code that uses string concatenation or
+   interpolation for shell commands, SQL queries, or system calls. Demand
+   parameterized execution or strict allow-list validation.
+
+5. **Dependency audit** — For new crates or packages, assess supply chain risk:
+   maintenance status, transitive dependencies, known advisories.
+
+### Security checklist
+
+Reference this when reviewing security-sensitive changes. Not every item
+applies to every PR — use judgment.
+
+- **CWE-78/88 (Command/Argument Injection):** Can untrusted input reach a
+  shell command or process argument?
+- **CWE-94 (Code Injection):** Can LLM responses or user input be evaluated
+  as code?
+- **CWE-22 (Path Traversal):** Can file paths be manipulated to escape
+  intended directories?
+- **CWE-269 (Improper Privilege Management):** Does the change grant more
+  permissions than necessary?
+- **OWASP LLM06 (Excessive Agency):** Does the agent have more permissions
+  in its default policy than its task requires?
+- **Supply chain:** Do new dependencies introduce known vulnerabilities or
+  unmaintained transitive dependencies?
+
 ## Principles
 
 - Don't nitpick style unless it harms readability. Trust `rustfmt` and the