What can you do with this server?

The agent-guardrail MCP server acts as a policy firewall for AI agent tool calls. It lets you evaluate, record, and audit agent actions before execution. * guardrail_check – Evaluate a proposed tool call (tool_name and arguments) against a policy, returning ALLOW, WARN (requires human confirmation), or BLOCK with an explanation. * guardrail_record_outcome – Record the real-world result (success or error) of a previously checked action, linked via request_id, for a persistent audit trail. * guardrail_agent_history – Retrieve a paginated history of recent decisions for a given agent_id, enabling review and accountability of past evaluations.

agent-guardrail

by rudimentall1

Overview Schema Source Related Servers Discussions Admin

Python

Local

Guardrail

agent-guardrail MCP server

📄 Read the white paper

A policy firewall for AI agent tool calls.

Your agent wants to run a shell command, send an email, or move money. Guardrail checks that request against rules you wrote, before it happens, and either lets it through, asks a human, or blocks it — with a plain- English reason every time.

60-second quickstart

git clone <this repo> && cd agent-guardrail
pip install -r requirements.txt

python3 cli.py check --agent trading-agent-001 --tool wallet.transfer \
  --args '{"amount": 9999, "to": "0xabc"}'

Or pip install guardrail-mcp gives you a guardrail command directly — same output, no repo checkout required (falls back to the policy bundled in the package if you don't point --policy at your own file):

guardrail check --agent trading-agent-001 --tool wallet.transfer \
  --args '{"amount": 9999, "to": "0xabc"}'

{
  "decision": "BLOCK",
  "matched_rules": [
    {"rule": "numeric_cap_exceeded", "severity": "BLOCK",
     "message": "amount=9999.0 exceeds cap 5 for 'wallet.transfer' (unknown agent)"}
  ]
}

That's it — no server, no account, no API key. policies/default.yaml is the file that decided this; open it and change the numbers to match your own rules.

Related MCP server: Agent Identity MCP Server

Why this, not another "AI risk scoring" tool

Most "AI agent security" projects (including an earlier project of mine) lean on statistical risk scores computed from data nobody can actually verify at build time — wallet age, "reputation," contract "risk" — which either requires paid data feeds you don't have yet, or quietly becomes mock data pretending to be real. Fine for prototyping, dishonest to ship.

Guardrail only makes claims it can back up. Every check is a deterministic rule — a blocklist entry, a regex match, a numeric cap, a rate limit — evaluated against a policy file you write and can audit yourself, backed by a real, persistent audit log (SQLite) you can query. Nothing here pretends to know something it doesn't.

It's also not blockchain-specific. Shell execution, email, HTTP requests, file deletion, database writes, crypto transactions — same engine, same policy file, same rules.

Four ways to use it

1. CLI — for testing a policy by hand

Shown above. No setup, instant feedback while you write rules.

2. MCP server (`mcp_server.py`) — the easy on-ramp, advisory

Exposes guardrail_check, guardrail_record_outcome, and guardrail_agent_history as MCP tools any MCP-compatible agent (Claude Desktop, Claude Code, custom MCP clients) can call.

{
  "mcpServers": {
    "guardrail": {
      "command": "python3",
      "args": ["/absolute/path/to/agent-guardrail/mcp_server.py"],
      "env": { "GUARDRAIL_POLICY": "/absolute/path/to/agent-guardrail/policies/default.yaml" }
    }
  }
}

Then tell your agent (in its system prompt) to always call guardrail_check before spending money, deleting data, messaging someone externally, or running code.

Be clear-eyed about its limit: like any MCP tool, nothing stops the calling model from just not invoking it. This only helps if the agent is instructed to always check first — for a guarantee it can't skip, see #3.

3. `guardrail.decorator.enforce` — the real guarantee

Wraps the actual Python function that performs a tool's side effect. The check runs in your code, before that function executes — the model never gets a chance to call the real function directly.

from guardrail.decorator import enforce, BlockedActionError

@enforce(engine, tool_name="send_email")
def send_email(agent_id: str, to: str, subject: str, body: str):
    ...  # only runs if the decision is ALLOW, or WARN-and-confirmed

Use this if you're building your own agent loop (LangChain, CrewAI, a custom MCP host, a Slack bot with tool access). Run python3 examples/example_agent_usage.py to see it block a real function call.

4. `guardrail.mcp_enforced_server.EnforcedGuardrailMCPServer` — the real guarantee, over MCP

The MCP server in #2 above is honest about being advisory: the model gets a guardrail_check tool, but nothing stops it from calling the actual tool (exposed by some other MCP server, or by the model's own direct access) without checking first, or checking one thing and doing another. If the model talks to your infrastructure only over MCP - no Python decorator possible - this is the same #3 guarantee for that case: the operator registers real action executors (the code that holds real credentials and performs the real side effect) as the only way the model can invoke that action at all.

from guardrail.mcp_enforced_server import EnforcedGuardrailMCPServer

def do_transfer(request):
    wallet = get_wallet_for(request.agent_id)  # real credentials, held here - never exposed to the model
    tx_hash = wallet.transfer(to=request.arguments["to"], amount=request.arguments["amount"])
    return {"tx_hash": tx_hash}

server = EnforcedGuardrailMCPServer(policy_path="policies/default.yaml")
server.register_action(
    "wallet.transfer", "Transfer funds from the agent's wallet.",
    input_schema={"type": "object", "properties": {"to": {"type": "string"}, "amount": {"type": "number"}}, "required": ["to", "amount"]},
    executor=do_transfer,
)
server.serve_stdio()

The model is given exactly one MCP tool named wallet.transfer - there is no separate, unguarded way to move funds through this server. A BLOCK decision means do_transfer never runs. Both this and enforce() share one implementation of "check, maybe route WARN to a human, run only if not blocked, report the real outcome back" (guardrail/enforcement.py) - not two independently-maintained copies of the same guarantee.

Getting a human to actually confirm a WARN

on_warn is the hook — Guardrail ships two ready-made implementations:

Local web UI (guardrail/confirmation/web_ui.py) — a tiny built-in server (stdlib only, no Flask) with Approve/Reject buttons. The wrapped function blocks until someone clicks one, or times out (fails closed — timeout means reject, not "allow by default").

from guardrail.confirmation.web_ui import ConfirmationServer

confirmation = ConfirmationServer(port=8787, timeout_seconds=300)
confirmation.start(open_browser=True)

@enforce(engine, tool_name="wallet.transfer", on_warn=confirmation.request_confirmation)
def transfer(...): ...

Try it live: python3 examples/example_web_confirmation.py, then open http://localhost:8787.

Terminal prompt (guardrail/confirmation/cli_ui.py) — for scripts and local testing where a browser is overkill:

from guardrail.confirmation.cli_ui import cli_confirm

@enforce(engine, tool_name="wallet.transfer", on_warn=cli_confirm)
def transfer(...): ...

Neither is required — on_warn is just a function (decision) -> bool, so a Slack message, a ticket, or anything else you already use works too.

Writing a policy

Policies are plain YAML — see policies/default.yaml for a real, working starting point (11 confirmation-gated tools, 10 destructive-pattern checks, numeric caps, domain rules, rate limits, all commented).

Rule type	What it checks
`blocked_tools`	Tool names that are never allowed
`confirmation_required_tools`	Tool names that always produce `WARN`
`argument_patterns`	Regex against the JSON-serialized call arguments — destructive shell commands, SQL, leaked credentials, path traversal, SSRF, force-pushes, regardless of which tool carries them
`numeric_caps`	Per-tool numeric field caps, tighter for agents with no history
`aggregate_caps`	A cap shared across several tools, tracked as one running total per agent — see below
`domain_rules`	Allow/deny lists on a URL or email-recipient field, per tool
`rate_limits`	Sliding-window call limits per (agent, tool), backed by SQLite

numeric_caps limits each tool independently — wallet.transfer capped at 1000/day and wallet.approve capped at 1000/day separately means an agent using both can still move 2000/day combined. aggregate_caps closes that: every tool listed in the same group draws from one shared running total, e.g.

aggregate_caps:
  daily_money_movement:
    tools:
      wallet.transfer: amount
      wallet.approve: amount
    window_seconds: 86400
    max_unknown_agent: 5
    max_known_agent: 1000

Only confirmed spend counts toward the total: a BLOCKed request never adds anything, and a request that's provisionally recorded (because its own check passed) is refunded if the real action later turns out not to have succeeded — engine.record_outcome(request_id, "error"), called automatically by both enforce() and the enforced MCP server (they share one implementation of this, guardrail/enforcement.py) when the real executor raises, or when a WARN a human rejects results in a BlockedActionError. Real enforcement of this therefore has the same caveat as everything else that depends on record_outcome being called: it works fully under enforce() and the enforced MCP server (see below); under the advisory-only MCP server (#2 above), a provisionally-recorded amount just stays recorded, since nothing ever reports back whether the action actually happened. See guardrail/storage/aggregate_spend.py's module docstring for the full picture.

No code changes needed to adjust any of this — edit the YAML, restart the process (or the MCP server).

Running the tests

pip install -r requirements.txt
PYTHONPATH=. python3 -m unittest discover -s tests -v

134 tests: rule evaluation, the full engine pipeline (real SQLite-backed rate limiting, aggregate spend tracking, and audit persistence), the enforce decorator and the enforced MCP server (both proving a BLOCK genuinely prevents the real action from running, sharing one implementation of that guarantee), the advisory MCP server's JSON-RPC handling, the confirmation web UI over real HTTP requests against a live server, and a dedicated suite that checks the shipped policies/default.yaml — not just synthetic test policies — actually catches what it claims to.

What's honestly still missing

Single-process SQLite by default. Fine for one agent process; for multiple replicas sharing rate limits/audit history, point every process at the same file on shared storage, or swap in a real database (the storage classes are small and easy to re-target).
Secrets/PII redaction in the audit log is on by default. AuditLog redacts values whose key looks sensitive (password, api_key, authorization, ...) and a couple of high-confidence value shapes (PEM private key blocks, JWT-shaped strings) regardless of key name, recursing into nested dicts/lists - see guardrail/storage/redaction.py for exactly what is and isn't caught, and why general-purpose entropy heuristics were deliberately left out (too many false positives on ordinary UUIDs/hashes). Pass AuditLog(redact=False) to store arguments as-submitted, or extra_sensitive_keys={...} to redact additional field names specific to your tools.
The default policy is a reasonable starting point, not a complete threat model. It catches well-known destructive shell/SQL patterns and obvious credential formats — extend argument_patterns for whatever your agents actually touch.
The confirmation web UI has no auth. It binds to 127.0.0.1 by design (not exposed on the network), but anyone with local access to that port can approve/reject. Fine for a single developer's machine; put it behind your own auth if multiple people share the host.

None of these are mocked or faked — they're just not built yet, and they're the honest next steps if you adopt this.

Publishing this / getting people to actually use it

See PUBLISHING.md for a concrete checklist: MCP directories to submit to, what a listing needs, and what "done" looks like.

Same author, same principle applied elsewhere:

agentic-wallet-guardian-v3 - a security decision layer for AI agents transacting on-chain. MIT, 112 tests.
x402-attest - cryptographically signed (Ed25519), independently verifiable attestations for agent-to-agent payment policy decisions. Early proof of concept.
open-agent-attestation - vendor-neutral open spec (JWT+EdDSA) for signing agent policy decisions, verifiable by anyone. x402-attest above uses a custom format; this is the generalized version. Draft v0.1.

Project layout

guardrail/
    __main__.py            CLI implementation — also the `guardrail` console command
    mcp_server.py            MCP stdio server — also the `guardrail-mcp-server` console command
    core/
        models.py               ActionRequest, RuleMatch, GuardrailDecision (stdlib only)
        policy.py                 Policy loader (the one place PyYAML is used)
    rules.py                    Deterministic rule evaluators
    storage/
        rate_limiter.py           SQLite-backed sliding-window rate limiter
        audit.py                    SQLite-backed persistent audit log
    engine.py                    GuardrailEngine — orchestrates rules + rate limit + audit
    decorator.py                 enforce() — the unbypassable integration point
    confirmation/
        web_ui.py                    Local web UI for human approve/reject (stdlib http.server)
        cli_ui.py                      Terminal-prompt confirmation
    policies/default.yaml           Copy of the default policy bundled into the installed package
policies/default.yaml       Canonical, editable default policy (git-clone workflow)
cli.py                      Thin shim -> guardrail/__main__.py (for `python3 cli.py`)
mcp_server.py                Thin shim -> guardrail/mcp_server.py (for `python3 mcp_server.py`)
pyproject.toml               Package metadata — `pip install .` gives you `guardrail` + `guardrail-mcp-server`
.github/workflows/ci.yml      Runs the test suite + policy validation + package build on every push
examples/
    example_agent_usage.py       Decorator basics
    example_web_confirmation.py    Real browser-based approve/reject, live
tests/                       46 unit tests, all runnable with just PyYAML installed
CONTRIBUTING.md              How to add a rule type, ground rules
CHANGELOG.md                  Version history
PUBLISHING.md                 How to actually get this in front of people
landing/index.html             Static one-page site (open directly or host on GitHub Pages)

Available Tools

3 tools

guardrail_agent_historyB

Return recent decision history for a given agent — a real, persisted audit trail.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No
`agent_id`	Yes

TDQS

B3.1/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden of behavioral disclosure. It only adds 'a real, persisted audit trail,' but does not explain ordering, pagination (beyond schema's default limit), authentication requirements, or the structure of the returned history. This is minimal transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence with no fluff. It front-loads the action and resource, and the dash-separated clarification adds value without excess length.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has no output schema and no annotations, the description is too sparse. It does not describe the return format, what constitutes a decision, or any limitations/pagination behavior, making it incomplete for an agent to invoke correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It only implies agent_id via 'given an agent' and never explains the 'limit' parameter or its default. No additional meaning is provided beyond the raw schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Return recent decision history for a given agent,' providing a specific verb and resource. The phrase 'a real, persisted audit trail' differentiates it from potentially transient data, and the sibling tools (guardrail_check, guardrail_record_outcome) suggest this is a historical lookup, distinct from check/record actions.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus the sibling tools. It does not specify scenarios, exclusions, or alternative tools, leaving the agent to infer usage solely from the tool name.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

guardrail_checkA

Evaluate a proposed tool call against the Guardrail policy BEFORE executing it. Returns ALLOW, WARN, or BLOCK with a concrete explanation. Always call this before performing any action that spends money, deletes data, sends messages externally, or runs code.

ParametersJSON Schema

Name	Required	Description
`agent_id`	Yes	Identifier of the calling agent
`arguments`	No	Arguments the tool would be called with
`tool_name`	Yes	Name of the tool/action being proposed

TDQS

A4.3/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the transparency burden; it discloses that the tool returns ALLOW, WARN, or BLOCK with a concrete explanation and implies it does not execute the proposed action. It could add explicit no-side-effect or error behavior, but for a guardrail check the core behavior is clearly conveyed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences: the first front-loads the purpose and output, the second gives a concrete usage rule. No words are wasted, and the structure makes the call conventions immediately findable.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers the essential aspects an agent needs: what it evaluates, when to call it, and the expected return values. Since there is no output schema, the explicit mention of ALLOW/WARN/BLOCK with explanations fills that gap well, making the description sufficient for this moderately complex tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already describes all three parameters, and schema coverage is 100%, so the description adds little beyond labeling the call as 'proposed'. This matches the baseline of 3 for fully schema-documented parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb-resource pair: 'Evaluate a proposed tool call against the Guardrail policy', which clearly identifies the action and subject. It also distinguishes the tool from siblings by emphasizing 'BEFORE executing it' and enumerating the return values (ALLOW, WARN, or BLOCK), making its role distinct from guardrail_record_outcome and guardrail_agent_history.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly says 'Always call this before performing any action that spends money, deletes data, sends messages externally, or runs code', which is strong when-to-use guidance. It does not name sibling alternatives or state when not to use it, but the 'before' framing implicitly separates it from outcome recording.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

guardrail_record_outcomeA

Record the real-world outcome (success/error) of a previously-checked action, for the audit trail.

ParametersJSON Schema

Name	Required	Description	Default
`outcome`	Yes
`request_id`	Yes

TDQS

A3.7/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden. It identifies the action as recording for an audit trail but does not disclose whether it overwrites existing records, whether it requires a prior guardrail_check, what happens if request_id is invalid, or any error behavior. This is insufficient for a write operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence that front-loads the action and purpose. Every word contributes meaning without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simple two-parameter schema and no output schema, the description is minimally adequate but could be more complete. It explains the audit trail purpose but omits important context such as whether the outcome is appended, overwritten, or how errors are handled. For a straightforward logging tool, this is acceptable but not comprehensive.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must compensate. It does clarify that 'outcome' is success/error, matching the enum, and 'previously-checked action' implies request_id is an ID from a prior check. However, it does not explicitly define request_id's format or source, leaving some ambiguity.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Record' and the specific resource 'real-world outcome (success/error) of a previously-checked action, for the audit trail.' It distinguishes itself from siblings by focusing on post-check outcome logging rather than checking or history retrieval.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase 'previously-checked action' provides clear context that this tool is for logging outcomes after a guardrail check has occurred, implying a temporal relationship with guardrail_check. It does not explicitly name alternatives or state when not to use it, but the context is clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

3 tool updatesv1.0.2Aug 10, 2026
- First observedguardrail_agent_history
- First observedguardrail_check
- First observedguardrail_record_outcome

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.9/5.0

Scored 2026-08-10 11:00 across 3 tools

Disambiguation5/5

Each tool covers a distinct phase of the guardrail lifecycle: pre-action evaluation, post-action outcome recording, and historical audit retrieval. There is no functional overlap between check, record_outcome, and agent_history, making tool selection unambiguous.

Naming Consistency4/5

All tools share a consistent 'guardrail_' prefix, with two using a verb_noun pattern (guardrail_check, guardrail_record_outcome). The third, guardrail_agent_history, uses a noun phrase instead of a verb, which is a minor deviation but still predictable and readable.

Tool Count5/5

Three tools is well-scoped for a guardrail server, providing the core operations of checking, recording, and viewing history without unnecessary bloat. This is within the ideal range and earns its place.

Completeness5/5

The tool set covers the entire guardrail workflow: evaluate before action, record the outcome afterward, and retrieve an audit trail. There are no obvious dead ends or missing critical operations for this focused domain.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Related MCP Connectors

secureflows-mcp A
io.github.michal-lefler
MCP server for secureFlows: token-free URL builders and integration-linting tools for AI agents.
Code Analysis Developer Tools Security
181
wallet-verifier-mcp B
com.wallet-connectors
MCP server for verifying EUDI/Talao wallet data via OIDC4VP (pull) for AI agents.
Security Blockchain Web3 & Decentralized Tech
12
microservices.sh
sh.microservices
MCP server for AI agents to plan, verify, and deploy Cloudflare-native apps.
Cloud Platforms Agent Orchestration Developer Tools
21
agentic-commerce A
io.bosonprotocol
MCP server for Boson Protocol — on-chain agentic commerce for physical & digital goods.
Blockchain E-commerce & Retail Autonomous Agents
632

Related MCP Servers

aip-identity
Autonomous Agents Security
The-Nexus-Guard
A
license
A
quality
D
maintenance
MCP server for AI agent identity — verify agents with Ed25519 signatures, check trust scores, sign and verify content, exchange encrypted messages. Built on the Agent Identity Protocol (AIP).
Updated 6 months ago (2026-03-09 12:03 UTC)
8
MIT
Agent Identity MCP Server
Security Autonomous Agents
AiAgentKarl
A
license
Not graded
quality
D
maintenance
MCP Server for AI agent identity and authorization. Create, verify, and manage agent identities with trust scores and scoped authorization tokens.
Updated 6 months ago (2026-04-03 16:05 UTC)
MIT
guardrails-mcp-server
Security AI & Machine Learning
ExpertVagabond
A
license
Not graded
quality
B
maintenance
MCP server for AI agent security guardrails. Provides input validation, prompt injection detection, PII redaction, output filtering, policy enforcement, rate limiting, and comprehensive audit logging.
Updated 13 days ago (2026-09-08 02:24 UTC)
42 npm
1
MIT
enterprise-auth-mcp-server
Security Developer Tools
AiAgentKarl
A
license
A
quality
D
maintenance
MCP server for enterprise authentication and authorization — JWT validation, OIDC token inspection, OAuth 2.0 introspection, and role-based access control for AI agents.
Updated 5 months ago (2026-04-06 08:37 UTC)
8
MIT

Guardrail

60-second quickstart

Why this, not another "AI risk scoring" tool

Four ways to use it

1. CLI — for testing a policy by hand

2. MCP server (mcp_server.py) — the easy on-ramp, advisory

3. guardrail.decorator.enforce — the real guarantee

4. guardrail.mcp_enforced_server.EnforcedGuardrailMCPServer — the real guarantee, over MCP

Getting a human to actually confirm a WARN

Writing a policy

Running the tests

What's honestly still missing

Publishing this / getting people to actually use it

Related projects

Project layout

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

2. MCP server (`mcp_server.py`) — the easy on-ramp, advisory

3. `guardrail.decorator.enforce` — the real guarantee

4. `guardrail.mcp_enforced_server.EnforcedGuardrailMCPServer` — the real guarantee, over MCP