> 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/security-and-integrity.md). # Security and integrity How Solcis approaches security, integrity, and data handling. ## Our approach Solcis is self-hosted. The [Software](/legal-centre/software-licence-and-terms.md) runs entirely inside an environment you control, and Solcis does not host or operate it on your behalf. We are responsible for the security of the Software we ship and how we build it. You are responsible for how it is deployed, configured and operated in your environment. ## Shared responsibility | Area | Solcis | You | | ------------------------------- | -------------------------------------------------------------------- | ------------------------------------------------------------------------------ | | Source code, build and release | Building and releasing the Software securely | — | | Release integrity | Signing the release manifest and publishing SBOMs and our public key | Verifying each release before you deploy it | | Vulnerabilities in the Software | Triaging reports and releasing fixes | Installing security updates | | Hosting and network | — | Infrastructure, network segmentation, TLS and firewalling | | Identity and access | — | Who can administer Solcis and approve policies | | Keys and credentials | — | Generating, storing and rotating the keys and credentials your deployment uses | | Decision ledger | Designing the tamper-evident ledger | Storage, backup, retention, and whether independent witnessing is enabled | | Configuration | Configuration guidance in the Documentation | Configuration choices and any change from the defaults | ## Software integrity Each Solcis release is described by a release manifest signed with Ed25519. The manifest pins every container image by digest, so you can confirm the images you deploy are the ones we released. Each release also ships a CycloneDX software bill of materials (SBOM). Verify the manifest signature against our published public key before you deploy. For how we build, test and maintain the Software, see [Secure development](/legal-centre/secure-development.md). ## Decision records Every decision the Software makes is written to a hash-chained, tamper-evident ledger in your environment. Altering or removing an individual record breaks the chain, and the break is detected on verification. On its own, the hash chain cannot rule out the whole ledger being replaced by someone who controls your environment. Independent witnessing closes that gap: a witness outside your deployment countersigns checkpoints of the ledger, so a third party such as an auditor or regulator can confirm the ledger has not been rewritten without relying on Solcis or on you. Independent witnessing is optional, and is not available in air-gapped deployments. ## Data handling Solcis does not receive, store or process Customer Content: the data, actions and payloads your agents and systems submit to the Software. Customer Content stays in your environment. * **Air-gapped deployments.** Nothing is sent to Solcis. Licensing uses an offline licence. Air-gapped operation is available where your order form provides for it. * **Connected deployments.** The only data sent to Solcis is licence metadata, sent to the Solcis Licence Server for licensing and billing and does not include Customer Content. * **Support.** Solcis support may ask for logs or a diagnostic bundle to resolve an issue, but only with your agreement, and you choose what to share and can redact it first; we never need evidence ledger contents or action payloads to diagnose a fault. Anything you send is transferred over an encrypted channel, used only for that support case, accessible only to the engineers working on it, never used for training or any other purpose, and deleted within \[30] days of the case closing. * **Product improvement.** Customer Content is not used to train, fine-tune or evaluate Solcis models or to improve the product. ## Sub-processors Because Customer Content never reaches Solcis, Solcis is not a processor of Customer Content and has no product sub-processors. Licence metadata is handled by Solcis. Providers used for our own website and sales operations are listed in the [Privacy policy](/legal-centre/privacy-policy.md). ## Corporate security Solcis protects its own corporate systems with access control using single sign-on and multi-factor authentication, encryption of corporate data, and review of the suppliers we rely on. How we develop and release the Software is described in [Secure development](/legal-centre/secure-development.md). ## Certifications and attestations Solcis does not currently hold a security certification or an independent attestation report. Our secure development programme is structured on the NIST Secure Software Development Framework (SP 800-218 v1.1) and its profile for AI models, SP 800-218A, and our management system is being aligned to ISO/IEC 27001 and ISO/IEC 42001. Certifications and reports will be listed here once obtained. ## Report a vulnerability Report security issues to `security@solcis.ai` or through GitHub private vulnerability reporting. We acknowledge reports within three business days. You can encrypt your report with our [PGP key](https://solcis.ai/.well-known/pgp-key.txt). Our [Vulnerability disclosure policy](/legal-centre/vulnerability-disclosure-policy.md) sets out how to report, what we will do, and the safe harbour we offer to good-faith researchers. Machine-readable contact details are published in [security.txt](https://solcis.ai/.well-known/security.txt). --- # 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/security-and-integrity.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.