Security Architect Skill

Step 1: Threat Modeling (STRIDE)

Analyze threats using STRIDE:

Threat

Description

Example

S

poofing

Impersonating users/systems

Stolen credentials

T

ampering

Modifying data

SQL injection

R

epudiation

Denying actions

Missing audit logs

I

nformation Disclosure

Data leaks

Exposed secrets

D

enial of Service

Blocking access

Resource exhaustion

E

levation 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

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 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) 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 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