nomos-guard
v1.0.0
Published
Policy gateway for MCP — wrap any MCP server so every tool call is checked against a sealed NOMOS governance artifact before it executes. Allow, deny, or escalate, with a cryptographic audit hash on every verdict.
Maintainers
Readme
nomos-guard
The policy gateway for MCP. Wrap any MCP server so every tool call is checked against a sealed governance policy before it executes.
MCP standardizes how an agent discovers and calls a tool. It doesn't say whether that call should be allowed. nomos-guard is the missing layer:
Agent ──▶ nomos-guard ──▶ your MCP server ──▶ your system
│
└─▶ sealed .nomos policy
allow → forwarded, executed
deny → blocked, with the rule that fired + an audit hash
escalate → held for human approvalThe downstream server needs zero changes and never knows the guard exists. The policy isn't a prompt or a config file — it's a cryptographically sealed artifact (open spec) that can't be silently edited, and every verdict carries an audit hash.
Try it in 60 seconds — no account, no API key
Wrap any server with a public demo policy. Here, a refund policy (pub_refund_v1: auto-deny past the return window, escalate refunds over $1,000, allow the rest):
{
"mcpServers": {
"payments": {
"command": "npx",
"args": [
"-y", "nomos-guard",
"--artifact", "pub_refund_v1",
"--",
"npx", "-y", "your-payments-mcp-server"
]
}
}
}Everything after -- is the command that starts the server you're guarding. That's the whole integration.
Ask the agent for a $50 refund on last week's purchase → executes. Ask for $1,500 → the agent is told, verbatim:
ESCALATED by governance policy: this call requires human approval before it can proceed. Rule R6 — Refunds over $1,000 require dual approval. Audit hash: sha256:… Do not retry with altered arguments to evade this policy.
Writing policies for tools
The guard passes the tool's arguments as the policy inputs and injects a tool field with the tool's name. So rules can gate on argument values:
refunds over $1,000 → escalate
and on which tool is being called at all:
tool == "drop_table"→ deny
Public demo artifacts (no key needed): pub_refund_v1, pub_lending_v1, pub_fraud_v1, pub_hr_leave_v1, pub_kyc_v1. To govern with your own policy, seal one from your actual policy documents at nomosprotocol.com (takes about a minute), then pass its artifact ID plus --api-key.
Flags
| Flag | Env var | Meaning |
|------|---------|---------|
| --artifact <id> | NOMOS_ARTIFACT | Sealed artifact to enforce. Required. |
| --api-key <key> | NOMOS_API_KEY | Required for custom (non-pub_) artifacts. |
| --api-base <url> | NOMOS_API_BASE | Defaults to the hosted NOMOS API. |
| --fail-open | — | Forward calls if the policy check itself is unreachable. |
| --agent-id <id> | NOMOS_AGENT_ID | Identifies the calling agent in NOMOS's decision log. Defaults to nomos-guard:<downstream server name> if not set. |
Every check also tags the decision with the MCP tool name being called, so NOMOS's logs show "agent X's call to tool Y" — not just a bare verification.
Default is fail-closed. If the governance check can't run, the call is blocked — a guard that silently waves calls through when the policy engine is down isn't governance. Use --fail-open only if you've decided availability beats enforcement for that server.
What gets guarded
tools/call— every invocation is checked. This is the guard.tools/list— passes through untouched; discovery is MCP's job.- Resources and prompts — passed through when the downstream supports them. The guard governs actions.
Verdicts are auditable, not just enforced
Every allow, deny, and escalate returns an audit hash chained into the NOMOS decision log. The policy itself is a sealed artifact: signed with Ed25519, verifiable offline by anyone with the published public key — so "what policy was in force when the agent did X" has a cryptographic answer, not a shrug.
- Spec: github.com/nomos-spec/spec
- Platform: nomosprotocol.com
- The NOMOS tools themselves as an MCP server:
nomos-mcp
License
MIT
