Stacklok Security Center

Self-hosted AI governance, built to keep customers in control

Stacklok is deployed inside your infrastructure, in your Kubernetes environment. That means your AI traffic, prompts, tool calls, policies, logs, and governance data remain under your control.

Stacklok does not host, process, transmit, or store customer data by design. We do not have access to your environment, network, workloads, or data.

All data location, residency, encryption, retention, deletion, and access controls are governed by your own infrastructure and security policies. Nothing on Stacklok’s end affects your current security posture or governance controls. 

Our responsibility is to provide software that is safe to deploy, built with strong software supply chain practices, and designed for secure operation in customer-controlled environments.

Shared responsibility

Security in a self-hosted model is a shared responsibility.

Customers control the environment.
This includes data hosting, encryption, access control, retention, uptime, incident response, and compliance of the running system.

Stacklok controls the software we deliver.
This includes secure development practices, software supply chain integrity, vulnerability response, signed artifacts, SBOM availability, and build provenance.

Stacklok security posture

Stacklok focuses on the security of the software we provide, including:

Support for customer-controlled deployment and operations

• Signed software artifacts
• SBOM availability
• Provenance and build integrity
• Vulnerability and CVE response
• Secure development practices
• Limited vendor access by design

Subprocessors

Stacklok uses a variety of tools and technology internally that may subprocess data. These tools consist of cloud technologies like AWS and Slack. Below are all applications in which information may be subprocessed.

Why this matters

With Stacklok, enterprises can govern AI and MCP usage without giving up control of sensitive data or infrastructure.

You get the benefits of AI governance while keeping your security model aligned to your own environment, policies, and compliance requirements.

Vulnerability Management

Reporting a Vulnerability

If you believe you’ve found a security vulnerability in a Stacklok product, please report it privately through either of these channels:

• GitHub Security Advisories on the affected repository
• Email: security@stacklok.com (PGP key available on request)

We follow a coordinated disclosure process. We’ll work with you to confirm the issue, develop a fix, and agree on an embargo timeline before any public disclosure.

Vulnerability Detection

We use several complementary techniques to find vulnerabilities before and after release:

• Static analysis (SAST): Security linters run on every pull request.
• Software composition analysis (SCA): Every pull request is checked for known vulnerabilities in dependencies. Builds fail when a fixable vulnerability is found.
• Dynamic testing (DAST): Automated scans run daily and on every change to the main branch, covering our APIs, web console, and MCP proxy layer.
• Container image scanning: Every image is scanned at build time and re-scanned daily so newly disclosed vulnerabilities are caught after release.
• AI-assisted vulnerability analysis: We also scan our code with the latest AI cyber model to surface issues that rule-based tools tend to miss, such as logic flaws and context-dependent weaknesses. The scan runs in an isolated sandbox, so our code never leaves our environment. Findings are triaged by our team and handled under the same remediation timelines as all other vulnerabilities.

Severity is assigned by Stacklok during triage, based on CVSS score and whether the vulnerability is exploitable in Stacklok Enterprise. Timelines run from confirmation of the vulnerability to availability of a fixed release. Actively exploited vulnerabilities are fixed as soon as possible, regardless of severity. Vulnerabilities that don’t affect the product, for example because the vulnerable code isn’t reachable, are documented in our VEX statements rather than patched.

Security Advisories and Customer Notification

Notifications go to each Enterprise customer’s named security contact. Critical and High notifications may arrive before a fix is available, so they include the affected versions, severity, planned fix date, and any mitigations you can apply in the meantime. Enterprise customers are notified and receive fixes ahead of public disclosure.

Exploitability Transparency (VEX)

Every release includes an OpenVEX document stating whether reported CVEs in our components actually affect the product, so your team can focus on the vulnerabilities that matter.

Need more detail?

For security reviews, architecture discussions, or vendor questionnaires, contact the Stacklok team at enterprise@stacklok.com. Our technical team can help clarify which controls are owned by Stacklok and which are governed by your deployment environment.