HISN حصن
Security audit for MCP servers and AI agent stacks. One command, zero dependencies, free.
Your agent can read files, call APIs and run commands. Almost nobody audits it like it can.
Get told when it ships See the attack surface
Being built in the open — no release yet
$ hisn scan ./my-mcp-server HISN · auditing against MCP security best practices CRITICAL token-passthrough server.ts:142 Accepts a client-supplied bearer token and forwards it downstream without checking the audience claim. Spec: servers MUST NOT accept tokens not issued to them. CRITICAL authz-url-scheme oauth/handler.ts:61 Authorization URL opened without scheme validation. A javascript: URL here becomes XSS, then RCE over stdio. HIGH session-as-auth session.ts:28 Session ID alone authorizes requests, and is not bound to a user identifier. HIGH ssrf-metadata-discovery discovery.ts:19 OAuth metadata URL fetched with no private-range block. 169.254.169.254 reachable — cloud credentials exposed. MEDIUM scope-catalog-inflation manifest.json scopes_supported publishes the full catalog, including a wildcard scope. PASS redirect-uri exact match · consent per client_id · secure session entropy · no shell URL opening ───────────────────────────────────────────────────────────── 2 critical · 2 high · 1 medium · 4 passed report → hisn-report.html · sarif → hisn.sarif
Illustrative output. HISN has not shipped yet — this shows the intended report shape, not a real scan.
Seven attack classes, named by the protocol itself
These are not hypotheticals invented to sell a tool. Every one below is documented, with MUST and MUST NOT requirements, in the Model Context Protocol's own security best practices. HISN exists to check whether your server actually honours them.
Consent that gets skipped
A proxy server with a static client ID plus dynamic registration lets an attacker ride an existing consent cookie, and the authorization code lands on their redirect URI instead of yours.
Tokens that were never yours
Forwarding a client's token downstream without validating its audience bypasses rate limiting, breaks the audit trail, and turns your server into an exfiltration proxy. The spec forbids it outright.
The metadata endpoint
OAuth discovery fetches URLs a malicious server controls. Point one at
169.254.169.254 and cloud credentials walk out — with DNS rebinding
defeating naive validation.
Session IDs are not authentication
Guessable or unbound session identifiers allow impersonation, and on resumable streams they allow injecting a payload the original client will act on.
Servers run with your privileges
A one-click config can carry a startup command that reads your SSH keys and posts them out. The user sees a friendly install button, not the command.
From a URL to code execution
A javascript: authorization URL becomes XSS. In proxy architectures
that spawn processes over stdio, that XSS escalates into remote code execution on the host.
Wildcards widen the blast radius
Publishing the full scope catalog and granting it up front means one stolen token unlocks every tool at once, and revoking it breaks every workflow.
OWASP LLM Top 10
Findings map to the 2025 list where they correspond — LLM01 prompt injection, LLM03 supply chain, LLM05 improper output handling and LLM06 excessive agency — so a report means something to a security reviewer who has never heard of MCP.
The tools you already run do not check this
This is the honest case for HISN. If your existing stack covered it, there would be no reason to build it.
Dependency scanners
Socket and Snyk read your manifest and tell you which packages are malicious or vulnerable. Essential — and they never open your OAuth handler to see whether it validates a redirect URI.
Model red-teaming
Promptfoo and similar tools fire probes at a model and grade the replies. That tests behaviour. It does not read your server's configuration or its token handling.
Generic SAST
Static analysis finds injection and unsafe calls in general code. It has no concept of an MCP session, a scope catalog, or an audience claim that belongs to a different service.
HISN
Reads the server implementation and the client configuration, and checks them against the protocol's own MUST and MUST NOT clauses. One narrow job the others were never built to do.
Built on an engine that already runs
HISN is not starting from nothing. It extends the engine behind DIRA — zero dependencies, local analysis, SARIF output, CI gating, all already written and tested.
Scan
Point it at an MCP server directory or a client config file. Pure local analysis, no account, no telemetry.
Share
-f html produces a report you can hand to a reviewer.
-f sarif lands findings in GitHub's Security tab.
Gate
A CI workflow and pre-commit hook, so a regression fails the build instead of reaching production.
Fix
Every finding cites the specific spec clause it violates, so the report teaches the requirement rather than just flagging a line.
What it is not
It has not shipped. There is no download on this page because there is nothing to download yet. This page exists so the work is public while it is being built.
HISN will be automated pattern analysis. It does not replace a penetration test, a threat model, or a security review by a human who understands your trust boundaries.
A clean run will mean "no known bad patterns in this configuration". It will not mean your agent is safe to hand a production credential.
It cannot evaluate the one risk that matters most in agent systems: whether a tool should exist at all. Excessive agency is a design decision, and no scanner makes it for you.
Your code will never leave your machine. Local analysis, no telemetry, no account, and any detected credential redacted before it reaches a report — the same constraints DIRA already ships under.
Know the day it ships
MIT licensed. Free forever. No account, no telemetry, no paid tier.
Leave your email and you'll hear once, on release day. Nothing else, ever.
Used for this one announcement. Legal Privacy · all waitlists