Security & Trust
Security built into the runtime.
Tenant-scoped sessions. Context-bound secret encryption. Execution journals as evidence. Owlie's security posture is not a reporting layer on top of the product — it is how the product runs.
SOC 2 program in progress. Trust Center published.
Architecture.
Tenant isolation.
Every Owlie tenant is scoped by subdomain and by database-level `tenant_id` on every query. No query crosses tenant boundaries. Sessions, data, audit trails, and encryption contexts are all tenant-scoped.
Context-bound secret encryption.
Secrets — connector credentials, OAuth client secrets, Function secrets, settings — are encrypted per tenant and bound to their declared usage context. Ciphertext moved outside its original tenant or workflow fails closed at decryption time. Tenant keys rotate without breaking historical ciphertext. AWS KMS anchors the top-level key material.
Policy-gated authentication.
One login journey, tenant-configured: password — optionally a zero-knowledge mode that keeps the raw password in the browser — magic link, MFA (TOTP or passkey), terms acknowledgment, profile completion, external OIDC SSO. MFA can be required, admin-only, or off per tenant policy. Grace periods for staged rollout.
One auth surface to audit.
Other Owlie services authenticate incoming requests through a single auth service — browser sessions and API keys validated in one place, with a normalized identity + authorization snapshot returned. No service re-implements authentication parsing.
Granular permission catalog.
Admin access is governed by a tenant-wide permission catalog behind system and custom roles. Role assignment is guardrailed: an admin cannot grant a role carrying permissions they do not hold themselves, so access cannot be escalated past the granter's own.
Post-quantum gateway enrollment.
Gateway agents that reach into a customer's private network enroll with an ML-DSA-65 key pair generated on the agent itself. A single-use token bootstraps the first connection; every connection after is authenticated by the post-quantum private key, and the token cannot be reused.
One governed notification pipeline.
Every person-facing message — login links, approvals, provisioning outcomes — flows through a single pipeline. Security-class messages (login, verification, reset) are structurally non-suppressible by tenant policy or personal preference. Sensitive contents are encrypted at rest, and bearer links are redacted from the stored, auditable copy.
Governed file uploads.
Uploaded bytes go straight from the browser to tenant object storage through a short-lived, single-purpose address — they never transit Owlie's compute. After the bytes land, a content-signature check verifies a file's real contents against its declared type, catching the type-spoofing that extension rules miss.
Evidence, built in.
Per-step execution journal.
Every provisioning operation records each step with status, timing, and structured error capture. Retries don't overwrite prior context; superseded attempts are marked, not deleted.
Actual-state snapshots.
After a successful apply, observed state is persisted in the same transaction that advances the version counter. What we believe is true on the target cannot drift from what we recorded as applied.
Access reviews.
Review campaigns with reviewer accountability, completion tracking, and exportable artifacts. Part of the standard launch feature set.
Tenant audit log.
A generic, append-only governance log — no update, no delete. Admin and system events are queryable by namespace, event type, outcome, and time, and credential-shaped fields are redacted before an event is stored.
Platform status, in the open.
A public status page at status.owlie.com reports each component's health and its availability against a stated SLO, with error budget consumed and remaining over 30- and 90-day windows.
Execution journal — filtered view
Per-step record of a recent operation — status, timing, target-system response.
Formal review materials.
Our Trust Center at trust.owlie.com hosts the current controls list, data-processing documentation, and vulnerability disclosure policy. Our current subprocessor list is available on request ahead of general availability. Our SOC 2 program is in progress. When attestation completes, the report will be available through the Trust Center under NDA.
Vulnerability disclosure.
We welcome reports from security researchers and customers. Our disclosure policy is published at /security/vulnerability-disclosure. Send reports to security@owlie.com. We commit to acknowledgement within one business day.