The old AgentSeal article had the right instinct and the wrong hook. A headline about a percentage of risky MCP servers asks the reader to trust one statistic. The better article asks a more useful engineering question: before a team installs an MCP server, accepts a skill file, or shares a Codex setup, what can it test locally?

That is where AgentSeal is worth saving. The repository contains more than a security pitch. It has a local guard command, a prompt scan command, a live scan-mcp command, project policy, registry enrichment, baseline tracking, SARIF output, and source code that spells out which MCP risks are being flagged.

Why this seed is worth saving

The useful version of this article should not lead with the old 66% title. The stable source-backed value is the workflow. AgentSeal separates several agent-security jobs that teams often mix together: local machine inspection, system prompt probing, live MCP server checks, file watching, and policy configuration.

The README names four commands. guard scans skill files, MCP configs, toxic data flows, and supply-chain changes without an LLM. scan tests a system prompt against adversarial probes and needs a model. scan-mcp connects to stdio or SSE MCP servers and inspects tool descriptions. shield watches the same local paths over time. That separation makes it useful for Claude Code and Codex users because each command has a different adoption boundary.

Start with guard before adding tools

For a Codex or Claude Code repo, the first pass should be boring:

pip install agentseal
agentseal guard
agentseal guard --output sarif

Guard is the right first step because it scans the machine and project context, not just one prompt. The machine discovery source checks well-known agent config paths and project files. It knows about .mcp.json, .cursor/mcp.json, .vscode/mcp.json, mcp_config.json, CLAUDE.md, AGENTS.md, .cursorrules, and Codex CLI config under ~/.codex/config.toml. That means the tool can catch risk where agent behavior is actually configured.

Read MCP findings as permissions, not vibes

The MCP config checker is the strongest source anchor. It does not merely say a server is risky. It checks concrete permission and supply-chain conditions: access to .ssh, .aws, .gnupg, .npmrc, .docker, .kube, and other sensitive paths; hardcoded API keys; whole-home or root filesystem access; non-local HTTP; mutable npx, uvx, bunx, pip, docker, deno, and go run invocations; shell binaries; missing remote auth; known CVE patterns; and high-entropy secrets.

Those checks map cleanly to review decisions. MCP-001 and MCP-003 are stop-the-install findings for broad local access. MCP-002 means rotate or move a secret before continuing. MCP-007 means pin a package or image before a teammate copies the config. MCP-009 means a remote server should not become shared infrastructure until auth is explicit.

Scan live MCP servers separately

Static config review is not enough for tool metadata. AgentSeal's scan-mcp path connects to a live server, enumerates tools, then checks tool descriptions for poisoning. The README shows both common transports:

agentseal scan-mcp --server npx @modelcontextprotocol/server-filesystem /tmp
agentseal scan-mcp --sse http://localhost:3001/sse

This is the right place to catch a different class of problem: hidden instructions inside descriptions that tell the model to exfiltrate data, override user intent, or execute commands. The scan-mcp renderer reports a verdict, finding codes, severity, title, optional trust score, and tool count. Use that output as a review artifact before the MCP server enters .mcp.json or a team AGENTS.md setup guide.

Do not confuse prompt probes with MCP policy

AgentSeal's scan command is valuable, but it answers a different question. The JavaScript README describes 225+ attack probes and deterministic scoring with no LLM judge. The probe catalog splits the free set into 82 extraction probes and 143 injection probes; Pro-only groups cover MCP, RAG, and multimodal probes.

agentseal scan --prompt "You are a helpful assistant..." --model ollama/llama3.1:8b
agentseal scan --file ./prompt.txt --model gpt-4o --min-score 75

That belongs in prompt and agent-behavior testing. It should not replace local MCP config review. A system prompt can resist canary injection while an MCP server still has access to ~/.ssh. Conversely, a clean .mcp.json does not prove the agent will handle prompt injection well. Treat them as two gates.

Make policy explicit with .agentseal.yaml

A team adoption path needs policy, otherwise every finding becomes a debate. The project config source defines .agentseal.yaml fields for fail_on, allowed_agents, allowed_mcp_servers, ignore_paths, ignore_findings, and rules_paths. The important field is not only fail_on; it is ignore_findings with a reason.

Run agentseal guard init, then keep the file small. Put known team-approved MCP servers in allowed_mcp_servers. Keep fail_on at danger while you learn the signal. If a finding is intentionally ignored, write the reason and owner in the config review. A silent ignore list is just a new blind spot.

Registry enrichment is triage, not permission

The README points to an MCP Security Registry with thousands of scored servers, and the registry client shows how local results are enriched: package slugs are derived from npx, bunx, uvx, pip install, and docker run, then checked through a bulk endpoint for score, level, and finding count.

That is useful triage before installing an unknown MCP package. It is not permission to skip local review. Registry data can tell a reviewer which server deserves suspicion first. It cannot know the exact path arguments, environment variables, auth headers, or project-level config that your local setup is about to use.

The larger lesson is install discipline

AgentSeal matters beyond one scanner because MCP servers and skill files are becoming part of the agent supply chain. A team can now copy a server command from a README, add it to .mcp.json, and give an agent filesystem, browser, database, or SaaS access in minutes. That speed is useful, but it also makes review discipline easy to skip.

The right editorial frame is not fear. It is installation hygiene. Treat an MCP server like a dependency with permissions, runtime behavior, and update risk. Treat a skill file like executable policy that an agent may obey. AgentSeal gives the team a way to turn that concern into artifacts: a guard report, an MCP scan result, a registry match, and a reviewed .agentseal.yaml exception list.

Where AgentSeal should stop

AgentSeal should not be framed as proof that an agent stack is secure. It does not replace reading the MCP server source, pinning package versions, restricting filesystem paths, setting auth on remote servers, or reviewing the actual tool actions. It also should not be used to batch-quarantine files without a human reading what changed.

The practical use is a pre-install risk pass. Run it before a new MCP server enters the project, before a skill pack is copied into a team directory, before a prompt is promoted to production, and before a Codex setup guide tells teammates to trust a tool. If it finds a high or critical MCP issue, treat the finding as a blocker until a maintainer writes down the narrow exception.

Save AgentSeal as an MCP and skill risk-pass article. It is useful when the reader separates local guard checks, live MCP tool-description scans, and prompt red-team probes; it is unsafe when presented as a single security score or a substitute for source review.

Practical takeaway

Before adding a new MCP server to Claude Code, Codex, Cursor, or a shared AGENTS.md workflow, run agentseal guard, review every MCP finding, run agentseal scan-mcp against the live server, add only reviewed exceptions to .agentseal.yaml, and block team adoption until sensitive paths, secrets, remote auth, package pinning, and tool descriptions are clean.