Portfolio
AI Systems

REST GW

Registry-Driven REST and MCP Gateway for Governed AI Execution

June 14, 2026exec · dev · it
REST GW screenshot 1: REST GW Architecture

Outcome

Give AI clients one policy-governed path to approved APIs without exposing endpoint topology or bypassing operational controls

Innovation

One registry and policy pipeline governs both REST invocation and MCP tool execution

Stack

Fastify · MCP JSON-RPC · Workflow Registry · Policy Engine · DMZ Proxy · Redis

Walkthrough

A request becomes an approved workflow

Follow the negotiation from client intent through registry, policy, and invocation.
REST GW negotiation demo showing a client request, a missing semester prompt, workflow candidates, and policy decisions.
Natural-language intake

The AI client states the data need in ordinary language.

Registry resolution

The gateway matches intent to approved, bound workflows.

Targeted negotiation

Only the missing semester input is requested from the client.

Policy evidence

Candidates reveal allowed paths and explain rejected alternatives.

Bounded invocation

The selected workflow proceeds through the governed execution path.

REST GW screenshot 2: REST GW

REST GW is a registry-driven gateway that converts an AI client’s intent into a controlled call to an approved API workflow. It is built for environments where the AI layer must use tools and data services without receiving direct access to network targets, credentials, or internal topology.

The gateway exposes both conventional REST routes and an MCP-compatible JSON-RPC surface. Those are not separate control systems: each path resolves against the same production registry, evaluates the same policy constraints, uses the same endpoint bindings, and records the same audit trail.

The Challenge

  • AI clients should not choose backend IP addresses or paths at runtime
  • Tool availability must reflect approved workflows, not whatever an agent can discover
  • Identity, role, and data scope must travel with every invocation
  • Operators need a replayable record of the workflow, endpoint binding, and outcome

The Gateway Approach

REST GW makes the execution path explicit.

  1. Authenticate the AI client and recover caller context.
  2. Resolve intent to candidate workflows in the production registry.
  3. Evaluate policy and enforce role- and identity-scoped filters.
  4. Bind execution to an install-time-approved endpoint, not a caller-supplied target.
  5. Forward through the DMZ proxy with request signing and sticky-session handling.
  6. Record binding and audit evidence for review and incident analysis.

Technical Architecture

Registry-Driven Control Plane

REST GW: governed REST and MCP execution

Client PlaneAI client service

HTTPS requests carry authenticated identity and intent—not raw downstream targets or credentials.

Gateway RuntimeFastify gateway: AuthN, policy, resolver

Resolves a request against approved workflows, applies role and scope filters, then binds it to a managed endpoint.

Controlled EgressDMZ proxy + approved APIs

Uses signed forwarding and sticky-session resolution to reach only sanctioned downstream API paths.

Registry and Binding Plane
Production registryInstall-time endpoint bindingsRequired-parameter validation
REST and MCP Surfaces
Resolve-request APIWorkflow invoke APIMCP JSON-RPC tools/call
Traceable Operations
Request-to-endpoint bindingRedis / in-memory sticky stateAudit events and reviewable traces
Execution Invariant

The REST and MCP paths share the same registry, policy, endpoint-binding, proxy, and audit pipeline.

  • Registry-driven routing: the production registry describes approved workflows, required parameters, and route policy. Install-time endpoint bindings map those workflows to sanctioned proxy paths.
  • MCP tool surface: MCP tools/call requests use the same workflow registry and policy enforcement as REST, so tool access cannot drift away from API governance.
  • Protected execution path: the gateway signs traffic for the DMZ proxy, resolves sticky sessions through Redis or memory, and never trusts a caller-provided network destination.
  • Reviewable operations: request-to-endpoint bindings and audit events preserve the decision chain from client intent to downstream response.

Core Capabilities

1. Shared Policy Enforcement

Policy is evaluated at request time for every REST route and MCP tool call.

  • AI client authentication through bearer or HMAC credentials
  • Workflow role checks and identity-aware self/teacher/admin scopes
  • Enforced request filters that restrict downstream result sets
  • Required-parameter validation before proxy forwarding

2. Registry and MCP Tool Governance

The production registry is the source of truth for what can be executed. MCP is an access surface over that same control plane, not an alternate path around it.

  • Workflow discovery and resolution from structured client intent
  • MCP JSON-RPC tool calls mapped to approved workflow IDs
  • Endpoint selection from install-time bindings rather than client configuration
  • One consistent policy and audit contract across REST and MCP

3. DMZ Execution and Operational Evidence

The proxy path is designed to keep downstream access controlled and explainable.

  • Signed gateway-to-proxy forwarding with an allowlisted target set
  • Sticky-session handling for compatible downstream systems
  • Request binding records that relate caller intent to its resolved endpoint
  • Append-only audit events for authorization and execution outcomes

Why It Matters

AI systems become easier to scale when their tool layer is stable, observable, and governed.

REST GW makes the registry—not the agent prompt or client configuration—the authority for execution.