Sovara Gateway

Evidence and control for agent-to-MCP tool calls. In your environment, not ours.

Governance for AI agents - listed on Azure Marketplace as MCP Audit Gateway.

Start a team pilot Get it on Azure Marketplace

Sovara Gateway sits between your AI agents and the MCP servers they call. Each routed call requires a valid bearer JWT; configured tools/call requests are evaluated against policy and recorded as structured audit events with masked arguments. Optional inline DLP can mask configured values in JSON responses before they return to the agent. The gateway runs inside your environment - prompts and responses do not leave it for these checks.

The control gap

MCP servers do not automatically give security teams consistent identity policy, argument controls and audit evidence.

As teams add MCP servers, each route can bring its own authentication model, data exposure and evidence requirements. A consistent gateway boundary lets security teams define what must be true before an agent tool call is forwarded.

That slows everything down. The AI use cases are there, but adoption stalls because the controls aren't.

Evidencing

When operational-resilience reviewers or internal audit ask which agent called which tool, the answer needs structured evidence: resolved identity, tool, masked arguments, decision, status and latency.

Leakage

PANs, NINs, JWTs, and customer references can flow through tool arguments and responses. Without argument policy, masked evidence and response DLP, sensitive content can land in audit sinks or return to agent context.

Drift

Without an enforcement boundary, agent access may lack identity allow-lists, rate limits, approvals or time windows. Gateway policy makes those controls explicit per configured route and tool.

What it does

Structured audit trail

Each intercepted tools/call request is logged with resolved agent identity, masked arguments, decision, latency, and upstream response status. Stream events to Azure Log Analytics, an OTLP collector, or stdout. Masked-response capture is configurable; batch response bodies are not captured in v1.

Policy enforcement

Per-identity allow-lists, per-tool argument-pattern regex, sliding-window rate limits, and time-windowed access. Policies hot-reload from a mounted config file. Enforced denials are evaluated before the request reaches the upstream MCP server.

Masked evidence and response DLP

Twelve built-in detectors cover PAN (Luhn-validated), email, UK NIN, US SSN, IP addresses, phone numbers, JWTs, AWS and GitHub credentials, Slack tokens and private keys. They mask audit copies when enabled; optional inline DLP also masks live JSON responses. Configure raw argument patterns separately to deny sensitive requests.

Rate limiting

Per-identity sliding-window limits, configurable per tool. Useful both for runaway agents and for compromised credentials. Decisions are logged so you can see who was throttled and when.

Deployment

Azure Marketplace edition

Deploys as an Azure Managed Application into your own subscription. Audit events write to Log Analytics in your tenant, and procurement runs through the Azure Marketplace listing.

Right fit when your buying process runs through Azure and you want a single Marketplace invoice.

Self-hosted Docker edition

Same product, no Azure dependencies. Runs on AWS, GCP, on-prem, any Kubernetes cluster. Audit events go to your chosen OTLP collector or stdout. Annual licence direct from Weldon Web.

Right fit when your estate is multi-cloud, on-prem, or otherwise not Azure-first.

Compliance frame

The gateway produces evidence that supports the following regulatory frames. It does not certify your organisation; you use the evidence in your own compliance posture.

PCI DSS 4.x context

Luhn-validated PAN detection and masking in audit evidence. Confirm the applicable PCI requirements and system scope with your assessor.

UK GDPR / Data Protection Act 2018

Configurable identity policy, data minimisation in audit evidence and customer-controlled deployment. These controls support, but do not establish, compliance.

FCA / PRA operational resilience

Auditable AI agent action trail for important business services.

Internal audit and model risk

Resolved identity, tool, decision reason, masked arguments, latency and upstream status for intercepted calls.

How it works

The gateway is a reverse proxy in front of one or more MCP servers. A configured tools/call request flows through these stages:

1.Identity. The caller's JWT is validated against the configured OIDC authority, issuer and audience. Identity resolves in the fixed order upn, appid, oid, then sub.
2.Policy. Route and tool identity rules, scopes, roles, raw argument patterns, rate limits and time windows are evaluated. Enforce mode blocks denials; Audit mode records would-block and forwards.
3.Evidence masking. Built-in and custom detectors mask the audit copy of arguments. Response capture masks its audit copy too; optional inline DLP can mask the live JSON response returned to the agent.
4.Proxy. Forwarded requests go to the target MCP server via YARP. SSE GETs pass through without buffering or policy evaluation.
5.Audit. A structured event (identity, tool, masked args, decision, latency, upstream status) is written to the configured sink: Log Analytics, OTLP, or stdout.

     ┌────────────────────────┐
     │  Audit sink            │
     │  Log Analytics / OTLP  │
     │  / stdout              │
     └───────────▲────────────┘
                 │ structured events
                 │
┌──────────┐   ┌─┴───────────────────┐   ┌──────────────┐
│ AI agent │──▶│   Sovara Gateway    │──▶│  MCP server  │
│  Claude  │   │                     │   │  (your tool) │
│  ChatGPT │   │   identity          │   └──────────────┘
│  custom  │   │   policy engine     │
└──────────┘   │   redaction         │
               │   YARP proxy        │
               └─────────────────────┘

What the data looks like

Each intercepted tools/callrequest produces a structured audit event. Your team builds dashboards against those events in whatever observability stack you already run. The example below is Grafana, drawing on the gateway's emitted metrics: total invocations, deny rate, deny reasons by identity and pattern, p50 and p95 tool-call latency, top denied tools.

Example Grafana dashboard showing Sovara Gateway metrics: tool calls, deny rate, allow vs deny over time, tool-call latency, top denied tools, and top denial reasons.

Example dashboard, synthetic test workload. The agent identities shown (finance-bot@contoso.com, intern@contoso.com, reporting@contoso.com, support@contoso.com) are illustrative, not real customers. The gateway emits structured events; you build the dashboard in your stack of choice, including Log Analytics, Datadog, Splunk, Grafana, Loki, or any OTLP-compatible backend.

Pricing

Sold direct, annual subscription, priced per entity rather than per call. Standard deployments start at £24,000 per year. Larger and multi-entity deployments are quoted on request. Early reference customers receive a meaningful year-one discount in exchange for case-study rights.

Request a quote

One evidence model. Two enforcement points.

Sovara Gateway governs what your AI agents do when they call MCP tools. Sovara Browser is a separate product that governs what your people send to AI chat. The products use consistent decision semantics and the same audit-event schema, while policies, deployments and audit stores remain separate.

Start a team pilot

I built the gateway and I will be the one answering this form. Tell me the rough shape of your deployment (cloud, scale, regulatory frame) and which MCP tools are in scope. I will come back with a concrete pilot plan.

Want the security details first? See the security page.