Security

Security

What the MCP Audit Gateway does, what it never does, and how to report a vulnerability. Written for the security team that will read it before signing the contract.

Data residency

The gateway runs entirely inside your environment. The Azure Marketplace edition deploys as a Managed Application into your own subscription. The self-hosted edition runs in your cloud, your Kubernetes cluster, or on-prem.

No customer data is sent to Weldon Web. No telemetry, no phone-home, no mandatory egress to vendor systems. If you firewall off all outbound traffic except to your own MCP servers, the gateway still works.

What gets logged, and where it goes

Every tool call produces one structured audit event with the following fields:

  • · timestamp (UTC, ISO 8601)
  • · identity (resolved from JWT claims)
  • · tool (MCP tool name)
  • · arguments (post-redaction)
  • · decision (allow, deny, rate-limited, with reason)
  • · latency_ms
  • · upstream_status
  • · response (post-redaction, only if response capture is enabled)

Masked-response capture is toggleable per route. Off by default.

The audit sink is configurable. Choose one: Azure Log Analytics, an OpenTelemetry (OTLP) collector, or stdout. The customer chooses; Weldon Web never sees the events.

Sensitive data handling

Built-in detectors run on every request payload (and, optionally, response payload):

  • · PAN (Luhn-validated)
  • · Email address
  • · UK National Insurance Number
  • · US Social Security Number
  • · IPv4 and IPv6 addresses
  • · Phone numbers (E.164 and common UK / US formats)
  • · JWT

Default behaviour is to redact credentials (JWT) only. The remaining detectors are available out of the box but opted in per route, so you do not get surprised by redaction on data you wanted to see unmasked. Custom regex patterns are added in the same config file as the built-ins; matching values are replaced with a fixed token.

Patterns are validated at startup. The gateway will refuse to start with an invalid regex rather than silently disabling it. Config is hot-reloaded; updates apply without dropping in-flight connections.

Authentication

The gateway authenticates inbound requests via OIDC. Any standards-compliant identity provider works: Azure AD / Entra, Okta, Keycloak, Oracle IDCS, and others. Token validation is local; no round-trip to the IdP per request.

JWT claims drive identity resolution. You configure which claim (typically sub, preferred_username, or a custom claim) becomes the identity field on each audit event and the key the policy engine evaluates against.

Supply chain

The gateway is built on .NET 9. The notable runtime dependencies are YARP (reverse proxy) and the OpenTelemetry .NET SDK (instrumentation and OTLP export). Both are mainstream, actively maintained projects.

The container base image is mcr.microsoft.com/dotnet/aspnet:9.0 on Microsoft's servicing schedule.

An SBOM (CycloneDX) is generated on every release and available on request.

Vulnerability disclosure

Report vulnerabilities to security@weldonweb.co.uk. I aim to acknowledge reports within two business days and to confirm remediation timing within five.

No PGP key today. If that is a blocker for your disclosure policy, tell me and I will publish one.

SDLC

Weldon Web is a solo operation. I write the code, review it against an explicit threat model, and run the release. There is no SOC 2 today; do not let me invent one.

The test suite covers the policy engine, the redaction detectors, and the proxy middleware. Container images are scanned in CI on every build (Trivy). Releases are cut from a protected branch with reviewed commits only.

Anything else

If your procurement or security team needs something not covered here (penetration test report, specific compliance attestation, custom DPA terms), ask via the contact form. You will get the engineer, not a queue.