SentinelAgent Guard: Protocol-Native MCP Security Firewall

SentinelAgent Guard: a protocol-native MCP security firewall

Andrax Pentester editorial. This page restores the Guard deep-dive URL that previously redirected away. Product home: guard.sentinelreign.com. Related on this site: Introducing MCPGrade, the live MCP scanner hub, and Guard vs grade-only scanners.

Claims about Guard below are taken from public product pages (home, docs, pricing, trust, demo) as of the restore date. They are not a substitute for Guard’s own documentation, and they are not invented CVE numbers or third-party certifications.

Why this article exists

Model Context Protocol (MCP) servers sit on the trust boundary of AI agents. A grade tells you what a scanner saw at a point in time. A firewall sits in the path of every tool call and decides what is allowed to run.

SentinelAgent Guard is positioned publicly as a firewall for MCP servers and AI agents: point the agent at Guard, and Guard mediates the session. Product copy describes deterministic checks on every call, with no AI model in the path of those checks — a different design choice from LLM-based judges that re-interpret each request.

This is Andrax’s research framing of where Guard fits next to MCPGrade (our free A–F grading lane on andraxpentester.in/mcp). We publish education and measurement here; Guard is the separate runtime product when you need mediation, not only a report.

Grade vs gate

A grade without a gate is useful inventory. A gate without honest measurement is opaque. Serious MCP deployments want both: measure with MCPGrade, enforce with a firewall such as Guard when the agent is production-critical.

See also: Guard vs Grade-Only MCP Scanners — the companion piece on why a letter grade alone is not a control plane.

What “protocol-native” means here

MCP is not “just another HTTP API.” Tools, resources, and prompts are first-class protocol objects. A protocol-native firewall reasons about:

1. Tool identity and schemas — what the agent thinks it can call
2. Descriptions and instructions — where tool-poisoning and prompt injection hide
3. Side effects — network, filesystem, credentials, exfiltration paths
4. Session continuity — rug pulls and schema changes after first trust

Guard’s public positioning emphasises deterministic checks rather than asking another model to “decide if this looks safe.” Determinism matters for auditability: the same input should yield the same allow/deny reason, without a per-call token bill for a judge model.

Public product copy also states that detection lives in an Apache-2.0 engine that can be read and re-run from source, and that the same engine can be run in multiple deployment shapes (hosted gateway, embedded SDK, stdio sidecar) so verdicts stay aligned. This site does not ship or modify that SDK; we only point at the product and the public documentation.

What public Guard pages say (evidence, not folklore)

The following bullets paraphrase published Guard marketing and docs. Re-check the live pages before you rely on a number in a procurement memo — products change.

Detection posture

• Guard is described as sitting in front of an MCP server and running a fixed set of deterministic checks (product copy cites 22 checks across five layers) on every call, blocking bad ones before they reach the agent.
• Checking is explicitly not done by an AI model in the request path, so decisions are intended to be repeatable and without a per-call model cost.
• The homepage demonstrates a Unicode concealment style attack (invisible code points in a tool description) and shows the engine blocking a tools/list path — an educational artifact generated as the page loads, not a claimed customer incident.
• Docs state the checks reference is generated from the engine registry, so the marketing table and the code are meant to stay aligned.

Rubric alignment

• Guard publicly references a versioned mcpgrade rubric (product copy cites mcpgrade-2.0.0) shared across scanner, CLI, and runtime surfaces so two surfaces should not grade the same server differently.
• Andrax’s free scanner on /mcp is the measurement lane readers use on this site. Rubric versions can evolve; treat letter grades as signals for review, not as cryptographic proof. Do not equate historical Andrax article figures (for example older mcpgrade-1.x writeups) with Guard’s published runtime rubric without checking both sources.

Deployment shapes and limits (as documented)

• Docs describe three ways to run the same engine: hosted gateway, embedded SDK, and stdio sidecar.
• Docs also list deliberate non-goals (for example certain JSON Schema constructs out of the L2 subset; sidecar CLI policy-file gaps; SSO labelled as Enterprise and not yet shipped where that is stated). A control’s limits belong in its documentation — Guard’s docs put some of those edges in public.

Pricing and trust posture (public)

• Pricing is published as self-serve, including a Free tier (product copy: one server, no card) with the claim that all core checks run on every tier; paid plans buy capacity, retention, seats, and compliance features — not a secret detection pack.
• The Trust Center states plainly that Guard does not hold a SOC 2 report, and lists verifiable substitutes (open engine, published prices, operator-boundary docs, DPA/privacy pages). That honesty is unusual in the category and is why we quote it carefully rather than inventing badges.

If any of the above conflicts with what you see on guard.sentinelreign.com tomorrow, trust the live product pages.

Threats this category is aimed at (high level)

These are categories, not claimed CVEs and not a guarantee that every check fires on every payload:

• Poisoned tool descriptions that steer the agent without the operator noticing
• Hidden-instruction / Unicode concealment payloads in tool metadata
• Rug pulls — a tool that changes behaviour or schema after first approval
• Malicious payloads riding in tool arguments or results
• Data theft / exfiltration when an agent has private context plus an outbound channel
• Unsafe server behaviour that a one-shot grade might miss between scans

For the agent-side attack narrative on this site, read MCP Tool Poisoning Explained and MCP Prompt Injection and the Lethal Trifecta. For hands-on inspection before you connect anything, use How to inspect an MCP server.

How this fits Andrax’s MCP lane

Andrax Pentester publishes research and education across whole cybersecurity, with MCPGrade as the flagship product lane on this domain:

1. Discover / inspect — How to inspect an MCP server, MCP Dorks
2. Grade — MCP scanner, directory, browser extension
3. Enforce — product pointer to Guard (this article)
4. Methodology — MCP Security Complete Guide, methodology, cheat sheet

We do not ship or modify Guard SDK code from this repository. Engine and SDK work live elsewhere; this page is editorial so the historical SERP URL returns a real article again instead of a permanent redirect into the MCPGrade intro.

Cross-links (intentional)

• From measurement to story: Introducing MCPGrade
• From grade-only debate: Guard vs grade-only scanners
• From practice: open /mcp and paste a server URL
• From product home: https://guard.sentinelreign.com

A practical workflow (grade, then decide on a gate)

1. Inventory the MCP servers your agents can reach. Prefer a written allowlist over tribal knowledge.
2. Inspect tools, resources, and prompts before first connect (inspect guide).
3. Grade with the free scanner at /mcp. Treat F / D grades as “do not connect yet,” not as “wire up and hope.”
4. Review schema and description text for concealment, over-broad tools, and destructive operations without human approval.
5. Decide whether a one-time grade is enough for a lab toy, or whether production traffic needs an in-path firewall. If you need mediation, evaluate Guard from its own docs and Free tier — do not expect Andrax’s scanner to block live calls.
6. Re-grade after version bumps, tool-list changes, or new auth surfaces. Trust decays.

Practical takeaways

1. Treat every new MCP server as untrusted until graded and reviewed.
2. Prefer deterministic mediation for production agents over “ask another LLM.”
3. Keep measurement (MCPGrade) and enforcement (Guard) as separate layers.
4. Re-grade after schema or version changes — trust decays.
5. Start at /mcp for free grades; open guard.sentinelreign.com when you need an in-path firewall.
6. Read Guard’s Trust Center for what is verified today (and what is not, including the public “no SOC 2” note).
7. Do not confuse this website’s brand with unrelated “ANDRAX” Android pentest projects — see Andrax Pentester vs Android ANDRAX.

Related reading on Andrax

• Introducing MCPGrade
• Guard vs grade-only scanners
• MCP Security: Complete Guide
• MCP Tool Poisoning Explained
• MCP Prompt Injection and the Lethal Trifecta
• How to inspect an MCP server
• Andrax Pentester vs Android ANDRAX (brand disambiguation)

---

Editorial restored 2026-09-23 for SERP URL continuity. Product claims defer to guard.sentinelreign.com. No CVE numbers are asserted here without a cited advisory. No Guard SDK packages are vendored from this site.