Security & Trust
Where Ontinuity stands today
An honest posture, not a maturity claim
Ontinuity is an early-stage, direct-engagement research and applied-AI project. This page states plainly what exists today, what does not yet, and what is planned — because a verification-first system should be honest about its own boundaries. Where something is a roadmap item rather than a present capability, it says so.
Current access model
Ontinuity is direct-engagement only. There is no self-serve enterprise SaaS being represented, and no public sign-up that processes customer data. Work is delivered as verified output through direct conversation. Where the session engine is used, model API keys are user-supplied. This matters for trust: the surface that could mishandle data is deliberately small, because there is no multi-tenant product ingesting it yet.
Where the architecture is genuinely strong
These are not aspirations — they are properties the system was built around from the start, and they happen to be the controls enterprise buyers most often find missing in young AI projects.
Tamper-evident audit trail. Every consequential action — every build, review, deployment, and correction — is written to an append-only operating record keyed on shared identifiers. Any decision can be walked from the discussion that produced it, to the commit that enacted it, to the receipt that confirms it, and back. Auditability is the substrate the system runs on, not a logging feature added for compliance.
Least-privilege access. Privileged actions on infrastructure run through a small set of named, bounded operations — never a general shell or arbitrary command. Each operation does exactly one thing and is logged at both ends. A compromised credential is contained to the specific, recorded things those operations permit, rather than becoming open-ended access.
Separation of duties. The component that deploys a change is structurally forbidden from being the one that authored it; an independent review and sign-off is required before anything ships, and a self-deploy is recorded as a violation. No single actor authorizes its own consequential output.
Encryption in transit. All public surfaces are served over TLS.
How regulated data is handled
For regulated-data workflows, Ontinuity’s posture is to minimize exposure at the boundary rather than manage it downstream. The Boundary De-Identifier de-identifies sensitive data on the operator’s own machine before any field crosses to a service, keeps the identity-to-token mapping local, and independently verifies the sanitized output. The intent is that nothing identifiable from a de-identified dataset is sent to the service at all. This is an architectural approach to lowering regulated-data risk; it does not by itself constitute a compliance certification, and any specific engagement’s data handling is scoped to that engagement.
What is on the readiness roadmap
The following are planned, not yet in place. They are listed here because naming the gaps is itself part of an honest posture — and because this roadmap was shaped directly by enterprise-readiness guidance.
Business and legal. Formal incorporation (LLC), Terms of Service, Privacy Policy, Acceptable Use Policy, a published subprocessor list, and standard agreements (NDA, DPA, SLA) are on the near-term roadmap. Professional-liability and cyber-liability insurance are being scoped.
Security controls. Encryption-at-rest verification, enforced multi-factor authentication on all administrative accounts, dependency and code scanning in the build pipeline, and written incident-response and disaster-recovery plans are planned hardening steps.
Compliance. Formal certifications (such as SOC 2) are deferred until an engagement requires them — the strong audit-trail foundation is intended to make that path more straightforward when the time comes. HIPAA considerations are tracked specifically because of the regulated-data use cases the de-identifier targets.
The principle behind this page
A system whose entire thesis is “don’t trust the component — verify it” would be incoherent if it asked you to simply trust its security claims. So this page states what is real now and what is not, and it will be kept current as the posture changes. For the architecture that makes verifiability the core of the system, read Reliability Without Trust. For serious or regulated-data engagement, the most useful next step is a direct conversation. contact@ontinuity.org