Stage 17 Developer Preview · Live public adoption
Does a live delegation path from this principal to this actor still exist right now?
GATE is the live authority-state resolver for delegated agents across trust domains.
It resolves whether a currently valid authority path still exists at effect time using live authority state from external trust domains. GATE does not mint a proprietary delegation token, replace OAuth, replace your policy engine, or require MCP.
Current operational boundary: one Canadian primary database, no production regional replicas, and no independent third-party issuer propagation SLA.
maxStalenessMsmeasures primary snapshot age only. The Developer Preview is not enterprise GA.
GATE public product website — launch, Free plans, and supported developer paths.
Signed revocation quickstart — actual GATE Network DENY → ALLOW → DENY with a self-controlled ES256 test issuer.
Start with the hosted sandbox — synthetic graph for learning GATE revocation semantics.
Create a real Free GATE Network project — live gate-network with a real API key and managed quota.
Stage 17 has validated real Free onboarding, independent CAEP/SSF revocation interoperability, external problem validation, and Free-to-paid entitlement continuity. GATE remains a Developer Preview: independent adoption and enterprise-scale operation are the next validation targets.
Related MCP server: MCPGate
Identity / credentials / policy / issuer systems
|
| authority state + trust signals
v
+-------------------+
| GATE |
| live authority |
| state resolver |
+-------------------+
|
gate.verify()
|
v
trusted effect boundaryGATE complements identity, credential, policy and gateway systems. MCP is one integration surface, not GATE's definition.
The differentiator is not multi-hop alone. It is the combination of live upstream revocation, alternate-path preservation, federated issuer state, freshness semantics and protocol-neutral effect-time resolution.
Read: docs/POSITIONING.md, docs/INTEGRATION-MODEL.md, docs/RELEASE-BOUNDARY.md.
GATE exposes two separate onboarding paths.
Use the hosted sandbox to learn GATE semantics on a synthetic authority graph:
https://gate-phi-eosin.vercel.app/quickstart.html
Temporary key: 7 days. Quota: 500 verifications/project/day.
Canonical endpoint:
https://ufqtoyakmrddqytrkcje.supabase.co/functions/v1/gate-network
Current Free Developer Preview: 50,000 verifications/month, 1 authority issuer, bounded consistency. Strict consistency is not included.
Use GateClient from @gate-avn/sdk. See docs/QUICKSTART.md for the complete live-network flow.
Requirements: Node.js 20+.
npm install
npm test
npm run demoThe demo calls the public SDK shape:
import { GateClient } from './packages/sdk/dist/index.js';
const gate = new GateClient({ endpoint: process.env.GATE_URL });
const result = await gate.verify({
principal: 'user:jerome',
actor: 'agent:C@company-c',
action: {
protocol: 'mcp',
name: 'delete_customer_data',
resource: 'customer:3456'
},
consistency: 'bounded',
maxStalenessMs: 200
});
if (result.decision !== 'ALLOW') throw new Error(result.reason);GATE answers a deliberately narrow question: whether the actor still has at least one live delegation path from the principal, according to sufficiently fresh external authority state.
The public contract separates authority state from application policy. A credential can remain syntactically valid while GATE returns INVALID or UNKNOWN because the authority behind it is no longer live or cannot be established with the requested freshness.
It can return:
VALID / ALLOW — at least one live authority path exists.
INVALID / DENY — the known paths are revoked/invalid.
UNKNOWN / DENY — freshness or availability is insufficient for the requested consistency contract.
GATE is not your business-policy PDP. The action object is carried for integration/audit context in this preview; policy such as "may this principal delete customer 3456?" belongs in AuthZEN, Cedar, OPA, Permit, Cerbos, OpenFGA, or your existing authorization system.
GATE is also not trying to replace OAuth, MCP, A2A, OpenID Federation, Security Event Tokens, Shared Signals, an IdP, or an API/AI gateway. The intended role is to sit underneath/alongside them as a live authority-state resolver.
The Developer Preview does not claim a portable cryptographically signed authority proof. It returns a live resolution result; a signed GATE receipt is a possible future layer, not a current release promise.
A local verifier can validate signatures, expiry, scopes and token chains. It cannot independently know every external issuer's current revocation state, trust changes, alternate delegation paths, or freshness across domains. GATE's hypothesis is that the defensible value is the shared, low-latency state network — not a secret verification algorithm.
bounded: live verification from the canonical primary on v7, with a bounded primary-read snapshot age; regional replicas are not yet deployed.
strict: canonical primary-read verification available only to eligible plans; not synchronous confirmation of external issuer systems.
packages/sdk/ public developer-facing client
examples/ minimal SDK demonstration
services/ experimental control plane / edge / trust services
src/ PoC verification primitives
mcp/ MCP enforcement harness
test/ SDK + distributed consistency tests
docs/ architecture, integration contract, due diligencenpm install @gate-avn/sdk@devRepository Stage 16 baseline: 0.1.0-dev.4
Published npm @dev: 0.1.0-dev.4 (verified from public npm registry on 2026-10-28)
npm install @gate-avn/mcp@devRepository Stage 16 baseline: 0.1.0-dev.8
Published npm @dev: 0.1.0-dev.8 (verified from public npm registry on 2026-10-28)
Official MCP Registry:
io.github.Projetxana/gate-authority-networkGATE is publicly available as a Developer Preview on npm and in the Official MCP Registry.
The SDK and MCP server are currently installable from the public npm registry. The MCP server is also discoverable through the Official MCP Registry.
The HTTP, x402, AuthZEN, A2A, AP2 and SSF adapters exist in the Stage 16 repository baseline but are not yet published as public npm packages.
This remains experimental Developer Preview software and is not production-ready.
Read next: docs/STAGE17D-EXTERNAL-VALIDATION.md, docs/STAGE17E-FREE-PAID-CONTINUITY.md, docs/DUE-DILIGENCE-2026-10-02.md and docs/PUBLIC-VALIDATION-PLAN.md.
Apache-2.0. This repository is intended to make the verification logic easy to inspect and challenge; the long-term product hypothesis is the shared live authority network, not proprietary verifier code.
Inspect the configured GATE verifier mode and operational status. Use this tool for setup checks and troubleshooting, not to authorize an action. In demo mode, it reports the local simulated authority graph. In network mode, it requests the configured endpoint health information. A healthy response does not prove that an actor has permission to act. Use gate_verify at the trusted effect boundary for authority decisions. If the status request fails, do not assume access is allowed.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile, but the description adds genuinely new behavioral context: the mode-dependent behavior (local simulated authority graph vs. remote endpoint health request) and the semantics of both success and failure. The caveat that a healthy response does not prove permission is a non-obvious interpretive constraint an agent could not infer from annotations.
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?
Purpose and mode behavior are front-loaded, and every sentence carries operational meaning. The only weakness is mild redundancy between 'a healthy response does not prove permission' and 'if the status request fails, do not assume access is allowed' — both are useful, but they are phrased as near-parallel warnings.
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 parameters and no output schema, the description carries the burden of explaining what comes back, and it does so at a high level (mode, simulated authority graph, endpoint health). It stops short of describing the response structure, but for a status probe the interpretive guidance it supplies is the more valuable content.
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?
The tool takes zero parameters, so there is nothing to disambiguate and the baseline applies. The description correctly adds no parameter talk, leaving the no-argument contract intact.
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 opening sentence gives a specific verb ('Inspect') and resource ('configured GATE verifier mode and operational status'), which is unambiguous. It also explicitly separates itself from gate_verify, so an agent can route correctly without opening either schema.
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?
It names the intended contexts (setup checks, troubleshooting) and an explicit exclusion ('not to authorize an action'). It then routes the alternative use case to gate_verify 'at the trusted effect boundary', which is exactly the when/when-not/alternative structure a 5 requires.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify whether an AI agent currently has a valid delegated authority path from a principal for a requested action. Call immediately before a protected operation, using trusted principal, actor and action context. The verifier evaluates current authority evidence, including upstream revocation and alternative delegation paths, subject to the configured consistency and freshness guarantees. Inspect the returned decision: ALLOW, DENY or UNKNOWN authority. UNKNOWN must not permit the protected action. A standalone verification response does not enforce authorization: the trusted execution boundary must enforce the decision. Live network verification requires a configured GATE endpoint and appropriate credentials. Demo mode is simulated and not production authority.
| Name | Required | Description | Default |
|---|---|---|---|
| actor | Yes | Identifier of the agent or actor attempting the operation. | |
| action | No | Action context being verified, including protocol, operation and resource when available. | |
| principal | Yes | Trusted identifier of the principal delegating authority. | |
| consistency | No | Requested consistency level. Free Developer Preview supports bounded only. | |
| maxStalenessMs | No | Maximum acceptable authority snapshot age in milliseconds, subject to the network freshness contract. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well past the annotations: it discloses that the verifier evaluates upstream revocation and alternative delegation paths, that decisions are ALLOW/DENY/UNKNOWN, that UNKNOWN must not permit the action, that a standalone response does not enforce authorization, and that demo mode is simulated. These are exactly the behavioral traits annotations cannot convey.
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?
Front-loaded with purpose and when-to-call, then proceeds to decision semantics, enforcement caveat, and environment caveats in a sensible order. It is dense but nearly every sentence carries operational weight; a small amount of prose could be compressed.
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 carries the burden of explaining the return values and does so fully (ALLOW/DENY/UNKNOWN plus how to treat UNKNOWN). It also covers the enforcement-boundary semantics and the credential/endpoint prerequisites needed to interpret a result, which is complete for a verification primitive.
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 would be 3; however the description adds meaning beyond the schema by tying 'consistency' and 'maxStalenessMs' to 'configured consistency and freshness guarantees' and flagging the bounded-only limitation of the Developer Preview. The remaining gap is that it doesn't address the nested 'action' object's shape.
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 (delegated authority path) with scope: 'whether an AI agent currently has a valid delegated authority path from a principal for a requested action.' This clearly separates it from the only sibling, gate_status, which reads as a status/report tool rather than a point-in-time authority decision.
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?
'Call immediately before a protected operation, using trusted principal, actor and action context' gives a concrete invocation point, and the caveats about live network vs demo mode and the bounded-only consistency constraint help the agent decide when the call is meaningful. It stops short of an explicit when-not-to-use rule or a named alternative beyond the implicit gate_status contrast.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0-dev.9gate_verify5 fields changedInput schema / properties / action / descriptionAdded value: +"Action context being verified, including protocol, operation and resource when available."Input schema / properties / actor / descriptionAdded value: +"Identifier of the agent or actor attempting the operation."Input schema / properties / consistency / descriptionAdded value: +"Requested consistency level. Free Developer Preview supports bounded only."Input schema / properties / maxStalenessMs / descriptionAdded value: +"Maximum acceptable authority snapshot age in milliseconds, subject to the network freshness contract."Input schema / properties / principal / descriptionAdded value: +"Trusted identifier of the principal delegating authority."v0.1.0-dev.8gate_statusgate_verifyScored across 2 tools
gate_verify (authority decision at effect boundary) and gate_status (configuration/health inspection) are explicitly delineated, and both descriptions cross-reference each other to prevent misuse. An agent can unambiguously choose between making an authorization decision and checking setup/health.
Both tools use a uniform snake_case verb/noun pattern with a consistent 'gate_' prefix (gate_verify, gate_status). The convention is predictable and scales if more gate operations are added.
Two tools is thin even for a narrowly scoped verification service; the surface is tightly focused but offers no affordances beyond a single decision call and a status probe. It sits at the borderline of minimal but arguably sufficient.
The core lifecycle — check readiness, then verify authority at the effect boundary — is covered, including the critical UNKNOWN/deny semantics. Minor gaps remain: no way to inspect delegation chains, revocation evidence, or batch/bulk verification results directly.
Zero-secret MCP gateway for AI agents: risk-scored, audited calls with human-in-the-loop approval.
MCP gateway: one connection for your AI apps, with tool policies, PII redaction and audit logs.
Zero-setup MCP gateway securely connecting AI to your tools with authentication and workflows
MCP gateway and cloud hosting for MCP servers, agents and apps like RAG, managed from your agent.