Last updated: July 18, 2026 · Version 2.0
soul_state flow through a request and
are never persisted by us. On the hosted API we retain only your account and aggregate turn counts.
Because there is no conversation store, the blast radius of any incident is structurally small - the strongest
control is the data we never hold.LEO Soul’s design starts from a question most vendors answer the hard way: what if we’re breached? Our
answer is to hold almost nothing worth stealing. The Engine processes each turn and returns a result without
writing your message content or soul_state to disk. That single architectural choice - statelessness
- shrinks the attack surface, the retention risk, and the compliance burden all at once, and everything below
builds defence-in-depth on top of it.
soul_state to disk.
Even idempotent retries store only a request fingerprint and the decision action - never content.python3-saml library; provisioning is domain-scoped so an IdP cannot
assert a foreign address.X-RateLimit-* headers.Run LEO Soul three ways, from most-hosted to most-isolated:
| Mode | What reaches us | Best for |
|---|---|---|
| Hosted API | Aggregate turn counts only - no content, no
soul_state. | Fastest start; most teams. |
| SDK / in-process | Nothing - the Engine runs inside your own process. | Teams that want zero network hop. |
| Self-hosted / on-prem | Nothing - Docker inside your network; offline license verification; air-gappable. | Regulated or data-sensitive environments. |
We keep a small, auditable codebase with a security-first posture: a documented internal security audit (covering the engine, billing, auth, and enterprise surfaces), least-dependency design (the core is pure-Python with zero runtime dependencies), code review on changes, and secrets kept out of the repository. Security-relevant fixes are prioritised and shipped through our normal release pipeline; self-hosted customers receive them by pulling a new image.
The Hosted Service runs on reputable cloud infrastructure with a managed database, uses Stripe for payments (card data never touches us), and a transactional email provider. The in-product LEO Assistant uses OpenAI for that chat only - never the metered product turn. The current subprocessor list is in the Privacy Policy and available to Enterprise customers on request.
We maintain incident-response practices to detect, triage, contain, and remediate security events, and to learn
from them. If we determine an incident affects your personal data, we will notify you without undue delay and,
where required, notify regulators, consistent with the Privacy Policy and
DPA. Because we hold no conversation content, most incident scenarios cannot expose your
messages or soul_state - there is nothing there to expose.
Live status is published at /status, backed by real dependency checks rather than a bare
liveness ping. Incidents and planned maintenance are communicated by email, an in-app banner for every member of
a workspace, and a service.degraded webhook, so a customer's own systems can react automatically.
Failure behaviour is graded and documented rather than assumed. Inside the Engine, a module
that errors degrades to a pass-through and marks itself in the decision trace, so one failed check does not cost
the turn; a regulated deployment can switch this to fail-closed, where a turn whose safety check
could not run escalates for human review instead of answering. If the Service itself is unreachable,
the decision necessarily belongs to the client: our SDKs expose it as on_unavailable and default to
failing closed, so an unverified answer is never served silently. See the
resilience guide.
Account and billing data are backed up by our managed infrastructure; because message content is never stored, there is no conversation dataset to back up or lose. Availability is monitored by an external heartbeat that is independent of the application itself, so a total outage is detected even when nothing inside the service is able to report it. Enterprise SLAs and continuity terms are set in the MSA and order form.
We are candid about our stage. What is already true today is the strongest control of all - we hold no conversation data to lose - and we support the practical requirements enterprises ask for: a DPA, the EU/UK Standard Contractual Clauses for transfers, a subprocessor list, security questionnaires, a security review on your schedule, and a BAA for health data on Enterprise engagements. A formal SOC 2 program is on our roadmap; we will reflect certifications here as they are achieved rather than claim them before. For any compliance document or questionnaire, contact us below.
Security is a partnership. We secure the Software and the Hosted Service as described here. You are responsible for safeguarding your credentials and API keys, enabling 2FA, scoping keys, managing your team’s access, complying with your Model Provider’s terms, maintaining human oversight of outputs, and - for a self-hosted Deployment - operating and securing your own infrastructure (TLS, network, backups, patching the host).
If you believe you’ve found a vulnerability, please report it through our contact page with details and steps to reproduce. We aim to acknowledge within 3 business days and will work with you on a fix and coordinated disclosure. Please do not run automated scans against production or access data that isn’t yours. Our security.txt lists the current contact. We appreciate good-faith research and will not pursue action against researchers who follow this policy.
Kadropic Labs, Inc. - contact us · kadropiclabs.com. For a DPA, SCCs, or a security questionnaire, mention it and we’ll route you to the right document.