Vizier
A local (stdio) guardrail helper for screening proposed AI agent actions and checking content, not an enforcing authorization service.
Screen/authorize actions (
vizier_screen_action): pass anaction_type(tool_call, shell_command, payment, database_write, external_api, file_modification, mcp_proxy) and exacttargetplus optional parameters, agent_id and principal_id; get an ALLOW / REVIEW / BLOCK decision with a receipt covering deterministic policy, DLP leakage and loop prevention.Verify receipts (
vizier_verify_receipt): validate a receipt token's structure, expiration and request/action hash binding, optionally against an expected target and action type.Policy/guardrail checks (
vizier_check_policy): screen content (text, parameters or entity names) underdlp,sanctions,circuit_breakerorgeneral.Safe by design: all tools are read-only, idempotent and non-destructive — nothing is executed and no infrastructure is changed.
Limits: a local ALLOW is not principal-signed delegation and the receipt helper does not verify a JWS signature; for enforceable signed-grant authorization use the hosted tool/
/v1/verifywith the maintained SDK or MCP proxy.
Provides VizierCrewAIToolGuard, which wraps CrewAI tools so each agent action (e.g. payments) is authorized by Vizier against amount limits and policy constraints before execution.
Provides a LangChain tool guard (VizierLangChainToolGuard) that wraps existing LangChain tools so each invocation is submitted to Vizier for a deterministic ALLOW/BLOCK/REVIEW decision before the tool executes, with configurable allowed actions and amount limits.
The same tool guard integrates with LangGraph agent graphs, enforcing Vizier authorization decisions on every tool call so graph-driven agents cannot execute protected side effects without approval.
Provides a TelegramHITLHandler that sends interactive approval buttons to a Telegram bot when a Vizier decision is REVIEW, letting a human operator approve or deny an agent action before it runs.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@Vizierscreen this action: purchase $500 from supplier.example.com"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Vizier
Scoped authorization for AI agents before they act.
Vizier checks a proposed agent action against permissions signed by its owner. It returns ALLOW, BLOCK, or REVIEW, together with policy results and a receipt bound to the request. Your integration invokes the protected tool only after validating the authorization.
Use it at the action boundary of an agent or recurring workflow: before a deployment, repository write, database change, message, or payment API call. A continuously running agent can receive short-lived permissions for specific actions and targets while the owner keeps control of the signing key.
Playground · Live API reference · OpenAPI · Delegation setup · Threat model
Choose an integration
Your task | Start here | Prerequisites |
Try the deployment adapter locally | Node 24+; no keys for the preparation step | |
Verify an action with signed delegation | An operator API key, registered public key and owner-issued grant | |
Protect existing MCP tools | Operator-owned upstream credentials and a restricted tool route | |
Inspect the hosted API | Public documentation; execution permissions are separate |
Related MCP server: MandateGuard
Control an agent's infrastructure deployment
For platform and security teams operating a DevOps agent: pin one existing Cloudflare Worker and require owner-signed scope plus human approval of the exact uploaded version before changing its traffic. Changed versions, out-of-scope targets, expired permissions and repeated approval claims stop before execution. Keep cloud credentials and the executor outside the agent's control.
Install the v0.5.14 SDK and deployment adapter from npm (Node 24+):
npm install @agenda-intelligence/vizier-sdk@0.5.14 @agenda-intelligence/vizier-gated-deploy@0.5.14
npx --no-install vizier-worker-deploy prepare \
--scope node_modules/@agenda-intelligence/vizier-gated-deploy/examples/scope.json \
--plan node_modules/@agenda-intelligence/vizier-gated-deploy/examples/plan.jsonPreparation is local, uses synthetic IDs and needs no keys. Follow the integration and recovery guide before submitting a real review or executing anything. The live sandbox trace shows eight scenarios against production Vizier and a disposable Cloudflare Worker, including a real API response mismatch fixed in v0.5.10. This adapter is installed in the operator's executor; the hosted MCP endpoint exposes verification, not cloud deployment. The automated offline suite simulates Cloudflare; the linked maintainer sandbox trace used the real API and is not external adoption.
Request a scoped integration · What an assisted pilot includes
The paid offer is an assisted integration for one agreed workflow. Hosted subscription and ongoing support are follow-up options to scope with the buyer; there is no automated checkout or self-service paid plan. Code remains MIT. No external customer adoption or IoT malware protection is claimed.
How it works
flowchart LR
Owner[Owner-controlled signer] -->|Scoped, expiring grant| Guard[Tool guard or MCP proxy]
Agent[Agent proposes action] --> Guard
Guard -->|Action + grant| Vizier[Vizier policy service]
Vizier -->|Decision + receipt| Guard
Guard -->|Validated ALLOW| Tool[Protected tool]
Guard -->|Submit REVIEW explicitly| Human[Human review workflow]The owner signs an ES256 delegation: principal, agent, permitted actions, constraints, and expiry. The operator registers only the public key in Vizier.
The integration submits the intended action and grant to
/v1/verify.Vizier verifies the signature, identities, expiry and exact authority binding, then evaluates deterministic policies. No LLM runs in this decision path.
The guard validates the response and request binding before invoking the tool. BLOCK, REVIEW, invalid responses and unavailable authorization stop that path.
An API key authenticates the caller. A delegation grant proves the owner's permission. They have separate roles. A request cannot enlarge the authority inside a valid grant; invalid grants are blocked.
The hosted deployment uses VIZIER_SIGNED_GRANT_MODE=required as of
30 September 2026. Unsigned verification requests return
BLOCK / GRANT_REQUIRED. A hosted ALLOW requires an operator-registered
principal key, a valid matching grant, and passing policies. Check /docs for
current deployment settings. Self-hosted optional mode permits caller-asserted
authority; its receipts do not establish owner delegation.
Working integrations
The Agenda fleet uses Vizier in an owner-operated deployment workflow. This is concrete operational use by the same maintainer; it is not external customer adoption.
Workflow | Protected action | Inspect the evidence |
Agenda Worker fleet | Target-scoped |
The workflow separates signer and execution steps and supplies short-lived, owner-signed grants. Missing or expired grants and invalid required receipts stop that deployment path. An operator who retains direct Cloudflare access still has separate platform authority; Vizier does not remove it.
Start with signed delegation
Experimental. The runnable examples pin published npm clients at v0.5.14.
Service and client versions are tracked separately. TypeScript packages use the owned @agenda-intelligence
npm organization: SDK,
MCP proxy, and
deployment adapter.
Earlier GitHub archives retain their original @vizier/* names; update imports
when switching from those archives to npm.
npm install @agenda-intelligence/vizier-sdk@0.5.14First register a principal public key and mint a grant
from an owner-controlled signer. This example requires a grant for
platform-owner → release-agent, with exactly this authority:
{
"allowed_actions": ["deploy_worker"],
"constraints": {
"allowed_targets": ["worker:example-worker"],
"allowed_sensitive_actions": ["deploy_worker"]
}
}Keep the private signing key outside the action-taking agent. Supply the integration API key and a current grant file to the trusted guard:
import { readFile } from "node:fs/promises";
import { Vizier } from "@agenda-intelligence/vizier-sdk";
const client = new Vizier({
baseUrl: "https://vizier.agendamcp.dpdns.org",
apiKey: process.env.VIZIER_API_KEY,
});
const grantPath = process.env.VIZIER_GRANT_FILE;
if (!grantPath) throw new Error("An owner-issued grant file is required.");
const grant = (await readFile(grantPath, "utf8")).trim();
const result = await client.verify({
agent: { id: "release-agent", owner: "platform-owner" },
principal: { id: "platform-owner" },
action: {
type: "deploy_worker",
target: "worker:example-worker",
parameters: { commit: "reviewed-commit" },
},
authority: {
allowed_actions: ["deploy_worker"],
constraints: {
allowed_targets: ["worker:example-worker"],
allowed_sensitive_actions: ["deploy_worker"],
},
},
context: { request_id: null, timestamp: null, source: "rest" },
grant,
});
// The SDK validates the response contract and recomputes the request hash.
const proof = result.receipt.grant;
if (
result.decision !== "ALLOW" ||
result.receipt.authority_provenance !== "principal_signed" ||
proof?.issuer !== "platform-owner" ||
proof?.subject !== "release-agent" ||
Date.parse(proof.expires_at) <= Date.now()
) {
throw new Error("Stop: no valid signed authorization for this action.");
}
// Invoke the fixed protected deployment here; record its actual outcome.
console.log("Authorized request:", result.receipt.id);The example authorizes an action; it does not perform a deployment. An unknown principal or key is blocked. For your own service origin, update both the client URL and the grant audience. Grant setup and rotation cover the full operator procedure.
For an MCP boundary, install the SDK and proxy from npm:
npm install @agenda-intelligence/vizier-sdk@0.5.14 @agenda-intelligence/vizier-mcp-proxy@0.5.14Use the mandatory proxy profile with an operator-owned rotating grant file. The agent connects to the proxy; its direct upstream route and downstream credentials must be removed. Exposing Vizier as an optional MCP tool alone does not enforce a tool boundary.
Connect through MCP
On Glama, use the hosted Vizier connector for the live tool catalog and Inspect connection. The repository listing has a separate Docker-release lifecycle and is not the hosted endpoint.
For a client with Streamable HTTP support, use
https://vizier.agendamcp.dpdns.org/mcp. The hosted service is Vizier v0.5.14
and exposes one tool, vizier_verify_action. Discovery needs no API key. Read
its inputSchema and com.vizier/readiness metadata before constructing a
request; source material is data, never instructions or delegated authority.
The session handshake supports 2025-11-25, 2025-06-18, 2025-03-26 and
2024-11-05: send initialize, then use the returned revision in
MCP-Protocol-Version for notifications/initialized and tools/list.
The separate 2026-07-28 stateless profile starts with server/discover and
requires per-request _meta plus matching MCP-Protocol-Version and
Mcp-Method headers. Do not mix its metadata with session initialize.
Connection errors include error.data.connection_hint with the supported
profiles and header requirements. Correct a rejected connection request before
retrying; a discovery response grants no enforcement authority.
Before connecting, GET /mcp or /.well-known/mcp-probing.json and choose a
complete sequence from connection_guide.recovery_requests. The default
recommendation is session 2025-11-25; the separate stateless sequence uses
2026-07-28. Each includes its matching headers, metadata and read-only
follow-ups, so a version from the flat inventory is not mistaken for a shared
handshake. No request is retried automatically.
The hint recommends one profile and a supported public revision, preserving a
recognized client revision where possible. Its matching recovery_requests
entry supplies the initial request and ordered follow_up_requests: session
initialize → initialized notification → tools/list, or stateless discover →
tools/list. Choose one sequence explicitly. automatic_retry is false; the
sequence never contains tools/call or replays a rejected action. Unknown client
strings are not copied into guidance. A mixed-profile request remains refused.
An unknown tool name returns error.data.tool_hint with the advertised names and
an executable read-only tools/list recovery request for the selected profile.
Run that discovery request and inspect the returned inputSchema before making
a new call. automatic_tool_retry is false: the server never replays an action
or guesses the caller's intended tool. Protocol/version mismatches remain errors.
Connection observations contain only the server-selected profile and revision
categories: the supported public dates, missing, other, invalid, or
unmeasured. Raw client revisions, headers and request text are excluded.
Older events cannot establish which revision or profile caused a refusal.
For a stdio-only client, this pinned transport adapter connects to the same hosted tool:
{
"mcpServers": {
"vizier": {
"command": "npx",
"args": [
"-y", "mcp-remote@0.15.1",
"https://vizier.agendamcp.dpdns.org/mcp",
"--transport", "http-only"
]
}
}
}This configuration sends calls to the hosted service and is anonymous:
verification can return BLOCK or REVIEW, never ALLOW. It executes no
protected action. For enforcement, the trusted integration supplies its existing
credential and a valid owner-issued grant matching the actual request; see
delegation setup. Keep private signing keys outside
the agent and do not paste credentials into tool arguments.
The separately versioned Python vizier-guard v0.3.3 stdio helper exposes
vizier_screen_action, vizier_verify_receipt and vizier_check_policy. That
local catalog is not the hosted authorization service: its local ALLOW is not
principal-signed delegation, and its receipt helper does not verify a JWS
signature. Use the hosted tool and the maintained enforcing SDK/proxy for the
signed-grant workflow above. The root npm workspace is private: npm install vizier is not an installation command for this project. TypeScript packages
are published under @agenda-intelligence/vizier-* as linked above.
Python SDK 0.3.3 fixes stdio session-version negotiation. Install its tested wheel from GitHub Release v0.5.13:
python -m pip install https://github.com/vassiliylakhonin/vizier/releases/download/v0.5.13/vizier_guard-0.3.3-py3-none-any.whlThe wheel is a GitHub Release distribution; this does not claim a PyPI publication.
Interfaces and capabilities
For a bounded infrastructure pilot, see Worker version deployment. The installable adapter pins one existing Worker and requires owner-signed scope plus human approval of the exact version before calling Cloudflare. The offline demo uses real authorization/review handlers and a simulated Cloudflare response; it creates no infrastructure and is not evidence of external adoption.
Surface | Role |
REST | Action checks with deterministic policies, delegation provenance and request-bound receipts |
TypeScript SDK | Validates response contracts and bindings; includes explicit human-review helpers |
Standard-library client, function guards and framework adapters | |
MCP service | Discover and call verification tools; manifest |
MCP enforcement proxy | Intercepts configured tool calls, validates authorization, and forwards permitted calls |
A2A | Verification adapter and agent card |
Human review queue | Separate reviewer credential, signed approval tokens and atomic server claims |
Policies cover permitted actions, targets, amount constraints, sensitive operations and configured review requirements. SDK/proxy circuit breakers can limit repeated tool calls and session budgets. Additional review workflows and financial reservations have their own contracts and deployment requirements; see the live reference and financial reservation limitations.
Receipts and trust boundary
A /v1/verify receipt records the request hash, decision, rule results and
authority provenance. The legacy verification receipt itself is unsigned;
the grant behind a principal_signed decision is owner-signed. The SDK checks
response consistency and recomputes the request hash over canonical JSON.
A receipt records authorization, not proof that a tool executed successfully.
Legacy Action Covenant and human-review tokens use separate signed receipt formats. Required-grant mode blocks legacy covenant authorization because that entrypoint does not carry a delegation grant. See the covenant contract and the threat model before using compatibility surfaces.
Vizier is an application-level authorization service. The integration enforces its decision. An agent or administrator with direct tool credentials can bypass that integration. Short-lived grants are not single-use execution reservations. Supplied evidence is not independently verified, and authorization does not establish factual truth, legal clearance, payment settlement, or customer demand.
Development
Node.js 24+ is required for the Worker and TypeScript packages.
npm ci
npm run checkcheck runs package builds, type checks, migration checks, lint, tests and a
Worker deployment dry run. It does not publish or deploy. Networked checks are
separate: npm run check:deployed checks the production bundle digest;
npm run check:live checks deployed service and discovery contracts.
Architecture · Claims · Security review · Pilot scope · Issues and integration feedback
Available Tools
3 toolsvizier_check_policyARead-onlyIdempotent
Check content or parameters against security guardrails (DLP credential/PII leaks, sanctions screening, or circuit breaker loop limits).
| Name | Required | Description | Default |
|---|---|---|---|
| content | Yes | Text string, parameters object, or entity name to screen. | |
| category | Yes | The policy check category. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description adds the substantive point that this is a policy/screening operation with distinct check families. However, it never says what a violation produces — a block, a flag, an error — or whether the check is advisory or enforcing, which is the behavior an agent most needs here.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence, front-loaded with the verb and resource, with the category detail folded into a compact parenthetical. Zero filler and nothing to trim.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With only two fully-described parameters and no output schema, the description is close to sufficient, but for a gate-keeping tool the return semantics (pass/fail shape, what a hit looks like, whether the caller should abort) are the critical missing piece and there is no output schema to carry them. The `general` enum value is also left unexplained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description earns above baseline by glossing the otherwise opaque enum values: 'dlp' means credential/PII leaks, 'sanctions' means sanctions screening, 'circuit_breaker' means loop limits. That mapping is genuinely more informative than the schema's bare 'The policy check category.' It still does not explain the accepted shapes of `content` beyond what the schema says.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb ('Check') plus a clearly bounded resource ('content or parameters against security guardrails') and a parenthetical enumerating the three guardrail families. An agent immediately knows this is a screening/validation call. It stops short of naming how it differs from vizier_screen_action or vizier_verify_receipt, which is the only thing separating it from a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The guardrail categories imply when the tool applies (DLP before emitting secrets/PII, sanctions before transacting, circuit breaker before looping), but there is no explicit when-to-use instruction and no exclusion telling the agent to prefer a sibling. Usage is inferable rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
vizier_screen_actionARead-onlyIdempotent
Screen and authorize a proposed AI agent action before execution. Evaluates deterministic policy constraints, DLP leakage, loop prevention, and returns an ALLOW / REVIEW / BLOCK decision with an auditable cryptographic receipt.
| Name | Required | Description | Default |
|---|---|---|---|
| target | Yes | Exact target resource URI or identifier (e.g. 'mcp://github/create_issue', 'stripe://charges', 'bash://rm', 'https://api.example.com'). | |
| agent_id | No | Identifier of the agent requesting action. | claude |
| parameters | No | Arguments or payload of the proposed action. | |
| action_type | Yes | Category of action: 'tool_call', 'shell_command', 'payment', 'database_write', 'external_api', 'file_modification', or 'mcp_proxy'. | |
| principal_id | No | Identifier of the human operator or principal. | operator |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, and the description is consistent with that safety profile. The description adds meaningful behavioral context beyond annotations: deterministic policy checks, DLP leakage checks, loop prevention, and an ALLOW / REVIEW / BLOCK decision with a cryptographic receipt. It could say more about enforcement or authorization requirements, but this is strong.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences and front-loads the core action before the behavioral details. Every clause contributes useful information with no padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description helpfully explains the return categories and the receipt. It is complete enough to invoke the tool correctly, but it does not clarify operational details such as whether it enforces the decision or how it relates to the sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all five parameters are already documented in the input schema, including target examples and the action_type categories. The description adds no parameter-specific semantics beyond what the schema provides, so the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a specific verb and resource: screen and authorize a proposed AI agent action before execution. It also names the evaluation dimensions and decision outputs, so the tool's function is clear. It does not explicitly differentiate itself from siblings vizier_check_policy or vizier_verify_receipt, so it falls short of 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'before execution' clearly establishes when to use the tool. However, it does not name when not to use it or point to the sibling tools as alternatives, so it lacks the explicit routing that would earn a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
vizier_verify_receiptBRead-onlyIdempotent
Verify a cryptographic receipt or audit proof issued by Vizier. Validates token structure, expiration, and exact request/action hash binding.
| Name | Required | Description | Default |
|---|---|---|---|
| receipt | Yes | The receipt token string (JWS compact or receipt JSON) issued by Vizier. | |
| expected_target | No | Optional expected target URI to verify against the receipt. | |
| expected_action_type | No | Optional expected action type to verify against the receipt. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds useful detail about what the verification checks (token structure, expiration, hash binding), but says nothing about the result of a failed verification or whether failures raise or return a value, and there is no output schema to fill that gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences, zero filler, with the core action and the specific validation checks front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only verification tool with fully documented parameters and annotations covering the safety profile, this is nearly complete. The only meaningful omission is failure/return semantics, which is not inferable from an absent output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all three parameters are documented in the schema itself, establishing a baseline of 3. The phrase 'exact request/action hash binding' loosely ties to expected_target and expected_action_type, but adds no syntax or matching-precision detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Verify') and resource ('cryptographic receipt or audit proof issued by Vizier'), then enumerates what is validated (structure, expiration, hash binding). This clearly separates it from vizier_screen_action and vizier_check_policy, though the description never names those siblings or contrasts the roles.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use, when-NOT-to-use, or prerequisite guidance is given. Nothing tells an agent whether this is the step after screening/checking, or under what conditions a receipt should be verified rather than merely inspected.
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 updates
v0.3.3- First observed
vizier_check_policy - First observed
vizier_screen_action - First observed
vizier_verify_receipt
TDQS
Scored across 3 tools
verify_receipt is clearly distinct, but screen_action and check_policy overlap substantially: screen_action already evaluates DLP leakage, policy constraints, and loop prevention, while check_policy checks content/parameters against DLP, sanctions, and loop limits. The descriptions hint that one is a pre-execution authorization gate and the other a narrower guardrail check, but an agent could reasonably select either for the same content-screening need.
All three tools use the same vizier_ prefix followed by a clear verb_noun pattern: screen_action, verify_receipt, check_policy. The convention is predictable and readable throughout.
Three tools is reasonable for a focused runtime security/authorization layer, and each appears to serve a role. It sits at the low end of the typical 3-15 range, with little room for policy management or introspection.
The surface covers the core lifecycle: screen an action, check guardrails, and verify an issued receipt. Minor gaps exist around policy configuration/listing or retrieval of prior receipts, but the essential authorization and audit workflows are present.
Maintenance
Related MCP Connectors
MCP enforcement layer that intercepts AI agent actions and blocks rule violations before execution.
Pre-execution governance for AI agents. Deterministic PASS/FAIL/REVIEW verdicts, replayable proof.
Pre-execution policy gate for consequential agent actions with durable trust receipts.
Check, limit, record and prove AI agent actions with 2-of-3 validators and onchain proofs.
Related MCP Servers
- FlicenseNot gradedqualityCmaintenanceProvides a secure MCP boundary for AI agents, intercepting and validating tool calls, redacting secrets, and requiring human approval for sensitive actions with a tamper-evident audit trail.-
- AlicenseNot gradedqualityAmaintenanceDeterministic, auditable payment policy enforcement for AI agents. It provides pre-action authorization with scopes, budgets, allowlists, and signed mandates via an MCP server.MIT
- AlicenseNot gradedqualityBmaintenanceEnables MCP-compatible AI agents to safely act on business backends by enforcing per-agent permissions, autonomy thresholds, human approval with review-and-edit, and full audit trails.MIT
- AlicenseNot gradedqualityBmaintenanceProvides a governed execution boundary for AI agents, enforcing deterministic policy, one-shot human approvals, and signed receipts for MCP tool effects.MIT