> For the complete documentation index, see [llms.txt](https://docs.solcis.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.solcis.ai/legal-centre/vulnerability-disclosure-policy.md). # Vulnerability disclosure policy How to report a security vulnerability in Solcis, and what we will do about it. **Version 1.0 · 10 September 2026** Solcis builds runtime controls for AI agents. Our customers deploy our software into regulated environments and rely on it to make and record enforcement decisions. We treat the security of that software, and of our repositories and services, as a first-order concern. We welcome reports from security researchers, customers and anyone else who finds a weakness in our products. This policy explains how to tell us, what we will do, and what we ask of you in return. ## 1. How to report a vulnerability **Please do not open a public issue, discussion or pull request for a security vulnerability.** Use whichever of these suits you: * **Email** `security@solcis.ai`. For sensitive content, encrypt to our OpenPGP key, published at . Key fingerprint: `9BAA 2A30 A68F 5859 B59C 2491 8F0B C8DC 9158 DA39`. We recommend verifying that fingerprint through a second channel before sending anything sensitive. * **GitHub private vulnerability reporting**, from the Security tab of the relevant repository. This is the fastest route if you already have the repository open. Our machine-readable contact details are published at in accordance with RFC 9116. We accept reports in English. ## 2. What to include A report we can reproduce is a report we can fix quickly. Where you can, please tell us: * What the vulnerability is, and what an attacker could achieve with it. * Steps to reproduce it, with a proof of concept if you have one. * The affected component, the licensing tier it sits in (`oss`, `source-available` or `proprietary`), and the version or commit you tested. * The deployment shape you tested against — Docker Compose, Kubernetes, air-gapped, or an SDK integration. * Any suggested remediation, and whether you intend to publish. If you are unsure whether what you have found is a vulnerability, send it anyway. We would rather triage a non-issue than miss a real one. ## 3. What we will do * **Acknowledge your report within 3 business days.** * **Provide an initial assessment and our expected remediation timeline within 10 business days.** Where an initial assessment takes longer, we will tell you why and when to expect one. * Keep you informed as we work, and tell you when a fix or mitigation is available. * **Coordinate disclosure with you** — we will agree the timing and the content of any public disclosure with you before it is published. * Publish a security advisory when a fix or a workaround is available, including a description, the affected versions, the impact and severity, and what users need to do. * Request a CVE identifier where one is appropriate. * **Credit you** in the advisory if you would like to be credited, and respect your preference if you would rather not be. We do not currently operate a bug bounty and we do not offer payment for reports. We say so plainly rather than leaving it ambiguous. ## 4. Coordinated disclosure Our default position is public disclosure once a fix or a workaround is available, and no later than **90 days** after we acknowledge your report. We will agree a date with you rather than impose one, and we will move faster where a vulnerability is being exploited. If we need longer — because a fix is complex, or because customers operating air-gapped deployments need time to receive and apply it — we will explain why and propose a revised date. We ask that you do not disclose publicly before the agreed date. If we cannot agree, tell us, and we will make sure our advisory is ready to publish on your timeline rather than leaving users unprotected. ## 5. Scope **In scope:** * Solcis software in all licensing tiers, in any supported deployment shape. * The published SDK packages, including `@6clicks-rails/solcis-pep`, `Solcis.Pep` and the Python PEP SDK. * The container images, Helm charts, deployment packages and installers we distribute. * The `solcis.ai` website and any Solcis-operated service. **Out of scope:** * Third-party services and software we do not control, including vulnerabilities in dependencies where the correct recipient is the upstream maintainer. Where you report a dependency vulnerability that affects our product, we will act on it and, where appropriate, report it upstream ourselves. * Findings that require physical access to a host, or that depend on an already-compromised host or a malicious administrator. * Social engineering of Solcis staff, customers or contractors. * Denial-of-service testing, volumetric or otherwise. * Reports generated solely by automated scanners, with no demonstrated impact. * Missing security headers, outdated library versions, or configuration observations with no demonstrated exploitability. **Please test against your own deployment.** Solcis is designed to be self-hosted, so you can stand up an instance and test it freely. Do not test against a Solcis-operated environment, and do not test against another organisation's deployment. Do not access, modify or exfiltrate data that is not yours, and stop as soon as you have established that a vulnerability exists. ## 6. Safe harbour If you make a good-faith effort to comply with this policy while researching a vulnerability, we will: * Treat your research as authorised, and not pursue or support legal action against you in respect of it. * Not report you to law enforcement in respect of your research. * Work with you to understand and resolve the issue quickly. This protection does not extend to accessing, modifying, destroying or exfiltrating data belonging to Solcis, our customers or any third party; to degrading the availability of any service; or to conduct outside the scope set out in section 5. If a third party brings action against you in respect of research conducted in accordance with this policy, we will make it known that your research was authorised. If you are unsure whether something is within scope, ask us at `security@solcis.ai` before you do it. ## 7. Which versions we fix Solcis is **pre-general-availability**. Security fixes are applied to the most recent released version, and to `main`. Where a fix requires an upgrade, that upgrade is available to customers at no additional charge. We will publish a formal support period — stating how long each released version receives security updates — **before general availability**. Until then, customers running a self-hosted deployment should expect to upgrade to the current release in order to receive a security fix, and should contact their Solcis representative if that is not practical for them. ## 8. Third-party components Where a vulnerability originates in a component we integrate rather than in our own code, we will remediate our product and, where the component is still maintained and the maintainer is not already aware, report it to the maintainer and share any fix we develop. We check public vulnerability databases and project trackers first, so that we do not add duplicate reports to the workload of open-source maintainers. ## 9. A note on our regulatory obligations We may be legally required to notify a national computer security incident response team and ENISA about a vulnerability in our products that is being actively exploited, or about a severe security incident, under Article 14 of Regulation (EU) 2024/2847 (the EU Cyber Resilience Act). Those notifications are made to authorities, not published, and are separate from the coordinated disclosure process described in section 4. If your report triggers such an obligation we will tell you, and we will not name you to an authority without your agreement unless we are compelled to. ## 10. Contact `security@solcis.ai` is our single point of contact for security matters. It is monitored by the Solcis Head of Security and a nominated deputy, who have the authority to act on reports. For anything that is not a security issue, please use our ordinary support channels. *** **Policy owner:** Head of Security **Last reviewed:** 10 September 2026 **Next review:** 10 September 2027, or on any change to the reporting channel --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.solcis.ai/legal-centre/vulnerability-disclosure-policy.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.