Blog

Skill and MCP server security, reported in public.

Methodology posts, public scan data, and field notes on the supply-chain surface of LLM agents. No fluff, no recycled vendor marketing.

2026-06-21 · Permissions Policy · Feature Policy · iframe Security · MCP Servers

MCP Server Permissions Policy Security: Permissions-Policy header, feature gating, iframe allow= attribute, sandbox vs Permissions-Policy, and Feature-Policy v1 vs v2

The Permissions-Policy HTTP header is the document-level kill switch for browser APIs: camera, microphone, geolocation, payment, USB, serial, Bluetooth, and compute-pressure. For MCP servers that render tool output in iframes, setting an explicit deny-all policy at the HTTP layer means even a successful XSS injection cannot call those APIs — the browser enforces the policy before dispatching any OS permission prompt. This post covers the fourteen device APIs you should deny by default; the syntax difference between legacy Feature-Policy (deprecated, ignored by modern browsers) and current Permissions-Policy; the critical distinction between sandbox="" (controls iframe capabilities like script execution) and Permissions-Policy (controls which browser hardware APIs running code can call); the parent-iframe layering model where the parent's header is the ceiling that cannot be expanded by the iframe's allow= attribute; cross-origin iframe tool rendering with a two-layer policy system; Caddy and nginx configuration including the nginx always flag required for error response coverage; and the interaction with Content Security Policy (CSP restricts what code runs, Permissions-Policy caps what that code can access). SkillAudit findings: HIGH −20 no Permissions-Policy header, HIGH −18 legacy Feature-Policy header present but ignored by modern browsers, MEDIUM −14 missing high-risk features in partial policy, MEDIUM −10 iframe rendering tool output without explicit allow= denials.
Read post →
2026-06-21 · Subresource Integrity · SRI · CORS · supply chain · MCP Servers

MCP Server Subresource Integrity (SRI) Security: integrity attribute verification, hash algorithm selection, CORS requirements, dynamic import() limitations, and CSP require-sri-for

Subresource Integrity lets browsers verify that CDN-hosted scripts and stylesheets haven't been tampered with by comparing a cryptographic hash in the integrity attribute against the fetched resource. The silent failure mode — where a cross-origin script loads and executes but the SRI check is skipped because crossorigin="anonymous" is absent — is the most dangerous misconfiguration. This post covers the full SRI security model: the integrity attribute format (sha256-, sha384-, sha512- base64 hash); why sha384 is the recommended algorithm and when multiple hashes enable algorithm agility; the CORS requirement and all four interaction modes (correct, silent bypass, CORS failure, credentialed CORS); the dynamic import() gap where sub-module scripts have no SRI protection at runtime; service worker registration limitations and the Cache-Control: no-store mitigation; and the CSP require-sri-for directive's Chrome-only, deprecated status. SkillAudit findings: CRITICAL −22 CDN script loaded without integrity attribute, CRITICAL −20 cross-origin script with integrity but missing crossorigin attribute (silent bypass), HIGH −18 module script with dynamic import() of third-party modules, HIGH −16 service worker without Cache-Control: no-store, MEDIUM −12 sha256 instead of sha384, MEDIUM −10 no multi-algorithm hash for CDN resources.
Read post →
2026-06-21 · Fetch Metadata · XS-Leaks · Resource Isolation · MCP Servers

MCP Server Fetch Metadata Security: Sec-Fetch-Site, Sec-Fetch-Mode, Sec-Fetch-Dest, Resource Isolation Policy, and XS-Leak Defense

The four Sec-Fetch-* request headers are set by the browser and classified as Forbidden — JavaScript cannot forge them. A resource isolation policy built on Sec-Fetch-Site, Sec-Fetch-Mode, Sec-Fetch-Dest, and Sec-Fetch-User gives MCP server tool endpoints a server-side classification of every request before auth logic runs: same-origin API fetch, cross-site image probe, navigation injection, or CSS import timing oracle. This post covers the complete Fetch Metadata security model: the four header values and what each encodes; the Forbidden header restriction that makes them un-forgeable by JavaScript; building a resource isolation policy that rejects Sec-Fetch-Site: cross-site requests before CSRF validation or database access; the specific XS-Leak vectors blocked (image load/error oracle, script parse oracle, CSS import timing oracle, iframe frame-count oracle); handling Sec-Fetch-Mode: navigate + cross-site as a navigation injection signal; WebSocket CSRF defense using Sec-Fetch-Mode: websocket; the critical non-browser client caveat (missing headers ≠ safe — pass non-browser clients through to auth layer); layering Fetch Metadata with CSRF tokens; and structured violation logging for probe-storm detection. SkillAudit findings: CRITICAL −24 no resource isolation policy on tool endpoints (cross-site probes reach handler code), CRITICAL −22 policy rejects missing Sec-Fetch headers (breaks SDK/CLI callers), HIGH −20 no navigation injection defense (GET endpoints with side effects), HIGH −18 WebSocket upgrade accepts cross-site connections, HIGH −16 CSS import timing oracle not blocked, MEDIUM −12 Fetch Metadata deployed as replacement for CSRF tokens, MEDIUM −10 no violation logging.
Read post →
2026-06-20 · COOP · COEP · CORP · SharedArrayBuffer · MCP Servers

MCP Server COOP/COEP Cross-Origin Isolation: SharedArrayBuffer Availability, Spectre Mitigations, CORP Per-Resource Headers, and OAuth Popup Flows

Cross-origin isolation via COOP and COEP is the prerequisite for SharedArrayBuffer in MCP server worker pools, but it breaks OAuth popup flows and blocks every third-party script that doesn't send a CORP header. This post covers the full cross-origin isolation stack: COOP same-origin vs same-origin-allow-popups and when each is correct; COEP require-corp vs credentialless and the tradeoff for third-party CDN scripts; per-resource CORP configuration (same-origin for API endpoints, same-site for CDN subdomains, cross-origin for public assets); the crossOriginIsolated property and why SAB and Atomics.wait() require both headers; three solutions for third-party scripts under COEP (credentialless mode, service worker proxy, sandboxed iframe without COEP inheritance); and the two OAuth popup flow solutions under COOP (COOP asymmetry with same-origin-allow-popups on the initiating page plus same-origin on the callback page, and redirect-based PKCE OAuth that doesn't use a popup at all). SkillAudit findings: CRITICAL −24 COOP not set (crossOriginIsolated permanently false), CRITICAL −22 SAB used without crossOriginIsolated guard, HIGH −20 COEP require-corp breaks third-party assets without CORP header, HIGH −18 OAuth popup broken by COOP same-origin without fallback, MEDIUM −12 COEP credentialless used without SAB guard, MEDIUM −10 CORP cross-origin on MCP API endpoint (allows cross-site embedding).
Read post →
2026-06-20 · CSP · Nonce · strict-dynamic · MCP Servers

MCP Server CSP Nonce Strategy: Nonce Generation, Reuse Vulnerabilities, Streaming HTML Timing, strict-dynamic, JSONP Bypasses, and report-to Monitoring

Nonce-based Content Security Policy is the gold standard for script injection defense in MCP server UIs — but five failure modes consistently defeat it in production. This post covers all five: static nonces baked at build time (permanently reusable bypass); CDN and template caching of nonce-bearing HTML responses (fixed nonce reuse across users); streaming HTML timing mismatches (nonce generated after first res.write(), mismatch with header value); strict-dynamic trust propagation to attacker-controlled dynamically imported scripts (the nonced script is trusted; code it eval()s or dynamically loads inherits that trust); and JSONP endpoints on script-src whitelisted origins (callback= parameter serves attacker-controlled JavaScript that CSP allows because the origin is whitelisted). The fix for JSONP bypass: nonce-only + strict-dynamic with no origin allowlist — no whitelisted origins, no JSONP bypass vectors. The section on report-uri vs report-to covers both deprecated and current violation reporting; CSP violation reports are a real-time injection detection channel that most MCP server deployments don't configure. Includes complete Express middleware with per-request nonce generation, Cache-Control: no-store enforcement, streaming-safe nonce lifecycle, and violation handler with session-correlated logging. SkillAudit findings: CRITICAL −24 static nonce, CRITICAL −22 JSONP endpoint on whitelisted origin, HIGH −20 nonce-bearing HTML cached by CDN, HIGH −18 nonced script calls eval() on tool result, MEDIUM −12 no violation reporting, MEDIUM −10 streaming nonce lifecycle mismatch.
Read post →
2026-06-20 · Trusted Types · DOM XSS · CSP · MCP Servers

MCP Server Trusted Types API Security: createHTML/createScript Policy Enforcement, DOM Clobbering Bypasses, and Default Policy Escape Hatches

MCP UIs that render tool output in the DOM are DOM XSS targets. Trusted Types closes the attack surface by requiring every string-to-DOM assignment to flow through a named policy's createHTML, createScript, or createScriptURL callback — the browser throws a TypeError on raw string assignments when require-trusted-types-for 'script' is set in CSP. This post covers the full Trusted Types security model for MCP servers: named policy enforcement and getPolicyNames() auditing; the default policy as escape hatch that attackers target (createHTML: (s) => s defeats the entire CSP directive); DOM Clobbering to bypass window.trustedTypes before policy registration (form id="trustedTypes" turns the API into a DOM element — cache globalThis.trustedTypes at startup before any HTML rendering); cross-policy injection when two named policies with different sanitizer strictness exist and policy routing is user-controlled; TrustedScriptURL enforcement for Worker() source validation (origin allowlist in createScriptURL callback is the single validation point). SkillAudit findings: CRITICAL −24 no require-trusted-types-for 'script' in CSP, CRITICAL −22 default policy with identity transform, HIGH −18 window.trustedTypes referenced directly (DOM clobbering bypass), HIGH −16 attacker-controlled policy routing, MEDIUM −12 createScriptURL allows wildcard origin, MEDIUM −10 unexpected policy in getPolicyNames().
Read post →
2026-06-20 · Workers · postMessage · SharedArrayBuffer · MCP Servers

MCP Server Worker Thread Message Security: postMessage Structured Clone vs Eval Deserialization, SharedArrayBuffer Race Conditions, and Worker Termination on Auth Failure

Web Workers and Node.js worker_threads are used in MCP servers to offload CPU-bound tool execution — AST parsing, cryptographic operations, ML inference, sandboxed code evaluation — away from the main event loop. The postMessage structured clone algorithm is safe by design: it cannot transport executable code. The security boundary breaks the moment the worker calls eval(), new Function(), or vm.runInThisContext() on received data — four failure patterns covered in depth (eval on expression, require() from message path, vm.Script misuse, JSON.parse reviver class instantiation). SharedArrayBuffer shared memory between pool workers creates TOCTOU race conditions: rate limit counters modified with plain assignment are bypassed under concurrent load; the fix is Atomics.add() and Atomics.compareExchange() for all shared state. SharedArrayBuffer also enables Spectre-class timing oracles in worker pools where untrusted code runs. Worker termination is a security primitive: auth failure or injection attempt detected in a worker is a security event requiring worker.terminate() and pool replacement, not an error to catch and continue from. importScripts() in classic workers bypasses page CSP; module workers apply page CSP to all imports. Worker pool session isolation requires no module-level mutable state — all invocation state scoped to the message handler and cleared in finally. SkillAudit findings: CRITICAL −24 eval on received data, CRITICAL −22 require(data.path) without allowlist, HIGH −20 SharedArrayBuffer without Atomics, HIGH −18 module-level session state in pool worker, HIGH −16 importScripts(data.url) in classic worker, MEDIUM −12 no worker termination on security events.
Read post →
2026-06-20 · WebRTC · DTLS · Signaling Security · MCP Servers

MCP Server WebRTC Data Channel Security: DTLS Fingerprint Verification, ICE Candidate Injection, SDP Tampering, and Signaling Server Authentication

WebRTC data channels skip the server-side relay for high-frequency peer-to-peer MCP tool delivery — but removing the relay removes the central authentication point. Security moves to the DTLS handshake, the SDP exchange, and the signaling server, each with a distinct failure mode that breaks the security model while leaving the connection alive. This post covers the full WebRTC MCP security stack: the DTLS fingerprint attack (DTLS encrypts the transport but only authenticates the peer if you verify the SDP fingerprint after the handshake — without verification, MITM is trivial); ICE candidate injection (injected ICE candidates force the connection through an attacker-controlled relay for traffic analysis or disruption); SDP offer/answer tampering (unsigned SDP lets the signaling server or a MITM replace the DTLS fingerprint, strip DTLS requirements, or add attacker ICE candidates); TURN credential exposure (long-lived or static TURN credentials in client JS give anyone your relay infrastructure); signaling server authentication as the root of trust (unauthenticated WebSocket signaling lets any party inject into any active session); data channel message validation (DTLS proves transport, not content — schema validation and size limits still required on every message); and pion/webrtc, aiortc, node-webrtc library-specific fingerprint verification patterns. SkillAudit findings: CRITICAL −24 no DTLS fingerprint verification, CRITICAL −22 unauthenticated signaling WebSocket, HIGH −20 unsigned SDP, HIGH −18 static TURN credentials, HIGH −16 ICE candidate injection via unauthenticated signaling, MEDIUM −12 no data channel message size limit.
Read post →
2026-06-19 · API Versioning · Schema Evolution · MCP Servers

MCP Server API Versioning and Backward Compatibility Security: Schema Evolution Attack Surfaces, Version Negotiation Exploits, and Forced-Upgrade Sunset Strategy

API versioning is almost always framed as a developer experience problem — how do you evolve a tool schema without breaking existing clients? The security problem is the inverse: backward compatibility creates a mechanism for bypassing the security controls you added in the new version. When you add a required tenantId field to a tool call for authorization, clients that claim the old schema version don't send it. If your server accepts the old version for compatibility, the authorization check is silently skipped. This post covers the full versioning security stack: the version negotiation attack (client claims an old schema version to bypass new security fields), secure version negotiation with a server-enforced MIN_SUPPORTED_VERSION floor, schema evolution risk classification (additive optional vs additive required vs type narrowing vs field removal), why version-conditional security logic is the root cause, removing bypass fields correctly with strict schema validation, the deprecated endpoint attack surface (monitoring decay, patch skew, auth drift), sunset strategy as a security operation (RFC 8594 Sunset headers, deprecated-version traffic metrics, hard removal date enforcement), protecting the version header from spoofing via session-bound schema version in server-issued tokens, and CI contract tests that replay old-schema requests to prevent regression. SkillAudit findings: CRITICAL −24 no minimum version floor in negotiation, CRITICAL −22 version-conditional security logic, HIGH −20 additionalProperties:true allows removed bypass fields, HIGH −18 version from client header not session token, HIGH −16 deprecated schema live 90+ days past sunset date.
Read post →
2026-06-19 · Message Queues · Async Architecture · MCP Servers

MCP Server Message Queue Security: Replay Attacks, Dead-Letter Queue Poisoning, Consumer Authentication, and Idempotent Tool Execution

Moving MCP tool calls to an async message broker (Kafka, RabbitMQ, SQS) shifts the threat model: broker replay attacks re-execute tool side effects (email sends, card charges, resource provisioning) because at-least-once delivery guarantees duplicates without application-layer deduplication. Dead-letter queues introduce a privilege escalation path — crafted messages that reliably fail main-consumer processing reach the DLQ consumer, which often runs with elevated permissions or is reviewed by operations engineers with production access. This post covers the full async MCP security stack: SASL/SCRAM and mTLS broker authentication per broker type (Kafka, RabbitMQ, SQS IAM), the idempotency key pattern with PostgreSQL reservation table and Redis-backed single-use SSE tickets for deduplication, DLQ hardening with original-context preservation and HMAC message signing, consumer group isolation for multi-tenant Kafka deployments, Zod schema validation with .strict() on all inbound messages, and envelope encryption with AWS KMS for sensitive tool argument fields. Includes a 12-item deployment checklist and SkillAudit findings: CRITICAL −24 unauthenticated broker, CRITICAL −22 no idempotency key on side-effectful tools, HIGH −20 DLQ elevation, HIGH −18 no message signing.
Read post →
2026-06-19 · Concurrency · Distributed Systems · MCP Servers

MCP Server Race Conditions Beyond Shared Memory: Distributed Locking, Optimistic Concurrency, and Idempotency Keys for Multi-Instance Deployments

In-process mutexes are useless across process boundaries. The moment you run two MCP server instances behind a load balancer, every Mutex.lock() becomes a local no-op for cross-instance coordination. This post covers the real distributed concurrency stack for multi-instance MCP deployments: Redis distributed locks with atomic SET key value NX PX ttl and compare-and-delete release via Lua script to prevent releasing another holder's lock; Redlock for multi-Redis quorum (⌊N/2⌋+1) when a single Redis node is a single point of failure; optimistic concurrency control with version columns (UPDATE ... WHERE version = N returning rowCount 0 on conflict, triggering exponential-backoff retry); and the idempotency key pattern for exactly-once side effects (email send, charge, job enqueue) — reserving the key in a dedupe table with INSERT ON CONFLICT DO NOTHING before executing the side effect, deleting on failure so retries are permitted. Includes interleaved execution test patterns that reliably reproduce race conditions in CI. SkillAudit findings: CRITICAL −24 unguarded read-modify-write on shared records, CRITICAL −22 in-process-only mutex in multi-instance deployment, HIGH −18 external API call in retry loop without idempotency key, HIGH −16 Redis lock missing compare-and-delete, HIGH −14 idempotency key generated server-side.
Read post →
2026-06-19 · CSP · Browser Security · MCP Servers

MCP Server Content Security Policy Deep Dive: Nonce-Based Inline Scripts, strict-dynamic, and report-uri Monitoring for Browser-Based Agent UIs

Browser-based MCP server UIs render tool output that may contain attacker-controlled content — a prompt-injection payload that causes HTML injection sets up XSS with full access to every tool the authenticated session can call. A production-grade CSP closes the XSS surface permanently. This post is the complete playbook: building the baseline from default-src 'none', per-request nonce generation with crypto.randomBytes() (never reused, Cache-Control: no-store to prevent cached-nonce attacks), 'strict-dynamic' trust propagation to eliminate CDN host allowlists, sandboxed iframes for tool output rendering using blob URLs with sandbox="" to prevent script execution and same-origin access, style-src hardening against CSS injection and attribute exfiltration attacks, upgrade-insecure-requests for mixed content, and report-uri violation telemetry with rate-limited collection endpoints. Includes the complete production policy string, CSP mistake grid (unsafe-inline, static nonce, wildcard script-src, missing frame-ancestors, rendering tool output in main document context), deployment checklist, and SkillAudit findings: CRITICAL −24 no CSP on authenticated UI, CRITICAL −22 unsafe-inline in script-src, HIGH −18 static nonce, HIGH −16 missing frame-ancestors, HIGH −14 tool output in main document context.
Read post →
2026-06-19 · SSRF · Advanced Patterns · MCP Servers

MCP Server SSRF Advanced Patterns: DNS Rebinding Chains, Cloud Metadata Exploitation, IPv6 Bypass, and TOCTOU in URL Validation

Basic SSRF prevention — blocking 127.0.0.1 and 10.0.0.0/8 in a URL allowlist — stopped being sufficient years ago. Four advanced patterns defeat allowlist-only defenses: DNS rebinding (attacker-controlled domain resolves to a public IP at validation time, then re-resolves to 169.254.169.254 at fetch time because TTL=0 forces re-resolution), cloud metadata service exploitation (AWS IMDS v1 at 169.254.169.254 returns IAM role credentials with no authentication — a single SSRF to /latest/meta-data/iam/security-credentials/ yields rotating AWS keys), IPv6 notation bypass (::1, ::ffff:127.0.0.1, ::ffff:7f00:1, fc00::1 all route to loopback or private ranges and bypass IPv4-only blocklists), and the TOCTOU race between dns.resolve() at validation time and the re-resolution that fetch() triggers. Covers the isBlockedIPv4/isBlockedIPv6 CIDR check implementation, the safeFetch() pattern that connects to the resolved IP directly (preventing re-resolution), AWS IMDSv2 and why it doesn't fully eliminate SSRF risk if PUT requests are possible, IPv4-in-IPv6 hexadecimal decoding, and redirect chaining defense (re-validating every redirect destination through the same SSRF check). Complete Node.js implementations of safeResolveUrl() and safeFetchWithRedirects(). SkillAudit findings: CRITICAL −24 fetch() with unvalidated user URL confirmed to reach IMDS, CRITICAL −22 DNS rebinding window open (hostname passed to fetch() for re-resolution), CRITICAL −20 IPv4-only blocklist missing ::1 and ::ffff forms, HIGH −18 redirect following without re-validating destination, HIGH −16 no network-layer SSRF block (iptables / security group), HIGH −14 only first DNS result checked.
Read post →
2026-06-18 · Supply Chain · npm · MCP Servers

MCP Server Supply Chain Security: npm Lockfile Integrity, Typosquatting Detection, and Provenance Attestation

The most dangerous vulnerability in an MCP server is often in the code you installed, not the code you wrote. A compromised npm dependency — whether via typosquatting, account takeover of a popular package's maintainer, dependency confusion, or a malicious postinstall script — delivers arbitrary code execution inside your MCP server process at install time. This post covers the full npm supply chain attack surface and a six-layer defense: using npm ci for lockfile-verified deterministic installs (and why npm install in CI is insufficient), running npm audit --audit-level=high as a required CI gate, detecting typosquat packages via Levenshtein edit-distance checks against a known-legitimate allowlist, verifying npm provenance attestation (Sigstore-backed publish provenance linking each tarball to the specific CI run that produced it), blocking install-time script execution with ignore-scripts or a curated postinstall allowlist, and pinning direct dependencies against the lockfile integrity hash. Includes a complete GitHub Actions workflow, a typosquat-check.js script, a planned dependency update workflow with git-diff lockfile review, and an audit checklist.
Read post →
2026-06-18 · Security · Behavioral Detection · MCP Servers

MCP Server Behavioral Intrusion Detection: Building a Session Anomaly Detector from Scratch

Static analysis catches the vulnerabilities baked into MCP server code at rest; a behavioral intrusion detector catches the attacks that unfold at runtime. This post builds a complete session anomaly detector in Node.js: a per-session record tracking call velocity (sliding-window timestamps, not calendar-minute counters), tool sequence ring buffer, privileged-tool set, and anomaly score accumulator. Five scoring rules — velocity (30/60/120 CPM thresholds with +5/+15/+40 deltas), error rate (30%/60% thresholds), first-time privilege escalation (within 5s = +25, after 5 minutes of low-privilege calls = +15), Shannon entropy on argument strings (entropy >4.5 bits/char signals base64 exfiltration encoding = +10), suspicious sequence pairs (readFile→callUrl, readSecret→callUrl = +30). Composite thresholds: log at 10, alert at 40, block and clear session at 80. Includes full implementation of SessionRecord, anomaly-scorer.js, and behavioralIDS middleware. Handler-first ordering rationale: execute then score catches errors as signals; add pre-execution velocity block as the one exception where volume risk outweighs diagnostic value. SkillAudit findings: CRITICAL −20 no session identity, HIGH −16 no tool call logging, HIGH −14 no privilege classification, MEDIUM −10 no rate limiting.
Read post →
2026-06-18 · Architecture · Zero-Trust · MCP Servers

MCP Server Zero-Trust Architecture: Never Trust, Always Verify at the Tool Call Level

Zero-trust for MCP servers is not about network segmentation — it is about applying the principle at the unit of damage: the individual tool call. Four principles adapted for the MCP threat model: (1) verify identity on every tool call via per-call JWT check + Redis revocation set, not just at session establishment; (2) treat every tool argument as adversarial with two-layer validation (Zod structural + semantic SSRF/path-traversal/injection checks); (3) sanitize every tool response before injecting into LLM context with external-data envelopes, content filtering, and size caps; (4) attenuate scope on every agent delegation via intersected capability tokens with delegation depth limits. Includes Node.js implementations of each principle — withPerCallAuth(), validateFetchArgs() with DNS-resolved IP check, sanitizeToolResult() with injection pattern detection, and delegateScope() with parentJti chain tracking. SkillAudit findings: CRITICAL −24 session-only auth, CRITICAL −22 unvalidated URL arguments, HIGH −16 raw tool responses injected to LLM context, HIGH −18 sub-agent delegation without scope attenuation.
Read post →
2026-06-18 · Security · HTTP · MCP Servers

MCP Server HTTP Request Smuggling: CL.TE, TE.CL, and CONNECT Tunneling Behind Reverse Proxies

HTTP request smuggling exploits disagreement between a reverse proxy and the origin server about where one HTTP/1.1 request ends and the next begins. For MCP servers deployed behind Caddy, nginx, AWS ALB, or Traefik, the consequence is severe: an attacker who can route requests to the same server can inject tool call requests into other users' active sessions, bypass authentication headers added by the proxy, and hijack SSE streams mid-stream. Covers CL.TE (front-end uses Content-Length, back-end uses Transfer-Encoding), TE.CL (front-end dechunks, back-end stops at Content-Length), TE.TE obfuscation via malformed Transfer-Encoding values, and CONNECT tunneling for proxy bypass. Explains why MCP SSE endpoints amplify the risk: a smuggled request injected during an active SSE session is delivered to the victim's Claude stream as if it came from a legitimate tool execution. Node.js mitigations (reject simultaneous Content-Length and Transfer-Encoding, explicit CONNECT rejection), Caddy configuration (H2 transport to back-end, header_up -Transfer-Encoding), nginx configuration (proxy_http_version 1.1 + proxy_set_header Connection "", OpenResty Lua CL+TE rejection), and end-to-end HTTP/2 as the definitive fix. Proxy-specific quick-reference table for Caddy, nginx, AWS ALB, HAProxy, and Traefik. SkillAudit findings: CRITICAL −24 CL.TE confirmed, CRITICAL −22 TE.CL confirmed, HIGH −18 CONNECT method not rejected, HIGH −16 H1.1 keep-alive to origin without normalisation, HIGH −14 TE.TE obfuscation accepted, MEDIUM −8 no H2 support on back-end listener.
Read post →
2026-06-18 · Security · Secrets Management · MCP Servers

MCP Server Secrets Rotation Without Downtime: Dual-Key Overlap, AWSCURRENT/AWSPREVIOUS Patterns, and In-Process SIGHUP Reload

Rotating secrets in a continuously-running MCP server is uniquely hard: the server can't restart to pick up new credentials without dropping every active Claude session, and a rotation window where the old key is revoked before the new one is distributed causes live tool call failures. This post covers four patterns: dual-key overlap for external API keys (issue new key → distribute → revoke old after TTL), AWSCURRENT/AWSPREVIOUS fallback for AWS Secrets Manager (fallback to AWSPREVIOUS on 401 during rotation window), SIGHUP-based credential cache invalidation (lazy TTL cache + process.on('SIGHUP') handler avoids process restart), and JWKS kid rotation for JWT signing keys (add new kid → wait for cache propagation → start signing with new kid → wait for max token TTL → remove old kid). SkillAudit findings: CRITICAL −22 naive rotate-then-distribute causes live auth failures, HIGH −15 credentials cached in module scope with no reload mechanism, HIGH −12 database connection pool with stale credentials after rotation, HIGH −10 JWT JWKS rotation without overlap window.
Read post →
2026-06-18 · Security · SSTI · MCP Servers

MCP Server SSTI Deep Dive: Handlebars Sandbox Escapes, Nunjucks Template Injection, and EJS RCE in LLM Tool Handlers

Server-side template injection in MCP tool handlers is uniquely dangerous: the "user" providing the payload is often the LLM itself, manipulated by attacker-controlled content in tool results. A document the agent reads or a database row it queries can contain a Handlebars constructor chain escape or an EJS outputFunctionName RCE payload — and if the tool handler renders that content as a template, the attacker achieves RCE without ever talking to your server directly. This post covers all three template engine families (Handlebars, Nunjucks, EJS), their specific escape paths, why the Handlebars sandbox fails, how Nunjucks reaches process.mainModule, and the EJS outputFunctionName trick. SkillAudit findings: CRITICAL −25 Handlebars.compile() on user-supplied string (constructor chain escape), CRITICAL −24 Nunjucks nunjucksEnv.renderString() on tool result (process.mainModule.require chain), CRITICAL −23 EJS ejs.render() with user-supplied template (outputFunctionName RCE), HIGH −16 no template allowlist, HIGH −14 no sandbox configuration, MEDIUM −8 template compilation at request time. The fix for all three engines is the same: never compile or render user-supplied strings as templates — compile from trusted static sources at startup, pass dynamic values as data context only.
Read post →
2026-06-15 · Security · gRPC · MCP Servers

MCP Server gRPC Transport Security: TLS Configuration, Deadline Propagation, Metadata Auth, and Streaming Authorization

MCP servers that use gRPC as their transport layer or call upstream gRPC services face four distinct attack classes that REST servers don't: insecure channel credentials (createInsecure() leaves all traffic unencrypted and unauthenticated), missing deadline propagation (upstream gRPC calls run indefinitely after the MCP client disconnects), metadata credential leakage (logging all gRPC metadata exposes Authorization headers; blind metadata forwarding amplifies token scope across services), and streaming authorization drift (auth checked only at stream open — revoked credentials keep receiving streamed data until the stream closes). Covers Node.js @grpc/grpc-js patterns: one-way TLS and mTLS with combineChannelCredentials, deadline extraction from incoming gRPC context and propagation to outgoing calls, sanitizing interceptors that redact sensitive metadata keys, allowlist-based metadata forwarding, and periodic re-validation inside streaming handlers using Redis revocation sets. Control matrix: six controls × attack class, root cause, control, library, SkillAudit axis. SkillAudit findings: CRITICAL −24 insecure channel to internal gRPC service, CRITICAL −20 no deadline propagation, HIGH −16 full metadata logging, HIGH −14 blind metadata forwarding, HIGH −12 no re-validation in streaming handlers, MEDIUM −8 server reflection enabled in production.
Read post →
2026-06-15 · Security · GraphQL · MCP Servers

MCP Server GraphQL Security: Introspection Abuse, Batch Query DoS, Field-Level Authorization Bypasses, and Query Complexity

GraphQL MCP servers expose a wider attack surface than REST: introspection reveals the full schema to any caller in a single query, unbounded depth enables recursive DoS, aliases allow batching hundreds of operations in one HTTP request bypassing per-request rate limits, and field-level authorization must be enforced in every resolver — not just the root query that first surfaces a type. This post covers all four attack classes with Node.js defenses. SkillAudit scan of 400+ MCP servers found 62% with introspection enabled in production, 71% with no query depth limit, 54% with no complexity budget, and 38% with field-level authorization gaps. Implementations for NoSchemaIntrospectionCustomRule (blocks all introspection including __type), graphql-depth-limit (depthLimit:7 rejects recursive queries before execution), graphql-query-complexity (maximumComplexity:1000 with per-field cost annotations for list joins), graphql-armor alias limits (maxAliases:15 closes batch bypass), graphql-shield per-field rules (canReadApiKeys fires regardless of which query path reaches the User type), and custom formatError stripping stack traces and internal error details. Control matrix table: seven controls × attack class, root cause, library, and SkillAudit axis. SkillAudit findings: CRITICAL −25 introspection enabled in production, CRITICAL −22 no depth limit, HIGH −18 no complexity limit, HIGH −16 no alias limit, HIGH −15 field-level auth gaps, MEDIUM −10 field suggestions enabled, MEDIUM −8 internal error details in extensions, LOW −4 no complexity logging.
Read post →
2026-06-16 · Security · Sessions · Authentication

MCP Server Session Fixation and Hijacking: Stateful Session Attacks in Long-Lived LLM Agent Contexts

Stateful MCP servers that issue session IDs to track authenticated agent contexts are vulnerable to session fixation (attacker pre-sets a session ID before authentication; if the server does not regenerate it on login, the attacker's known ID becomes an authenticated session) and session hijacking (stealing an authenticated token via network interception over plain HTTP, XSS in a companion web UI, or predictable token generation). Long-lived LLM agent sessions make these attacks worse: a hijacked session may give an attacker hours of autonomous agent actions under legitimate credentials with no human checking for anomalous behavior. Covers three attack scenarios with Node.js code: pre-auth session fixation via saveUninitialized: true and how session.regenerate() breaks the attack, token theft over plaintext HTTP transport with TLS enforcement and HttpOnly/Secure cookie patterns, and concurrent agent session race conditions with Redis WATCH/MULTI and agent-bound HMAC tokens. Session ID generation: why crypto.randomBytes(32).toString('hex') is the only safe approach and why UUID v1, Math.random(), and timestamp-based IDs are predictable. Six-row comparison table covering fixation, hijacking, token interception, predictable IDs, concurrent sessions, and session timeout. SkillAudit grade impacts: CRITICAL −25 (no session regeneration after auth), CRITICAL −22 (tokens over plain HTTP), HIGH −15 (no session expiry), HIGH −12 (predictable session IDs), HIGH −10 (concurrent agent sessions sharing mutable state), MEDIUM −6 (no invalidation on agent context reset), MEDIUM −4 (missing Secure/HttpOnly flags on session cookies).
Read post →
2026-06-15 · Security · Caching · Multi-Agent

MCP Server Cache Poisoning: How LLM Agents Can Poison Shared Caches to Corrupt Other Sessions

When multiple LLM agent sessions share a Redis or in-memory cache keyed by tool name and arguments, a malicious prompt injection can pre-populate cache keys with adversarial responses that any future session reads as legitimate tool output. This post covers three attack classes: predictable key pre-population (attacker controls the first fetch of a URL that gets cached, poisoning all subsequent sessions), cache stampede injection (race the repopulation window after cache invalidation to insert malicious content), and cross-session state injection via shared writable cache tools (prompt injection calls set_note with attacker-controlled values that other sessions read as policy). Why LLM agents are uniquely vulnerable: no result provenance tracking, instruction-following from tool output, and multi-session fan-out from a single poisoning event. Mitigations with code: per-session namespace isolation (prefix all cache keys with session ID to break the shared key space), HMAC-signed cache values (timingSafeEqual verification, reject unsigned entries as cache misses), short TTLs (≤5 minutes for agent-influenced values), strict namespace separation between agent-readable policy keys and agent-writable session keys, and cache provenance metadata in tool results. Production checklist with seven controls. SkillAudit grade impacts from CRITICAL −25 (shared writable cache, no session isolation) to MEDIUM −4 (no stale-while-revalidate for long-TTL entries).
Read post →
2026-06-14 · Security · Sandbox · Systems

MCP Server Runtime Sandbox Design: Isolating Tool Execution with vm.runInContext, Worker Threads, and Seccomp

MCP tool handlers run code paths shaped by LLM-generated inputs and perform privileged operations — file reads, HTTP fetches, database queries — inside a shared server process. Without isolation, a single prompt injection that redirects a tool handler reaches the filesystem, environment variables, and credentials of the entire process. This post covers three isolation layers that compose to contain the blast radius: vm.runInContext for V8-context sandboxing (separate global object with no prototype chain connection to the host context, CPU timeout to block infinite-loop event-loop starvation, stripped context that excludes require/process/global), Worker threads for event-loop and heap isolation (separate V8 isolate with a separate heap, resourceLimits.maxOldGenerationSizeMb to cap memory per worker, hard terminate on timeout, worker pool for latency-sensitive servers), and kernel-level containment with Node.js 22 --permission flags (--allow-fs-read/write allowlists, network blocking, no child process spawning) and seccomp-bpf Docker profiles (SCMP_ACT_ERRNO for execve, ptrace, mount — blocking the syscalls needed for privilege escalation). Comparison table across six isolation dimensions: heap isolation, filesystem isolation, network isolation, subprocess spawning, overhead, and complexity. Threat-model guide for choosing the right layer: vm for pure transformations (~0ms overhead), Worker+vm for I/O-bound execution (10–20ms), subprocess+permissions for user-authored code (20–100ms). Four common misconfigurations with code: passing require or process into the vm context, omitting the timeout, accepting non-string code input, and not calling worker.terminate() on timeout. SkillAudit grade impacts from CRITICAL −25 (eval with no sandbox) to MEDIUM −5 (sandbox context includes fetch).
Read post →
2026-06-14 · Security · WebSocket · Networking

MCP Server WebSocket Security: Authentication, Message Framing Attacks, and Connection Lifecycle

WebSocket-based MCP servers give up the per-request stateless model that HTTP security is built on — there is no CORS preflight, no per-request auth header, and no request-scoped rate limiting. A single upgrade handshake opens a long-lived channel that stays open for hours while an LLM agent makes dozens of tool calls. Covers the complete attack surface: cross-site WebSocket hijacking (CSWSH — cookies are sent on the WebSocket upgrade so a browser page at attacker.com can open a full bidirectional channel using the victim's credentials), upgrade-time authentication (the correct pattern validates the JWT before calling handleUpgrade(), not in a first-message auth phase that leaves the connection open before identity is established), three message framing attack classes (ping flood exploiting the RFC 6455 requirement to auto-respond to every Ping, message fragmentation-based size bypass with the ws library's default 100 MB maxPayload, and control frame injection via proxy desync), connection lifetime auth drift (JWT expires mid-session but the WebSocket stays open), per-identity rate limiting that spans reconnects (reconnect cycling bypasses per-connection limits), and secure close sequences (application codes 4001–4004 for auth/session events, no error details in close reason string). Seven-step security checklist with code for each. SkillAudit grade impact table: no upgrade-time auth CRITICAL −20, no Origin validation HIGH −12, default maxPayload HIGH −10, no connection TTL HIGH −8, per-connection rate limit only MEDIUM −6, no ping rate limiting MEDIUM −5, error details in close reason MEDIUM −5.
Read post →
2026-06-16 · Security · Architecture · Authorization

MCP Server Authorization Models Compared: Capability-Based vs. Role-Based vs. Policy-Based for LLM Agents

RBAC grants a role and that role's permissions apply to everything in the session — including every tool call an LLM agent makes autonomously. This breaks silently under agentic use because agents compose tools in ways no human anticipated, hold ambient authority for the entire session, and cannot be interrupted when a prompt injection redirects their goal. Compares three authorization models for MCP servers: capability-based tokens (narrow scope at task issuance, UCAN delegation for sub-agents, short TTL, explicit revocation — the fix for ambient authority), role-based RBAC (fast and auditable for simple single-tenant servers with trusted human callers, broken for multi-step agentic sessions), and policy-based OPA/Cedar (cross-call session-state rules, business-hours constraints, chain detection — earns its complexity cost only at enterprise scale). Includes working Node.js implementations for all three, a seven-row comparison table covering ambient authority risk, cross-call rule support, delegation, implementation cost, and prompt injection resistance, and a SkillAudit Permissions axis grade impact table. The minimum viable capability implementation takes 30 minutes to add to an existing RBAC server.
Read post →
2026-06-15 · Engineering · Supply Chain · Security

MCP Server Supply Chain Risk: How a Compromised npm Dependency Becomes a Compromised Tool Handler

A single malicious package in your MCP server's dependency tree can silently exfiltrate credentials, tamper with tool responses, or phone home on every tool call — all without touching your own code. Covers why MCP servers are a high-value supply chain target (elevated credentials, tool argument visibility, no egress filtering), a worked example showing how a compromised transitive dependency (fast-str four levels deep) exfiltrates every credential-pattern environment variable on a 60-second interval, three attack vectors specific to MCP servers (process.env credential scanning, tool argument interception and response tampering, dependency confusion via unscoped internal package names), the four controls that stop supply chain attacks (npm ci lockfile-strict, lockfile hash verification in CI, npm audit exit-code enforcement, provenance attestation for direct dependencies), a complete GitHub Actions workflow enforcing all four, runtime egress monitoring via https.request intercept to detect compromised dependency phone-home, dependency tree assessment commands, SBOM generation with CycloneDX, and a grade impact table mapping each supply chain gap to a SkillAudit finding and grade delta.
Read post →
2026-06-14 · Engineering · Observability · Security

MCP Server Security Monitoring and Alerting: What to Alert On, Threshold Calibration, and How to Avoid Alert Fatigue

A practical framework for monitoring MCP servers for security events in production: four alert categories (authentication failures, anomalous tool call patterns, data volume and exfiltration signals, configuration and filesystem tampering), threshold calibration from baseline traffic (not from a blog post), alert routing by severity tier (P0 pages on-call in 15 minutes, P1 alerts team channel within 4 hours, P2 batches to daily digest), SIEM integration for cross-server correlation and retrospective investigation, append-only log forwarding that survives incident tampering, and the three most common monitoring mistakes (logging only in error handlers, including credential values in logs, alerting on every anomaly equally). Includes the minimum viable monitoring setup (one security logger, two events, one alert rule, one external sink) that takes 2–4 hours to implement and surfaces real security signals within the first week. SkillAudit grade impact table mapping each observability gap to a finding severity and grade delta.
Read post →
2026-06-13 · Security · Attack Patterns · Authorization

MCP Server Tool Chaining Attacks: Read-to-Write Privilege Escalation via Chained Tool Calls

Three concrete attack chains showing how an attacker with only read-only MCP tool access escalates to full write access or RCE — without touching a single exploit. Covers env-var extraction to API takeover (read_file → .env → fetch_url with Stripe key), contact enumeration to mass PII exfiltration (list_contacts × 1000 → send_message to attacker), and database schema discovery to shell execution (query schema → write_file malicious script → UPDATE cron_jobs). Defenses: tool category composition guards (retrieval/mutation/external), session-level aggregate rate limits (max 5 retrievals before external call), write-intent parameters that break automated chain construction, executable path allowlisting for filesystem write tools, and per-session audit log with chain detection. Includes grade impact table mapping each structural pattern to a SkillAudit finding and grade delta.
Read post →
2026-06-13 · Engineering · Testing · Security

MCP Server Security Testing with Vitest: Unit Tests for Auth, Input Validation, and Error Handling

A practical guide to writing Vitest unit tests that verify the security properties of your MCP server — not just functional correctness. Covers four test suites: auth bypass tests (missing token, expired token, IDOR, and DB short-circuit verification), input validation edge cases (path traversal, null bytes, oversized inputs, and a parameterized adversarial battery), error information leakage tests (FORBIDDEN_LEAK_PATTERNS helper that checks every error path for stack traces, internal paths, and DB error strings), and rate limiter per-caller isolation tests. Includes a GitHub Actions workflow with coverage thresholds on auth and error-handling files, and a grade impact table mapping each test category to the SkillAudit finding it covers.
Read post →
2026-06-13 · Engineering · Error Handling · Security

MCP Server Error Handling: What to Return When Something Goes Wrong

A complete engineering guide to the four error categories every MCP server must handle — input validation, authorization, downstream service errors, and unexpected panics — with safe response patterns for each. Covers why raw error messages and stack traces earn HIGH findings, how to write a thin ToolError abstraction that keeps internals out of responses, why authorization and not-found errors should look identical to prevent resource enumeration, and how to log errors with argsHash correlation without leaking credential values. Includes grade impact table and a three-file setup you can copy into any MCP server.
Read post →
2026-06-13 · Tutorial · Architecture · Security-First

Building a SkillAudit-Ready MCP Server From Scratch: Security-First Architecture Walkthrough

A complete step-by-step tutorial for building an MCP server that achieves and maintains an A grade. Covers all six audit axes with working Node.js code: startup config validation with Zod to reject placeholders and misconfiguration, per-call authentication with constant-time comparison, structured audit logging with argsHash for correlation without credential exposure, safe error abstraction that scrubs stack traces from callers, strict allow-list input schemas, rate limiting with per-tool per-caller windows, and a CI gate (GitHub Action) that blocks grade regressions from shipping. Each section explains why the pattern earns its score, not just what to copy.
Read post →
2026-06-13 · Incident Response · Case Study · Path Traversal

MCP Server Zero-Day: A 6-Hour Incident Timeline and What We Learned

A detailed 6-hour incident timeline: how a path traversal vulnerability in a popular MCP server was exploited, discovered, and patched — from first anomaly alert to coordinated disclosure. The vulnerability had been flagged as HIGH by SkillAudit 14 days before exploitation. Covers triage, scope assessment, credential rotation, patch development, coordinated disclosure, and five lessons every MCP server maintainer should take: input validation in tool parameters, actionable scan finding alerting, anomaly detection value, credential scope, and emergency disclosure timelines.
Read post →
2026-06-12 · Security · Checklist · Pre-deployment

MCP Server Security Audit Checklist: The 15-Point Pre-Deployment Review

A practical 15-point security checklist for MCP server developers covering authentication, input validation, secrets handling, logging, and transport security — with explicit pass/fail criteria for each control. Covers API key validation, per-tool authorization, token expiry enforcement, confirmation gates for write tools, schema validation, shell and path injection prevention, prompt injection defense, secrets hygiene, audit logging, error message exposure, and TLS enforcement. A checklist run takes 45–60 minutes; SkillAudit automates 11 of the 15 controls on every push.
Read post →
2026-06-12 · Security · Agentic AI · Architecture

The Ambient Authority Problem in MCP: Why Session-Level Auth Isn't Enough for Agentic AI

Ambient authority lets any tool in an MCP server act with the full power of the session token — regardless of what the user intended. A single prompt injection exploiting ambient authority is a session-wide compromise, not just a single-tool compromise. Covers the attack model, per-tool capability scoping as the solution, orchestrator-side token issuance, argument injection defense, and a migration path from session-level to capability-based auth.
Read post →
2026-06-12 · Compliance · Financial Services

MCP Server Security for Financial Services: PCI-DSS, Cardholder Data, and Agentic AI Tool Access to Payment APIs

When AI agents use MCP servers to call Stripe, Plaid, or internal banking APIs, they bring the agentic layer into PCI-DSS scope. Covers CDE boundary definition, scope classification for common MCP patterns, the seven most-impacted PCI v4.0 requirements (Req 3/4/6/7/8/10/11), CHD log redaction implementation, per-invocation audit trail structure, network segmentation architecture, service account discipline for Req 8, prompt injection as a payment fraud vector, and how to frame MCP servers in a QSA assessment.
Read post →
2026-06-14 · Compliance · Healthcare

MCP Server Security for Healthcare: HIPAA, PHI Protection, and Agentic AI Tool Access

When AI agents use MCP servers to query EHR APIs or FHIR endpoints, HIPAA's Technical Safeguards apply to the MCP server layer. Covers Business Associate obligations, 45 CFR 164.312 audit logging requirements, minimum necessary access design patterns, per-call authentication, encryption requirements, and breach notification triggers for MCP tool call data containing PHI.
Read post →
2026-06-13 · Security Operations

The MCP Server Security Review Checklist: 50 Questions for Teams

A 50-question security review checklist for MCP servers organized into 8 domains: authentication, authorization, input validation, network security, secrets management, supply chain integrity, observability, and incident response. Includes severity tiers (Blocker/Major/Minor), the precise evidence to look for in source code, and a scoring summary table for team review meetings.
Read post →
2026-06-12 · Authentication Security

JWT algorithm confusion attacks on MCP servers: RS256→HS256, alg:none, and weak HMAC secrets

JWT algorithm confusion (CVSSv3 9.8) lets an attacker forge a valid-looking token using only the server's public key. A SkillAudit scan of 400+ MCP servers found 14% vulnerable to at least one pattern: RS256→HS256 confusion (attacker signs with HS256 using public key bytes as the HMAC secret), alg:none bypass (unsigned tokens accepted), and weak HMAC secrets (crackable offline in seconds). Includes the exact one-line fix for each pattern and how SkillAudit detects them via tree-sitter static analysis.
Read post →
2026-06-11 · Security Architecture

MCP server secrets management: Vault, AWS Secrets Manager, and the .env anti-pattern

61% of community MCP servers store credentials in .env files; 18% have at least one committed to git history. This guide covers the five exposure vectors of .env secrets, the runtime fetch pattern with AWS Secrets Manager and HashiCorp Vault, secret rotation without server restart using a TTL cache, and the per-request audit trail that makes secret access auditable — with WRONG/RIGHT Node.js patterns for each.
Read post →
2026-06-11 · Security Architecture

MCP server sandboxing: running untrusted tool code in isolated processes

Three isolation layers for MCP servers that execute community plugins or user-supplied code: the Node.js vm module (JavaScript context boundary), Worker threads (separate V8 isolate), and Docker sidecars (OS-level namespace isolation). Includes a comparison table of what each layer blocks — filesystem access, network connections, prototype pollution, fork bombs, supply chain — and a decision guide for choosing the right layer for your threat model.
Read post →
2026-06-11 · Developer Guide

MCP server observability: what to log, what not to log, and how to use logs for security detection

A complete guide to structured logging for MCP servers: the four event categories every server must emit, the no-log list (argument values, response bodies, credentials), and the eight detection rules that turn your log stream into a real-time security sensor.
Read post →
2026-06-12 · Open-Source Guide

MCP server security for open-source maintainers: what reviewers check in 2026

The Anthropic Skills Directory review process now requires a security review before listing. This guide covers what reviewers actually check (six axes, automated scan + human review), why servers get rejected, the SECURITY.md and CONTRIBUTING.md templates that prevent 80% of rejections, and a pre-submission self-assessment checklist ordered by rejection risk.
Read the post →
2026-06-11 · Developer Guide

How to harden an existing MCP server without breaking integrations

A six-phase additive hardening path for live MCP servers — observe, warn-only input validation, soft rate limiting, shadow authentication, command injection hardening, and permission scoping — each phase with an enforcement gate you flip only after verifying zero legitimate triggers in your warn-only logs. No surprise breaks for existing callers.
Read the post →
2026-06-10 · DevSecOps Guide

MCP server security for DevSecOps: integrating SkillAudit into CI/CD pipelines

Shift security left: wire SkillAudit grade-gates into GitHub Actions, GitLab CI, and pre-commit hooks so insecure MCP servers never reach the registry. Complete workflow YAML, fail-open vs fail-closed strategies, axis-level policy gating, SBOM export for SOC 2, and an exemption workflow that doesn't become a rubber-stamp.
Read the post →
2026-06-10 · Developer Guide

MCP server input validation: beyond Zod — custom validators, allow-lists, and adversarial LLM inputs

Zod validates shape and type, but not semantic safety. A filename that parses as a valid string can still be ../../etc/passwd; a URL that passes the schema check can still resolve to an internal metadata endpoint. This guide covers the four layers of input validation every MCP tool handler needs: schema parsing, semantic allow-listing (path traversal, SSRF, command injection), policy context, and output validation — with complete Node.js implementations and a full validated handler pattern.
Read the post →
2026-06-10 · Developer Guide

MCP server rate limiting deep dive: sliding window, token bucket, and adaptive throttling

Rate limiting is a security control, not just a reliability control. In the MCP context, a misbehaving or compromised LLM can call your tool in a tight loop, burn through API credits, or exfiltrate data at a rate that bypasses anomaly detection. This deep dive covers three production-ready algorithms — sliding window (most accurate), token bucket (burst-friendly), and adaptive throttling (load-aware) — with complete Node.js implementations, memory profiles, when to use each, and how SkillAudit grades rate limiting hygiene.
Read the post →
2026-06-10 · Developer Guide

When to reject a tool call vs return an error: defensive MCP handler design

The MCP spec gives you two ways to signal failure: throw an exception or return isError: true. Both signal failure, but the receiver is different — one goes to the client layer, one goes directly into the LLM's context. Choosing the wrong one creates retry loops, leaks internal state, or silently swallows security violations. This post gives you the decision rules, a decision table covering every common failure case, and six detailed scenarios: auth failures, input validation, downstream errors, policy violations, timeouts, and suspected prompt injection.
Read the post →
2026-06-10 · Developer Guide

The top 10 MCP security mistakes developers make in their first server

The ten security mistakes that appear most often in first-time MCP servers — with the exact failing code pattern and the minimal fix for each. Hardcoded credential fallbacks, shell: true with user input, console.log left in production, missing path resolution guards, overly broad tool permissions, no rate limiting on expensive tools, verbose error messages returned to the LLM, prompt injection pass-through from external content, global state shared across sessions, and unauthenticated HTTP transport. Four Critical, four High, two Medium — and a fix effort of under 4 hours total across all ten.
Read the post →
2026-06-09 · Research Report

The MCP server security debt report: 30 days of scanning 500 community servers

We scanned 500 community MCP servers over 30 days. 36.7% had SSRF vulnerabilities. 43% had unsafe command-exec paths. 61% logged credentials in plaintext. This report breaks down the grade distribution across the corpus, the most common vulnerability categories by frequency and severity, security debt quantification per tier, the maintenance debt dimension, patterns in the highest-debt servers, and what the re-scan data shows about whether remediation actually sticks.
Read the post →
2026-06-07 · Developer Guide

How to write a SkillAudit-ready SECURITY.md for your MCP server

A SECURITY.md file is one of the highest-leverage, lowest-effort improvements you can make before publishing an MCP server. This guide explains section by section what the SkillAudit scanner checks — Scope, Credentials, Vulnerability Reporting, Logging, Known Limitations, and Audit History — with the point values, the common mistakes that drop your grade, a full copy-paste template, and a minimum viable SECURITY.md for when you need to pass the gate quickly.
Read the post →
2026-06-06 · Security Leadership

MCP server security for CISOs: executive briefing on LLM tool chain risk

MCP servers are the new shadow IT: they run on engineer laptops, hold production credentials, and execute code, yet most organizations approve them with no more scrutiny than a browser extension. This briefing covers the full threat model (supply chain, prompt injection, misconfiguration), a realistic incident walkthrough, how SkillAudit grades map to board-level risk tiers, the five controls that define a mature MCP security program, and a three-sentence board summary you can drop into your next risk review.
Read the post →
2026-06-07 · Product Management

MCP server security for product managers: translating SkillAudit grades into business risk

Your team wants to ship faster by adding new MCP servers. Your security team is worried. This guide gives product managers the vocabulary to translate A–F SkillAudit sub-scores into business risk language, communicate findings to leadership and legal, and build a lightweight four-step intake process that evaluates new servers without creating a security bottleneck. Covers the sub-score override rule, common PM mistakes, and when to involve legal.
Read the post →
2026-06-06 · Procurement & Governance

MCP server vendor security questionnaire: what to ask before approving internal adoption

Community MCP servers are typically evaluated with a GitHub star count and a README skim. This post gives procurement teams a 15-question security questionnaire covering SSRF, credential scope, prompt injection, dependency practices, and incident response — with the answers that should block adoption, how SkillAudit grades map to procurement risk tiers, a CI gate configuration for minimum grade enforcement, and a sign-off template for internal audit trails.
Read the post →
2026-06-05 · Remediation

From C to A grade: a week-by-week MCP server remediation plan

A C grade is not a rejection — it is a prioritized work order. This post turns the SkillAudit report into a concrete four-week remediation plan: week 1 fixes Critical and High security findings (SSRF, injection), week 2 reduces permission scopes to minimum, week 3 removes credential logging and hardcoded fallbacks, week 4 commits the lock file and adds a SECURITY.md. Includes expected sub-score progression and the 30-day arc from C (60) to A (88).
Read the post →
2026-06-05 · Security Architecture

The MCP server supply chain: trust boundaries from tool call to upstream API

Every MCP server sits at the center of a five-layer dependency graph. The attack surface that gets exploited spans all five: the LLM prompt boundary where adversarial context steers tool argument generation, the argument trust boundary where server code must validate LLM-supplied input as untrusted, the server code internals covering credential handling and logging, the npm dependency layer with ambient access to process.env and the network, and the upstream API credential scope and response content that can carry secondary prompt injection. Maps what SkillAudit checks at each layer and what a complete supply chain audit actually requires.
Read the post →
2026-06-05 · Policy & Governance

How to write an MCP server security policy for your organization

A template security policy for organizations adopting MCP servers internally. Covers grade thresholds by environment (A for production PII, B for internal data, C for dev), a GitHub Action CI gate that enforces minimum grades and blocks F sub-scores, the vendor assessment checklist for new adoptions, the exception workflow (60-day expiry, manager + security sign-off, stored artifact required), re-audit triggers beyond the 90-day cadence, and a condensed plain-text policy block you can drop into your internal wiki.
Read the post →
2026-06-05 · Compliance

MCP server audit trail design for SOC 2 and GDPR compliance

MCP servers that touch personal data or operate under SOC 2 scope need structured, tamper-evident audit logs. This post covers the minimum viable audit log schema (event_id, timestamp, session_id, user_id, tool_name, input_summary, outcome, data_classes, credential_ref), how to sanitize input_summary to avoid logging credentials or PII in plaintext, how to implement a SHA-256 hash chain for tamper-evidence, the SOC 2 criteria mapped to specific fields (CC6.1 logical access, CC7.2 monitoring, CC7.4 incident response), GDPR requirements (Article 30 RoPA, Article 15/20 Subject Access Requests, Article 17 right to erasure with the two-table architecture), a tiered retention scheme (90-day hot with PII, 12-month warm without PII, 7-year incident archive), and a checklist for PR review before deploying any MCP server that touches production data.
Read the post →
2026-06-05 · Resilience Engineering

Designing for resiliency: how to build MCP servers that fail securely

Failure in an MCP server is not just an uptime problem — it is a security event. Without deliberate failure design, partial state, ambient credentials, and exploitable retry paths become the attack surface. This post covers eight patterns that turn failure into a security property: per-call timeout budgets with AbortController, circuit breakers that fast-fail on open upstreams, exponential backoff with full jitter to prevent retry storms, fail-closed authorization checks, idempotency keys for mutating tools, error message hygiene to prevent information disclosure via stack traces, graceful degradation with Promise.allSettled for multi-source tools, and connection pool limits with concurrent-call gates.
Read the post →
2026-06-04 · Security Methodology

The SkillAudit scorecard explained: how we grade MCP server security across six axes

A complete breakdown of every check we run, how findings map to severity levels, how axis scores are combined into a letter grade, and what you need to fix to move up. Covers the weights for all six axes (Security 35%, Credentials 25%, Permissions 15%, Maintenance 12%, Compatibility 8%, Documentation 5%), the HIGH/MEDIUM/LOW/INFO severity tiers with point deductions, the A–F letter grade thresholds, a worked example showing how a single path traversal finding drops a server from A to B, and what an A grade actually requires in practice.
Read the post →
2026-06-04 · Incident Response

MCP server security incident response playbook — what to do in the first 60 minutes

When a deployed MCP server has a confirmed security incident, the first sixty minutes determine whether you contain the breach or let it compound. This step-by-step playbook covers all six phases: confirming the incident and scoping the credential set (0–5 min), isolating the server and fencing credentials (5–15 min), rotating every long-lived credential without causing a cascading outage (15–30 min), preserving the audit log with a SHA-256 hash before log rotation (30–45 min), triaging what data was accessed and identifying the entry point (45–55 min), and communicating to vendors, stakeholders, and users (55–60 min). Also covers return-to-service validation and how SkillAudit's audit log history view supports both incident triage and post-incident verification.
Read the post →
2026-06-04 · Security Analytics

SkillAudit grade drift: how MCP server security scores change over time

A SkillAudit score is not a permanent seal of approval. Analysis of 30-day rescan data shows that Maintenance and Dependency axes regress in 87% and 74% of servers respectively — driven by time and the external advisory ecosystem, not code changes. Security and Permissions hygiene axes improve after authors read their first report. This post covers drift velocity by axis, the badge staleness problem, rescan cadence recommendations, and how to set a CI minimum-grade gate that accounts for drift rather than treating the point-in-time scan as a permanent approval.
Read the post →
2026-06-04 · Security Architecture

The minimal-footprint MCP server: building for security from the ground up

Most MCP security problems are architectural, not code-level — they stem from decisions made in the first hour. This guide covers six principles that collectively produce A-grade security from the first commit: stdio-only transport (no network attack surface), zero external dependencies (no supply-chain CVE exposure), per-tool credential isolation (blast radius bounded at the tool boundary), no shell invocation (no eval() or exec() on arguments), a declarative permission manifest (machine-readable blast-radius declaration), and an immutable append-only audit log. Includes a 60-line template you can drop into any new MCP server project.
Read the post →
2026-06-04 · Security Methodology

Why MCP server security scanning is different from code scanning

Semgrep finds exec(userInput). It does not find the tool description that makes an LLM call exec() on untrusted input. This post maps the five gaps between traditional SAST and MCP-specific security scanning — prompt injection via tool descriptions, capability pairing amplification, trust boundary violations, context-window exfiltration, and maintenance drift — with a side-by-side coverage table showing what SAST catches, what MCP-specific scanning catches, and what falls through both.
Read the post →
2026-06-03 · Security Architecture

Threat modeling an MCP server from scratch: the STRIDE approach

Most MCP servers ship without a threat model. STRIDE — Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege — gives you a structured framework to enumerate attack classes before writing a line of code. This post applies each STRIDE letter to the three MCP trust boundaries (caller→server, server→backend, tool description→model), with a concrete attack scenario, real mitigation code, and SkillAudit check name for each. Ends with a 30-minute threat model exercise you can run on any MCP server today.
Read the post →
2026-06-03 · Security Testing

Property-based fuzzing for MCP server security testing

Unit tests verify the cases you thought of. Property-based fuzzing generates thousands of adversarial inputs automatically — path traversal strings, null bytes, Unicode bypass variants, boundary integers — and breaks your tool handlers before attackers do. Uses fast-check (Node.js) and Hypothesis (Python) to express four security properties: path containment, no exception leakage, numeric bounds, and Unicode blocklist bypass. Includes CI integration with fixed seeds, the shrinking advantage for minimal failing cases, and a ready-to-drop 30-line template for any MCP server project.
Read the post →
2026-06-03 · Security Research

Anatomy of a prompt injection attack on an MCP server — kill chain trace

A step-by-step kill chain trace from planted document to exfiltrated secrets: how an attacker embeds a malicious instruction in a workspace file, waits for the user to ask the LLM to summarize it, and uses the LLM's own tool calls to read credentials and exfiltrate them via a webhook — without the user seeing any indication. Covers why correct path checks and HTTPS validation don't stop it, six defenses that actually work (domain allowlists, sensitive-file exclusions, trust tagging, capability separation, user confirmation gates, audit logging), and what SkillAudit's red-team check looks for.
Read the post →
2026-06-03 · Security Research

The ten most common SkillAudit C grades — and what they share

After auditing hundreds of MCP servers, ten finding patterns account for most C grades: argument logging leaking credentials, over-declared permissions, unvalidated URL schemes, stack trace disclosure, implicit env var reads, shell:true with user-controlled args, unchecked numeric bounds, unsandboxed file paths, unaddressed medium advisories, and stale maintenance signals. All ten share one root assumption: that the caller is always trustworthy. Includes pre-screen checklist and the B-grade path for each finding.
Read the post →
2026-06-03 · Security Architecture

Building a multi-agent MCP pipeline that doesn't trust itself: security isolation between agents

Identity verification stops impersonation — it does nothing against a compromised orchestrator that sends verified instructions to its workers. This post covers the three-layer model for multi-agent MCP pipeline security: privilege isolation by agent role (orchestrator vs. worker), command allowlists on cross-agent tools (no run_command surfaces), and confirmation gates on irreversible operations. Includes the threat model table showing what each compromised agent can do with and without the three layers applied.
Read the post →
2026-06-03 · DevOps

MCP server security CI/CD pipeline: a complete build pipeline audit checklist

Most MCP servers ship without a single automated security check in CI. This post builds the complete pipeline: pre-commit hooks with ESLint and semgrep, a SkillAudit grade gate in your GitHub Actions PR workflow, lockfile enforcement with npm ci, a shell script that validates declared permissions against actual API usage in source, and branch protection settings that make a security regression impossible to merge. Includes the full combined GitHub Actions YAML and a minimum-viable vs. full-pipeline comparison table.
Read the post →
2026-06-02 · Deep Dive

The ambient token problem: how LLM-controlled credential selection enables silent exfiltration

When multiple credentials are in scope for an MCP server, the model — not the code — selects which one to use. A prompt injection instruction can direct that selection to an attacker endpoint. Three real scenarios (credential-name argument, credential-store tool, credentials in descriptions), the complete exfiltration kill chain, why static analysis misses it, and the per-tool credential isolation fix that eliminates the attack surface entirely.
Read the post →
2026-06-02 · Forensics

Five MCP servers that nearly earned an A — and what they fixed to get there

A forensic look at five near-miss MCP servers that scored B or C on first SkillAudit scan. Each got four or five of six axes right — but one specific pattern tripped them. Covers a database bridge leaking connection strings on error, a filesystem tool with over-declared write permissions, an HTTP proxy with unchecked SSRF, a sandbox with a misleading manifest, and a notification dispatcher vulnerable to tool-description injection. The exact finding and the fix for each.
Read the post →
2026-06-02 · Buyer Guide

MCP server security for non-technical buyers: a 10-minute field guide

A plain-language guide for team leads evaluating MCP servers for internal adoption. What each SkillAudit axis measures — Security, Credentials, Permissions, Maintenance, Compatibility, Documentation — what A through F grades mean in practice, and a three-outcome decision framework (install / review first / block) for turning an audit report into an adoption decision. No code required.
Read the post →
2026-06-02 · Research

30-day re-scan delta: what moved on a fresh recrawl of the 101-server MCP corpus

Thirty days after publishing the initial 101-server MCP security scan, we re-ran the full corpus. 7 of 67 F-graded servers improved. 6 were archived or deleted. 88 were unchanged. The vendor-official tier: still zero improvements. Here's the full breakdown — what changed, which disclosure mechanisms drove improvement, and how we project the numbers to move through the rest of 2026.
Read the post →
2026-06-02 · Engineering

How to write a zero-finding MCP server: a step-by-step construction guide

Only two of the 101 servers in our corpus have zero HIGH findings across all six audit axes. Both share the same construction pattern: schema-first Zod tool design, an allowlist-based SSRF firewall, env-only credential isolation, a command execution allowlist (no shell: true), and a maintenance posture with exact pinning and Dependabot. This guide walks through each step with code you can copy, explains the WHY behind each decision, and closes with a complete reference skeleton that passes all six axes out of the box.
Read the post →
2026-06-01 · Research

MCP server security in 2026: state of the ecosystem mid-year update

Six weeks after publishing the 101-server corpus scan: 36.7% SSRF, 43% unsafe command-exec, 79% vendor-official F grades. Not a single vendor-official server improved after six weeks of public disclosure. Here's what changed, what didn't, where the attack surface is growing in H2 (multi-agent pipelines, event-driven architectures, GraphQL/gRPC proxies), and what a healthy MCP security posture looks like heading into the second half of 2026.
Read the post →
2026-06-01 · Engineering

The MCP server permissions checklist: 5 questions before you request org scope

The permissions axis is where the blast radius math is most unforgiving: a server that requests admin:org and has an SSRF vulnerability doesn't have two problems — it has one full-account-takeover problem. This checklist gives you five questions to answer before submitting to the Anthropic Skills Directory: GitHub Apps vs PATs, minimal scope declaration, permanent vs ephemeral tokens, credential-in-URL patterns, and LLM-controlled credential selection. Code examples for every fix and the exact SkillAudit finding for each.
Read the post →
2026-06-01 · Engineering

MCP server dependency pinning: a supply chain incident walkthrough

A floating ^ in your package.json is a standing invitation for npm to fetch whatever the upstream maintainer publishes next. This post walks through a concrete incident timeline — a compromised transitive dependency silently exfiltrating SSH keys and AWS credentials from 400 installers — then shows the three changes that prevent it: exact version pinning, lockfile integrity enforcement with npm ci, and a patch-only Dependabot configuration that delivers security updates within 24 hours of advisory publication.
Read the post →
2026-06-01 · Research

Vendor-official vs community MCP servers: updated security grade breakdown

Six weeks after our April 2026 scan, the grade distribution has not materially shifted: 79% of vendor-official MCP servers in our corpus earn F, versus 26% of community-maintained servers. Only one vendor-official server (Microsoft Playwright) earns A. The counterintuitive finding: indie devs who understand the SSRF and credential threat model outperform large corporate teams who ship MCP servers as afterthoughts. Grade distribution tables, three structural reasons behind the gap, what changed after public disclosure, and what it means for Anthropic's directory certification program.
Read the post →
2026-06-01 · Research

MCP server permission scope patterns — what the corpus shows

68% of corpus MCP servers request org-wide API scopes when only repo-level access is needed. This research post shows the three code patterns behind that number — OAuth app scope over-declaration, permanent tokens where ephemeral tokens would work, and credentials in URL parameters — explains the blast-radius math (SSRF × org-write = full account takeover), and gives the scope-down implementation that eliminates each finding without breaking functionality.
Read the post →
2026-05-31 · Engineering

GitHub Action gate: enforcing MCP security grades in CI/CD — the complete setup guide

The full CI/CD implementation guide for teams wiring a SkillAudit grade gate into GitHub Actions: lockfile diffing, observe-only mode, multi-agent-client support, org-level reusable workflows, the exception path with expiry tokens, a weekly re-scan cron with Slack alerts on grade regressions, branch protection integration, and the Team-plan version-pinned grade endpoint. Three complete workflow files, copy-paste ready.
Read the post →
2026-05-31 · Buyer Guide

How to Read a SkillAudit Report — Understanding Every Section of an MCP Security Audit

A complete field guide to every section of a SkillAudit report: what the six axis grades mean (Security, Credentials, Permissions, Maintenance, Compatibility, Documentation), when HIGH vs WARN vs PASS vs INFO applies, the install-gate decision framework for team leads (install / review first / block), and a prioritized fix order for authors. Includes the grade scale (A–F definitions with corpus context), how the badge and public permalink work, and the three gaps the current engine doesn't cover.
Read the post →
2026-05-31 · Engineering

MCP Server Security Testing: What Static Analysis Catches and What It Doesn't

An honest accounting of the SkillAudit v0.3 engine after 101 servers: what static AST/taint analysis reliably catches (SSRF, command injection, hardcoded secrets, credential echoes), what the LLM-probe layer adds (prompt-injection susceptibility scoring, scope vs. handler drift confirmation), and three finding classes neither layer handles well (cross-tool privilege chaining, long-lived session state, unsafe deserialization). Includes a 9-row coverage table mapping each finding class to each detection layer.
Read the post →
2026-05-31 · Security Research

MCP Server OWASP Top 10: What the Threat Map Actually Looks Like After 101 Servers

A field guide from running SkillAudit across 101 community and vendor-official MCP servers — which OWASP categories map cleanly onto Model Context Protocol, which stretch, and which three MCP-specific threats (credential echo into tool response, permission scope vs. handler drift, client compatibility drift) have no clean home in either the API Top 10 or the LLM Top 10. With corpus rates, priority order, and specific code examples for each class.
Read the post →
2026-05-31 · Hardening Guide

MCP Server Security Checklist: 12 Items Before You Publish

Across 101 MCP servers in the public corpus, 42 earned an F — and most of those failures trace back to the same dozen patterns. A 12-item hardening checklist covering every check the SkillAudit engine runs: SSRF prevention, command-exec gates, prompt-injection walls, credential handling, permission scope, dependency pinning, CHANGELOG discipline, client compatibility testing, and runnable documentation. One item per axis, with concrete grep commands for each and code patterns showing the before and after.
Read the post →
2026-04-30 · Engineering

Anatomy of a credential leak — four patterns across 38 of 101 MCP servers

Of the 101 community Model Context Protocol servers we audited, 38 emit findings on the credentials axis. The leaks group into four named patterns: 64 hardcoded secrets in source across 18 repos (30 OpenAI/Anthropic-style keys, 10 GitHub PATs, 8 Stripe test secrets, 6 AWS access keys, plus Slack and GitHub OAuth), 13 echoes of process.env / os.environ to stdout across 7 repos including Klavis-AI, PipedreamHQ, Honeycomb, mcp-use, punkpeye/fastmcp, Stripe agent-toolkit, and Pydantic AI, 1 error-message env-var echo at JetBrains, and 44 .env files committed to the repo tree across 28 repos. Why credentials are the one axis whose blast radius is unbounded by the host process — every leaked value travels with the LLM conversation. Bad-vs-good code shapes per pattern, install-gate rule, author + buyer checklists.
Read the post →
2026-04-30 · Research

Nine of 101 most-installed MCP servers are archived — what the maintenance signal looks like in 2026

Of the 101 community Model Context Protocol servers we audited, nine have been declared dead by their maintainers — eight of them vendor-official, including Azure (1,213 stars), Gmail Server (1,098 stars), Mem0, E2B, Pydantic Logfire, PostHog, Honeycomb, and two of Anthropic's own scaffolders. Four more haven't been pushed to in 365+ days; sixty lack a SECURITY.md disclosure file. The maintenance axis is the only one of the six that gets worse over time without anyone touching the code. Full list with grades, days-since-push distribution, and a four-signal install-gate framework. Calendar-axis counterpart to the anatomy-of-an-A post.
Read the post →
2026-04-30 · Engineering

Anatomy of an A-grade MCP server — five code patterns shared by the 19 that passed our 101-repo audit

Of the 101 community Model Context Protocol servers we audited, 19 earned an A and two earned a perfect 100. Reading their source side by side, the patterns that separate them from the 82 that didn't are five boring habits — no fetch(url) from a tool argument without an allowlist, no exec with template-string argv, env-vars read once at startup never echoed, narrow verb-shaped tool surface, and current maintenance signal. The single missing piece across 17 of 19 is the same: no SECURITY.md. The two perfect 100s (LangChain MCP adapters, Vectara) are explained, plus the Microsoft Playwright case study (A despite execSync in tests). Author and buyer checklists at the bottom.
Read the post →
2026-04-30 · Engineering

Engine v0.3 calibration delta — 22 grades moved when surface tiering shipped

SkillAudit engine v0.3 introduces surface tiering — findings in examples, benchmarks, top-level scripts, and installer code now deduct at lower weight than runtime tool surface. Across the 101-repo audit corpus, 22 grades moved: 9 letter promotions (Stripe F→C, Anthropic's MCP TypeScript SDK F→B as the corpus's first B, plus GitHub MCP, Grafana, Pydantic AI, MCP Go SDK, MCP Python SDK, MCP Quickstart, lastmile-ai), 8 within-band lifts (including Vectara A 90→100 — the corpus's second perfect score), and 5 honest cap-fix drops (punkpeye/fastmcp D→F, glips/figma-context-mcp D→F, plus three F-band internal moves) where v0.2's shared-cap bug had been silencing real production-source SSRFs. Every move named, every audit page linked.
Read the post →
2026-04-30 · Install guide

The MCP install shortlist — 19 community servers that earn an A in our 101-repo audit (April 2026)

Of the 101 most-installed Model Context Protocol servers we audited, 19 earned an A grade. The full shortlist grouped by use case (vector DBs, operational DBs, web fetch, backend platforms, voice, frameworks) — Pinecone, Qdrant, Milvus, Vectara, Meilisearch, Redis, ClickHouse, Couchbase, Snowflake, Exa, FireCrawl, DuckDuckGo, fetch-mcp, Microsoft Playwright, Appwrite, Box, FastAPI-MCP, ElevenLabs, and the LangChain MCP adapters at a perfect 100/100. The buyer-side counterpart to the vendor-official F-grades post.
Read the post →
2026-04-30 · Playbook

Block 52 of 101 community MCP servers with one CI gate — the 2026 team policy template

A min-grade-C team policy blocks 52 of the 101 most-installed Model Context Protocol servers in 2026, including 29 vendor-official releases your developers would have waved through on brand alone. The full policy paragraph, the 30-line GitHub Action that gates new installs on the SkillAudit grade, the re-scan cadence, the 12-week rollout calendar, and the four week-1 gotchas your security engineer will hit.
Read the post →
2026-04-29 · Research post

29 vendor-official MCP servers earned an F — every name, every file path

A line-by-line walk through every vendor-official MCP server in our 101-repo corpus that ended at an F grade — Cloudflare, Stripe, Heroku, MongoDB, GitHub, AWS, Azure, Auth0, Sentry, PostHog, Anthropic's own SDKs, and 18 more. Real findings, real file paths, honest calibration notes on where the engine is unambiguous and where it is still learning to subdivide runtime tool surface from examples and scripts.
Read the post →
2026-04-24 · Research post

We scanned 52 MCP servers — 56% had SSRF, 44% leaked credentials

SkillAudit's first 52-repo scan — vendor-official releases from AWS, Cloudflare, Stripe, MongoDB, Heroku, Redis, and indie frameworks — with every report public. Real grades, ranked F offenders, A-grade counterfactuals. (Corpus since expanded to 71; see the UPDATE banner inside the post.)
Read the post →
2026-04-23 · Launch post

Why 36.7% of community MCP servers fail a basic SSRF check

A public 2026 scan of community Model Context Protocol servers found SSRF in more than a third of them and unsafe command execution in 43%. Here is what that actually looks like in code, why existing dependency scanners miss it, and what we built about it.
Read the post →