Skip to main content
Glama
Sign In
Vizier

Vizier

by vassiliylakhonin
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Vizier

Scoped authorization for AI agents before they act.

CI Deploy Release License: MIT

Vizier checks a proposed agent action against permissions signed by its owner and returns ALLOW, BLOCK, or REVIEW together with policy results and a receipt bound to the request.

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 · Quickstart · Delegation setup · Threat model

Why this matters

AI agents can act quickly, but not every action should be allowed just because the model or workflow requested it. Vizier adds a deterministic authorization layer between an agent's intent and the protected tool call.

This is useful when you need to enforce:

  • owner-controlled permissions for agent actions

  • short-lived delegated authority

  • exact target scoping and action constraints

  • review-before-execution for sensitive operations

  • auditable receipts for action decisions

Related MCP server: MandateGuard

What this project does

Vizier provides a policy and authorization service for agent actions.

It can validate:

  • whether an action is allowed for a specific agent and principal

  • whether the grant is signed by an owner

  • whether the action matches the grant scope and constraints

  • whether the request should be blocked, allowed, or escalated to human review

It does not decide whether the action is factually correct or ethically acceptable. It decides whether the action is authorized according to the signed authority model and policy rules.

Quick start

1) Install the SDK

Node.js 24+ is required for the TypeScript SDK and deployment adapter.

npm install @agenda-intelligence/vizier-sdk@0.5.16

2) Verify an action with a signed delegation

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,
});

if (result.decision !== "ALLOW") {
  throw new Error(`Authorization failed: ${result.decision}`);
}

console.log("Authorized request:", result.receipt.id);

3) Gate the protected tool call

The service authorizes the action. Your integration still enforces the outcome before calling the protected tool.

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]

  1. The owner signs an ES256 delegation: principal, agent, permitted actions, constraints, and expiry.

  2. The integration submits the intended action and grant to /v1/verify.

  3. Vizier verifies the signature, identities, expiry, and exact authority binding, then applies deterministic policies.

  4. The guard validates the response and request binding before invoking the tool.

Important: an API key authenticates the caller; a delegation grant proves the owner's permission. They are separate roles.

Important boundaries

  • Vizier is an authorization service, not a fact checker.

  • It does not prove that a tool executed successfully.

  • It does not establish factual truth, legal clearance, payment settlement, or customer demand.

  • A receipt records authorization, not a guarantee of a successful side effect.

  • Self-hosted optional mode permits caller-asserted authority; receipts do not establish owner delegation.

Choose your integration

Your task

Start here

Prerequisites

Try the deployment adapter locally

Synthetic preparation example

Node 24+; no keys for the preparation step

Verify an action with signed delegation

SDK setup

An operator API key, registered public key and owner-issued grant

Protect existing MCP tools

Private MCP proxy

Operator-owned upstream credentials and a restricted tool route

Inspect the hosted API

API reference

Public documentation; execution permissions are separate

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.

Install the v0.5.16 SDK and deployment adapter from npm:

npm install @agenda-intelligence/vizier-sdk@0.5.16 @agenda-intelligence/vizier-gated-deploy@0.5.16
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.json

Preparation is local, uses synthetic IDs, and needs no keys. Follow the integration and recovery guide before submitting a real review or executing anything.

Start with signed delegation

Experimental. The runnable examples pin published npm clients at v0.5.16.

npm install @agenda-intelligence/vizier-sdk@0.5.16

First 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.

Connect through MCP

For a client with Streamable HTTP support, use:

https://vizier.agendamcp.dpdns.org/mcp

The hosted service exposes a tool catalog and verification endpoint. Discovery requires no API key. Read the tool schema and metadata before constructing a request.

GET/HEAD discovery is measured as HTTP metadata, separately from MCP RPC requests. A refused connection includes a bounded correction hint and a read-only connection sequence. Correct the request and explicitly start the selected profile; the hint does not authorize an action or trigger automatic retries.

For a copyable Node 24 connection with no dependencies, run one explicit read-only profile from this checkout:

node examples/mcp-connect.ts --profile session
node examples/mcp-connect.ts --profile stateless

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.

Interfaces and capabilities

Surface

Role

REST /v1/verify

Action checks with deterministic policies, delegation provenance and request-bound receipts

TypeScript SDK

Validates response contracts and bindings; includes explicit human-review helpers

Python SDK

Standard-library client, function guards and framework adapters

MCP service

Discover and call verification tools

MCP enforcement proxy

Intercepts configured tool calls, validates authorization, and forwards permitted calls

A2A

Verification adapter and agent card discovery

Human review queue

Separate reviewer credential, signed approval tokens and atomic server claims

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

Evidence

Agenda Worker fleet

Target-scoped deploy_worker authorization before deployment

Public workflow

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.

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.

Visualization of the trust boundary:

  • the integration enforces the decision

  • the agent or operator with direct tool credentials can bypass that integration

  • short-lived grants are not single-use execution reservations

  • authorization does not replace human judgment or operational controls

Development

Node.js 24+ is required for the Worker and TypeScript packages.

npm ci
npm run check

check runs package builds, type checks, migration checks, lint, tests, and a Worker deployment dry run. It does not publish or deploy.

Useful references:

License

MIT License.

Available Tools

3 tools
vizier_check_policyA
Read-onlyIdempotent

Check content or parameters against security guardrails (DLP credential/PII leaks, sanctions screening, or circuit breaker loop limits).

NameRequiredDescriptionDefault
contentYesText string, parameters object, or entity name to screen.
categoryYesThe policy check category.

TDQS

A3.6/5.0
Behavior3/5

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.

Conciseness5/5

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.

Completeness3/5

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.

Parameters4/5

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.

Purpose4/5

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.

Usage Guidelines3/5

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_actionA
Read-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.

NameRequiredDescriptionDefault
targetYesExact target resource URI or identifier (e.g. 'mcp://github/create_issue', 'stripe://charges', 'bash://rm', 'https://api.example.com').
agent_idNoIdentifier of the agent requesting action.claude
parametersNoArguments or payload of the proposed action.
action_typeYesCategory of action: 'tool_call', 'shell_command', 'payment', 'database_write', 'external_api', 'file_modification', or 'mcp_proxy'.
principal_idNoIdentifier of the human operator or principal.operator

TDQS

A4/5.0
Behavior4/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines4/5

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_receiptB
Read-onlyIdempotent

Verify a cryptographic receipt or audit proof issued by Vizier. Validates token structure, expiration, and exact request/action hash binding.

NameRequiredDescriptionDefault
receiptYesThe receipt token string (JWS compact or receipt JSON) issued by Vizier.
expected_targetNoOptional expected target URI to verify against the receipt.
expected_action_typeNoOptional expected action type to verify against the receipt.

TDQS

B3.4/5.0
Behavior3/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines2/5

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.

  1. 3 tool updatesv0.3.3
    • First observedvizier_check_policy
    • First observedvizier_screen_action
    • First observedvizier_verify_receipt
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.7/5.0

Scored across 3 tools

Disambiguation3/5

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.

Naming Consistency5/5

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.

Tool Count4/5

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.

Completeness4/5

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

ActivityActive
ResponsivenessNo recent community issues

Resources

Related MCP Connectors

Related MCP Servers

  • AgentGuard MCP Server

    vaasu202
    F
    license
    Not graded
    quality
    C
    maintenance
    Provides 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.
    -

  • varco_mcp

    williamselmo1993
    A
    license
    Not graded
    quality
    B
    maintenance
    Enables 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

  • veor

    winterbim
    A
    license
    Not graded
    quality
    B
    maintenance
    Provides a governed execution boundary for AI agents, enforcing deterministic policy, one-shot human approvals, and signed receipts for MCP tool effects.
    MIT