Security & Trust
Security built into the runtime.
Owlie scopes sessions to each tenant, binds encrypted secrets to their usage context, and records execution journals as operations run.
Architecture.
Tenant isolation.
Owlie enforces logical tenant isolation in the application. The request hostname identifies the tenant, and shared service queries apply tenant_id predicates alongside customer filters. Lower-level database callers must supply tenant scope. Customers share database and compute infrastructure.
Context-bound secret encryption.
Secrets, including connector credentials, OAuth client secrets, Function secrets, and 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.
Tenant-configured sign-in supports passwords, external OIDC and SAML, TOTP, and WebAuthn passkeys. Browser Secure Password sign-in uses OPAQUE without including the password in the login payload; other credential flows have different boundaries. Sensitive credential and login-policy changes require recent authentication.
One auth surface to audit.
The shared authentication service validates browser sessions and service-account API keys against tenant and identity state. API authorization then checks the actor’s permissions. Internal service bindings form a trusted control plane; the key-management service also requires caller enrollment and scoped capabilities.
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.
Customer-operated gateways generate ML-DSA-65 signing keys locally and enroll using a short-lived, single-use token. Custom connectors require a cloud-signed execution grant and the operator’s local allowlist, with the exact bundle hash checked before execution. Customers secure the host and install verified updates; automatic updates are off by default.
One governed notification pipeline.
Every person-facing message, including login links, approvals, and 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 access.
Initial browser uploads go directly to tenant object storage. Owlie verifies size and supported file signatures before publishing the completed file. Downloads check access to both the tenant-local file and its owning entity. File-signature checks identify supported formats; they are not malware scanning.
AI authority and secrets.
Dashboard AI uses the signed-in user’s authority; external MCP uses the caller’s service-account key. Both pass through normal API authorization. Designated dashboard actions require the current actor’s confirmation, not a second approver. Supported secure-input cards send secrets directly to the API and return value-free receipts to the assistant.
Policy checks before fulfillment.
Owlie checks requested access against policy before fulfillment. If a complete decision is unavailable, fulfillment is held and retried rather than starting provisioning. Deny policies take precedence over grants, and blocking denies require authorized exceptions. Customers maintain their policies and approvers.
Evidence, built in.
Per-step execution journal.
Provisioning records execution steps, status, timing, and structured errors. Workflows use bounded retries and explicit failure states. Ambiguous external side effects are held for reconciliation rather than retried without regard to whether they are safe to repeat.
Actual-state snapshots.
After a successful apply, the recorded applied state and version advance in the same database transaction. This keeps Owlie’s bookkeeping consistent; it does not prevent later changes or drift in the connected system.
Access reviews.
Certification review campaigns provide reviewer accountability, completion tracking, and exportable evidence. Subjects cannot certify their own access, and reviewer resolution fails closed when no eligible fallback remains.
Tenant audit log.
Tenant-scoped security and governance events record actor context and are queryable by namespace, event type, outcome, and time. Audit-log access requires a dedicated permission, and credential-shaped fields are redacted before storage. Retention is configurable and defaults to 365 days, subject to tenant deletion.
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.
Security operations and recovery.
Production access and response.
Production access is restricted to authorized personnel based on operational need, with MFA required wherever available. Service monitoring feeds operational alerts, and a documented incident response plan covers investigation, escalation, recovery, and notification obligations. Identified vulnerabilities have a remediation target of 30 days, regardless of severity.
Recovery objectives.
Our operational targets are a 24-hour RTO and a five-minute database RPO within the PlanetScale point-in-time recovery window. Separate daily encrypted backups provide older recovery points at approximately 24-hour intervals and expire after 30 days. These are operational targets, not contractual guarantees. Scripted database restores were tested on September 15, 2026; those tests were not a full-service disaster-recovery exercise.
Data location and deletion.
The production relational database is hosted in Northern Virginia. Other processing and storage use Cloudflare’s distributed infrastructure, so this is not an all-data US residency commitment. Tenant functionality is disabled on termination; active-system data is retained for 30 days, then deleted. A minimal deletion receipt remains and is used to scrub deleted tenants from restored backups.
Shared responsibility.
Owlie operates the application and its security controls. Customers configure sign-in, access policies, service-account permissions, API-key expiry and rotation, and connected-system access. Customers also review their code and maintain gateway hosts, local secrets, allowlists, and updates. The whitepaper details these boundaries and the remaining configuration choices.
Formal review materials.
Owlie has completed a SOC 2 Type II examination covering April 16 through July 16, 2026. The report is available under NDA through our Trust Center (opens in new tab). Consult the report for its scope and findings. Our current subprocessor list is published at owlie.com/legal/subprocessors.
We plan annual independent penetration testing. The first test is planned for later in 2026 and has not yet been completed.
Our Security Whitepaper describes the architecture, operational controls, and shared responsibilities, with a technical appendix. It complements the independent assurance report; it does not replace it.
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.