Secure by default
The safe configuration is the default configuration. Security is a property of the design, not a checklist bolted on before launch.
Security
Commitments now. Attestations when they mean something.
We separate two things that marketing usually blurs: how KnownScope is built today, and the formal assurances that come later. This page is honest about both.
Architecture commitments and future attestations
In the architecture today
Secure-by-default design, server-side authorization, tenant isolation, encrypted data, and non-destructive history are how the product is being built: decisions you can evaluate now, in a technical conversation.
Published when applicable
Certifications, third-party audits, and formal assurance material (for example SOC 2, ISO 27001, or a penetration-test summary) will be published where they can be verified once they apply. We will not imply them before then.
Architecture commitments
How KnownScope is built.
Server-side authorization
Access decisions are enforced on the server for every request. The interface reflects permissions; it never defines them.
Tenant isolation
A tenant’s Campaigns and data are isolated from other tenants by design, with the boundary enforced independently of the client.
Encryption and least-privilege access
Data is encrypted in transit and at rest. Operator access to production data is least-privilege by design, granted for a stated reason rather than held by default. These are design commitments, written down here so you can ask about them directly.
Auditability
Field-level and event-level accountability produce a durable record of who changed what and when, useful during a response and after it.
Careful secret handling
Secrets and credentials are handled deliberately and kept out of source control. Configuration and secrets are separated as a matter of practice.
Bounded imports
Imports are validated and bounded: size, shape, and content are checked so a paste or an upload cannot become an ingestion problem.
Non-destructive history
Data practices favor additive history over destructive edits. The record of who changed what and when stays intact and can be exported, so reconstruction and recovery remain possible after the response is over.
Dependency & security scanning
Dependencies and code are scanned as part of development, so known-vulnerable components are caught and updated rather than quietly shipped.
Responsible disclosure
Found something? Tell us directly.
If you believe you have found a security issue, please report it to the address below. We welcome good-faith research and will work with you on a coordinated resolution. Please give us a reasonable opportunity to address an issue before any public disclosure.
security@init6.comA formal disclosure policy will accompany general availability.
Private preview
Evaluate the architecture with us.
Bring your security and identity requirements to a private-preview conversation. We would rather answer hard questions than avoid them.