SentinelMCP is currently in Alpha (v0.1.x). Only the latest release line receives security fixes.

As the project stabilizes toward a stable v1.0, this table will be updated with a formal support window per release line.

We take security vulnerabilities seriously. Please do not open a public GitHub issue for security vulnerabilities.

Report them privately to security@technosive.co.uk.

To help us reproduce and fix the issue quickly, please include:

• A description of the vulnerability and its impact.
• The affected component (gateway core, orchestration adapter, sidecar proxy, or Inline SDK) and the version you are running.
• Step-by-step reproduction — a minimal config, the exact commands, or a proof-of-concept.
• Any relevant logs, audit output, or stack traces.
• Your assessment of severity, and any suggested remediation.

1. We acknowledge your report within two business days.
2. We investigate and confirm the vulnerability, then coordinate a fix and a disclosure timeline with you.
3. Once a fix is available, we publish a patched release and a security advisory (a GitHub Security Advisory, and a CVE where applicable), crediting you unless you prefer to remain anonymous.

We ask that you give us reasonable time to remediate before any public disclosure. 90 days is our default window, extendable by mutual agreement.

This policy covers the open-source SentinelMCP repository (technosiveuk-ui/SentinelMCP), including the gateway core, the orchestration adapter, the sidecar proxy, and the Inline SDK.

Out of scope:

• Vulnerabilities in third-party dependencies that are already fixed in a released version — please update your dependencies.
• Theoretical attacks without a concrete exploit path in a default configuration.
• Issues in Technosive Ltd.'s commercial Enterprise Control Plane — report those through your enterprise support channel.

• Default-deny on failure. Every failure path in the enforcement pipeline blocks the tool call rather than allowing it through (NFR-07), so a fault cannot silently downgrade protection.
• Sensitive values are never logged. Matched DLP values are marked non-serializable and are excluded from audit and span output.
• Loopback-plaintext-default transport. On loopback the sidecar may run plaintext HTTP with optional auth (the host boundary carries trust). Off loopback, inbound TLS and API-key authentication are required, and the sidecar refuses to start if either is missing. See Transport Security.
• Fail-closed transport on both legs. Outbound calls use TLS by default: strict mode rejects plaintext and IP-literal upstreams at config load, upstream certificates can be CA- or SPKI-pinned (InsecureSkipVerify is never set), and a non-allowlisted egress host or unresolved credential blocks the call. No path falls back to plaintext or anonymous access.
• Secrets at rest must be owner-only. A config.yaml carrying admin_token/api_keys, or a secrets.yaml, is refused at load if it is group- or world-readable (mode must be 0600); environment variables are the recommended path for secrets in shared environments.
• Alpha caveat. SentinelMCP is Alpha software and should not be your sole defense in a highly regulated production environment without thorough testing. See the project README for the current status.