Security Architect Skill

Step 1: Threat Modeling (STRIDE)

Analyze threats using STRIDE:

Threat Description Example

Spoofing Impersonating users/systems Stolen credentials

Tampering Modifying data SQL injection

Repudiation Denying actions Missing audit logs

Information Disclosure Data leaks Exposed secrets

Denial of Service Blocking access Resource exhaustion

Elevation of Privilege Gaining unauthorized access Broken access control

For AI/agentic systems, extend STRIDE with:

• Goal Hijacking (Spoofing + Tampering): Adversarial prompts redirect agent objectives

• Memory Poisoning (Tampering + Information Disclosure): Persistent context corruption

• Tool Misuse (Elevation of Privilege): Legitimate tools abused beyond intended scope

Step 2: OWASP Top 10 2025 Analysis

IMPORTANT: The OWASP Top 10 was updated in 2025 with two new categories and significant ranking shifts. Use this updated list, not the 2021 version.

Rank ID Vulnerability Key Change from 2021

1 A01 Broken Access Control Stable at #1; SSRF consolidated here

2 A02 Security Misconfiguration Up from #5

3 A03 Software Supply Chain Failures NEW — replaces Vulnerable Components

4 A04 Cryptographic Failures Down from #2

5 A05 Injection Down from #3

6 A06 Insecure Design Down from #4

7 A07 Authentication Failures Stable (renamed)

8 A08 Software or Data Integrity Failures Stable

9 A09 Security Logging and Alerting Failures Stable

10 A10 Mishandling of Exceptional Conditions NEW

Check for each vulnerability:

A01: Broken Access Control (includes SSRF from 2021)

• Verify authorization on every endpoint; deny by default

• Check for IDOR (Insecure Direct Object Reference) vulnerabilities

• Validate/sanitize all URLs; use allowlists for outbound requests (absorbed SSRF)

• Enforce CORS policies; restrict cross-origin requests

A02: Security Misconfiguration (up from #5 — now #2, affects ~3% of tested apps)

• Harden defaults; disable unnecessary features, ports, services

• Remove sample/default credentials and example content

• Ensure consistent security settings across all environments (dev/staging/prod)

• Review cloud storage ACLs, IAM policies, and network security groups

A03: Software Supply Chain Failures (NEW — highest avg exploit/impact scores)

• Maintain an SBOM (Software Bill of Materials) for all dependencies

• Enforce lockfiles (package-lock.json , yarn.lock , poetry.lock ) and verify integrity

• Use private registry scoping to prevent dependency confusion attacks

• Audit postinstall scripts; disable or allowlist explicitly

• Pin dependencies to exact versions and verify hashes/signatures

• Monitor CVE databases and security advisories (Dependabot, Snyk, Socket.dev)

• Harden CI/CD pipelines; enforce separation of duty (no single actor: write → deploy)

• Block exotic transitive dependencies (git URLs, direct tarballs) in production

A04: Cryptographic Failures (down from #2)

• Use strong algorithms: AES-256-GCM, SHA-256+, bcrypt/scrypt/Argon2 for passwords

• Never store plaintext passwords; enforce TLS 1.2+ everywhere

• Rotate secrets and keys; use envelope encryption for data at rest

A05: Injection (down from #3)

• Parameterize all queries (SQL, NoSQL, LDAP, OS commands)

• Validate and sanitize all inputs; apply output encoding for XSS prevention

A06: Insecure Design (down from #4)

• Threat model early in SDLC; use secure design patterns

• Apply principle of least privilege at design time

A07: Authentication Failures

• Implement MFA; prefer phishing-resistant methods (WebAuthn/Passkeys)

• Use OAuth 2.1 (mandatory PKCE, remove implicit/ROPC grants)

• Enforce secure session management; invalidate sessions on logout

A08: Software or Data Integrity Failures

• Verify dependencies with SRI hashes and cryptographic signatures

• Protect CI/CD pipelines; require signed commits and artifacts

A09: Security Logging and Alerting Failures

• Log all security events (auth failures, access control violations, input validation failures)

• Protect log integrity; never log secrets or PII

• Alert on anomalous patterns

A10: Mishandling of Exceptional Conditions (NEW)

• Ensure errors fail securely — never "fail open" (default to deny on error)

• Validate logic for edge cases: timeouts, partial responses, unexpected nulls

• Return generic error messages to clients; log detailed context server-side

• Test error handling paths explicitly (chaos/fault injection testing)

Step 3: OWASP Agentic AI Top 10 (ASI01-ASI10) — For AI/Agent Systems

When the codebase involves AI agents, LLMs, or autonomous systems, perform this additional assessment. Released December 2025 by OWASP GenAI Security Project.

ASI Risk Core Attack Vector

ASI01 Agent Goal Hijack Prompt injection redirects agent objectives

ASI02 Tool Misuse Legitimate tools abused beyond intended scope

ASI03 Identity & Privilege Abuse Credential inheritance/delegation without scoping

ASI04 Supply Chain Vulnerabilities Malicious tools, MCP servers, agent registries

ASI05 Unexpected Code Execution Agent-generated code bypasses security controls

ASI06 Memory & Context Poisoning Persistent corruption of agent memory/embeddings

ASI07 Insecure Inter-Agent Communication Weak agent-to-agent protocol validation

ASI08 Cascading Failures Error propagation across chained agents

ASI09 Human-Agent Trust Exploitation Agents manipulate users into unsafe approvals

ASI10 Rogue Agents Agents act outside authorized scope

ASI01 — Agent Goal Hijack: Attackers manipulate planning logic via prompt injection in user input, RAG documents, emails, or calendar invites.

• Mitigations: Validate all inputs against expected task scope; enforce task boundary checks in routing layer; use system prompts that resist goal redirection; log unexpected task deviations for review.

ASI02 — Tool Misuse: Agents use tools beyond intended scope (e.g., file deletion when only file read was authorized).

• Mitigations: Whitelist/blacklist tools per agent role; validate tool parameters before execution; enforce principle of least privilege for tool access; monitor tool usage patterns for anomalies.

ASI03 — Identity & Privilege Abuse: Agents inherit or delegate credentials without proper scoping, creating attribution gaps.

• Mitigations: Assign each agent a distinct, scoped identity; never reuse human credentials for agents; audit all credential delegation chains; enforce short-lived tokens for agent actions.

ASI04 — Supply Chain Vulnerabilities (Agentic): Malicious MCP servers, agent cards, plugin registries, or tool packages poison the agent ecosystem.

• Mitigations: Verify integrity of all tool/plugin sources; use registry allowlists; audit MCP server provenance; apply same supply chain controls as A03 to agent tooling.

ASI05 — Unexpected Code Execution: Agent-generated or "vibe-coded" code executes without traditional security controls (sandboxing, review).

• Mitigations: Sandbox code execution environments; review agent-generated code before execution in production; apply static analysis to generated code; never execute code from memory/context without validation.

ASI06 — Memory & Context Poisoning: Attackers embed malicious instructions in documents, web pages, or RAG corpora that persist in agent memory and influence future actions.

• Mitigations: Sanitize all data written to memory (learnings, vector stores, embeddings); validate memory entries before use; never execute commands sourced from memory without explicit approval; implement memory rotation and auditing (see ADR-102).

ASI07 — Insecure Inter-Agent Communication: Agent-to-agent messages lack authentication, integrity checks, or semantic validation, enabling injection attacks between agents.

• Mitigations: Authenticate all agent-to-agent messages; validate message schemas; use signed inter-agent payloads; apply semantic validation (not just structural) to delegated instructions.

ASI08 — Cascading Failures: Errors or attacks in one agent propagate uncontrolled through multi-agent pipelines.

• Mitigations: Define error boundaries between agents; implement circuit breakers; require human-in-the-loop checkpoints for high-impact actions; never auto-retry destructive operations on failure.

ASI09 — Human-Agent Trust Exploitation: Agents present misleading information to manipulate users into approving unsafe actions.

• Mitigations: Display agent reasoning and provenance transparently; require explicit human confirmation for irreversible actions; detect urgency/fear manipulation patterns; maintain audit trails of all user-agent interactions.

ASI10 — Rogue Agents: Agents operate outside authorized scope, take unsanctioned actions, or resist human override.

• Mitigations: Enforce hard authorization boundaries at the infrastructure level (not just prompt level); implement kill-switch mechanisms; log all agent actions with human-reviewable audit trail; test override/shutdown paths regularly.

Step 4: Supply Chain Security Review

Perform this check for all projects with external dependencies:

Check for known vulnerabilities

npm audit --audit-level=high

or

pnpm audit

Verify lockfile integrity (ensure lockfile is committed and not bypassed)

Check that package-lock.json / yarn.lock / pnpm-lock.yaml exists and is current

Scan for malicious packages (behavioral analysis)

Tools: Socket.dev, Snyk, Aikido, Safety (Python)

Dependency Confusion Defense:

• Scope all internal packages under a private namespace (e.g., @company/package-name )

• Configure registry resolution order to prefer private registry

• Use publishConfig and registry scoping to prevent public registry fallback for private packages

• Block exotic transitive dependencies (git URLs, direct tarball URLs)

Typosquatting Defense:

• Audit all npm install / pip install commands for misspellings

• Use allowlists for permitted packages in automated environments

• Delay new dependency version installs by 24+ hours (minimumReleaseAge ) to allow malware detection

CI/CD Pipeline Hardening:

• Enforce separation of duty: no single actor writes code AND promotes to production

• Sign all build artifacts and verify signatures before deployment

• Pin action versions in GitHub Actions (use commit SHA, not floating tags)

• Restrict pipeline secrets to minimum required scope

Step 5: Modern API Authentication Review

OAuth 2.1 (current standard — replaces OAuth 2.0 for new implementations):

OAuth 2.1 removes insecure grants:

• Implicit grant (response_type=token) — REMOVED: tokens in URL fragments leak
• Resource Owner Password Credentials (ROPC) — REMOVED: breaks delegated auth model

OAuth 2.1 mandates:

• PKCE (Proof Key for Code Exchange) for ALL authorization code flows
• Exact redirect URI matching (no wildcards)
• Sender-constraining tokens (DPoP recommended)

DPoP — Demonstrating Proof of Possession (RFC 9449):

• Binds access/refresh tokens cryptographically to the client's key pair

• Prevents token replay attacks even if tokens are intercepted

• Implement for all public clients (SPAs, mobile apps) where bearer token theft is a concern

// DPoP proof JWT structure (sent in DPoP header with each request) // Header: { "typ": "dpop+jwt", "alg": "ES256", "jwk": { client_public_key } } // Payload: { "jti": nonce, "htm": "POST", "htu": "https://api.example.com/token", "iat": timestamp } // Signed with client private key — server verifies binding to issued token

Passkeys / WebAuthn (FIDO2) — for user-facing authentication:

• Phishing-resistant: credentials are origin-bound and never transmitted

• Replaces passwords and SMS OTP for high-security contexts

• Major platforms (Windows, macOS, iOS, Android) support cross-device sync as of 2026

• Implementation: use navigator.credentials.create() (registration) and navigator.credentials.get() (authentication)

• Store only the public key and credential ID server-side (never the private key)

// WebAuthn registration (simplified) const credential = await navigator.credentials.create({ publicKey: { challenge: serverChallenge, // random bytes from server rp: { name: 'My App', id: 'myapp.example.com' }, user: { id: userId, name: userEmail, displayName: userName }, pubKeyCredParams: [{ alg: -7, type: 'public-key' }], // ES256 authenticatorSelection: { residentKey: 'preferred', userVerification: 'required' }, }, }); // Send credential.id and credential.response to server for verification

Step 6: Security Code Review

Look for common issues:

// BAD: SQL Injection const query = SELECT * FROM users WHERE id = ${userId};

// GOOD: Parameterized query const query = SELECT * FROM users WHERE id = $1; await db.query(query, [userId]);

// BAD: Hardcoded secrets const apiKey = 'sk-abc123...';

// GOOD: Environment variables / secret manager const apiKey = process.env.API_KEY;

// BAD: shell: true (shell injection vector) const { exec } = require('child_process'); exec(git commit -m "${userMessage}");

// GOOD: shell: false with array arguments const { spawn } = require('child_process'); spawn('git', ['commit', '-m', userMessage], { shell: false });

// BAD: Fail open on error (dangerous for auth/authz) try { const isAuthorized = await checkPermission(user, resource); if (isAuthorized) return next(); } catch (err) { return next(); // WRONG: allows access on error }

// GOOD: Fail securely (deny on error — A10:2025) try { const isAuthorized = await checkPermission(user, resource); if (!isAuthorized) return res.status(403).json({ error: 'Forbidden' }); return next(); } catch (err) { logger.error('Permission check failed', { err, user, resource }); return res.status(403).json({ error: 'Forbidden' }); // Default deny }

Step 7: Authentication/Authorization Review

Verify:

• Strong password requirements OR passkey/WebAuthn (preferred in 2026)

• Secure session management (HTTPOnly, Secure, SameSite=Strict cookies)

• JWT validation (signature, expiry, audience, issuer)

• Role-based access control (RBAC) enforced server-side

• API authentication: OAuth 2.1 + PKCE (not OAuth 2.0 implicit/ROPC)

• DPoP sender-constraining for public clients handling sensitive data

• Phishing-resistant MFA (WebAuthn preferred over SMS OTP)

Step 8: Generate Security Report

Create findings report:

Security Assessment Report

Critical Findings

1. SQL injection in /api/users endpoint
   • Risk: Data breach
   • Fix: Use parameterized queries

High Findings

2. Missing rate limiting on login

   • Risk: Brute force attacks
   • Fix: Implement rate limiting

3. OAuth 2.0 implicit grant in use (deprecated)

   • Risk: Access token exposure in URL fragments / browser history
   • Fix: Migrate to Authorization Code + PKCE (OAuth 2.1)

Medium Findings

4. No lockfile committed for npm dependencies
   • Risk: Supply chain attack via dependency resolution drift
   • Fix: Commit package-lock.json; add lockfile verification to CI

Recommendations

• Enable HTTPS everywhere; enforce HSTS
• Implement CSP headers
• Add security logging for auth events
• Migrate to OAuth 2.1 (remove implicit/ROPC grants)
• Implement passkey/WebAuthn for phishing-resistant authentication
• Run npm audit / pnpm audit in CI with failure on high/critical

</execution_process>

<best_practices>

• Defense in Depth: Layer security controls; no single control is sufficient

• Least Privilege: Minimal permissions for users, services, and AI agents

• Fail Securely: Default to deny — especially on errors (A10:2025)

• Validate Everything: Never trust input from any source, including agent memory

• Keep Secrets Secret: Use secret managers; rotate regularly; never commit credentials

• Supply Chain Hygiene: Lock dependencies, verify integrity, monitor for compromise

• Human-in-the-Loop for Agents: Require explicit approval for irreversible agentic actions

• Modern Auth Standards: OAuth 2.1 + PKCE, DPoP, and Passkeys/WebAuthn over legacy flows

</best_practices>

Review the authentication flow in src/auth/ for security issues

Example Response:

Security Review: src/auth/

Findings

CRITICAL: Weak Password Hashing

• File: src/auth/password.js:23
• Issue: Using MD5 for password hashing
• Fix: Use bcrypt with cost factor >= 12

HIGH: No Rate Limiting

• File: src/auth/login.js
• Issue: Login endpoint has no rate limiting
• Fix: Add rate limiting (5 attempts/minute)

HIGH: OAuth 2.0 Implicit Grant in Use

• File: src/auth/oauth.js:45
• Issue: Using response_type=token (implicit grant, deprecated in OAuth 2.1)
• Fix: Migrate to Authorization Code flow with PKCE

MEDIUM: Session Not Invalidated

• File: src/auth/logout.js
• Issue: Logout doesn't invalidate server-side session
• Fix: Clear session from store on logout

Recommendations

1. Implement bcrypt for password hashing (cost factor >= 12)
2. Add rate limiting middleware (5 req/min on /login)
3. Migrate OAuth flows to Authorization Code + PKCE (OAuth 2.1)
4. Consider passkeys/WebAuthn for phishing-resistant authentication
5. Use secure session configuration (HTTPOnly, Secure, SameSite=Strict)

</usage_example>

<usage_example> AI Agent Security Review Request:

Review the LLM agent pipeline in src/agents/ for agentic AI security risks

Example Response:

Agentic AI Security Review: src/agents/

ASI01 — Agent Goal Hijack (HIGH)

• File: src/agents/email-processor.js
• Issue: User email content passed directly to agent system prompt without sanitization
• Fix: Sanitize email content; enforce task boundary validation in routing layer

ASI06 — Memory & Context Poisoning (HIGH)

• File: src/agents/memory-store.js:78
• Issue: Web-fetched content written to persistent memory without validation
• Fix: Validate and sanitize all external content before writing to memory; never execute commands retrieved from memory without explicit human approval

ASI02 — Tool Misuse (MEDIUM)

• File: src/agents/tools/file-tool.js
• Issue: Agent has both read and delete file permissions; delete scope too broad
• Fix: Split into read-only and write tools; apply least privilege per agent role

ASI10 — Rogue Agent Risk (MEDIUM)

• Issue: No kill-switch or hard resource limits on agent execution
• Fix: Implement max-steps limit, timeout, and human override checkpoint for operations affecting production data

</usage_example>

Iron Laws

• NEVER approve production deployment for code handling auth, PII, or external data without a completed security review

• ALWAYS run both OWASP Top 10 2025 AND ASI01-ASI10 assessments for AI/agentic systems

• ALWAYS fail securely — design all error paths to deny by default, never allow

• NEVER trust any input without validation, including data from internal services

• ALWAYS prioritize findings by severity (CRITICAL > HIGH > MEDIUM > LOW) with specific remediation steps and code examples

Anti-Patterns

Anti-Pattern Why It Fails Correct Approach

Approving code without full security review Partial reviews miss exploitable paths in auth/PII/external data flows Complete all STRIDE + OWASP phases before approving production deployment

Using OWASP 2021 for AI/agentic systems AI-specific threats (ASI01-ASI10) are not covered by the standard web list Always run both OWASP Top 10 2025 and ASI01-ASI10 for any agentic component

Failing open on security errors Error paths become exploitable bypass conditions Design every failure mode to deny access by default

Providing vague remediation guidance Developers cannot act without specifics Provide exact code examples and parameterized fix patterns for every finding

Missing severity prioritization Critical findings are buried in noise with informational findings Triage all findings as CRITICAL > HIGH > MEDIUM > LOW before delivery

Related Skills

• auth-security-expert
• OAuth 2.1, JWT, and authentication-specific security patterns

Related Workflow

For comprehensive security audits requiring multi-phase threat analysis, vulnerability scanning, and remediation planning, see the corresponding workflow:

• Workflow File: .claude/workflows/security-architect-skill-workflow.md

• When to Use: For structured security audits requiring OWASP Top 10 2025 analysis, dependency CVE checks, penetration testing, and remediation planning

• Phases: 5 phases (Threat Modeling, Security Code Review, Dependency Audit, Penetration Testing, Remediation Planning)

• Coverage: Full OWASP Top 10 2025, OWASP Agentic AI Top 10 (ASI01-ASI10), STRIDE threat modeling, CVE database checks, automated and manual penetration testing

Key Features:

• Multi-agent orchestration (security-architect, code-reviewer, developer, devops)

• Security gates for pre-release blocking

• Severity classification (CRITICAL/HIGH/MEDIUM/LOW)

• Automated ticket generation

• Compliance-ready reporting (SOC2, GDPR, HIPAA)

See also: Feature Development Workflow for integrating security reviews into the development lifecycle.

Memory Protocol (MANDATORY)

Before starting:

cat .claude/context/memory/learnings.md

After completing:

• New pattern -> .claude/context/memory/learnings.md

• Issue found -> .claude/context/memory/issues.md

• Decision made -> .claude/context/memory/decisions.md

ASSUME INTERRUPTION: Your context may reset. If it's not in memory, it didn't happen.