Security Statement

This page describes the technical and organizational measures outr uses to protect the personal data and business data that runs through it. Words used here mean what they mean in our Privacy Policy and Data Processing Addendum.

We take security seriously because outr handles account, billing, business-profile, lead, and reply data on behalf of our customers. The measures below are the ones we actually run today. We do not claim protections or credentials we do not have.

1. Architecture and data isolation

• Managed, per-tenant database. Your data lives in a managed relational database run by our hosting and database provider. Customers are kept apart inside the database with row-level security, so each customer's rows are scoped to that customer's account.
• Service-role writes for sensitive operations. Ownership links and billing columns cannot be written from a browser session. Sensitive writes (subscription state, campaign ownership, provisioning records) happen server-side under a privileged role, never from the client.
• Row-level-security hardening. A dedicated hardening pass revoked client write access to ownership and billing columns and scoped internal configuration reads (agent-brain and prompt tables) to signed-in access only, closing paths that used to be more open.

2. Encryption

• In transit. All traffic between you, our application, and our providers runs over HTTPS (TLS).
• At rest. Data at rest is encrypted by our hosting and database provider using their platform-managed encryption.

3. Secrets and credentials

• Secrets live in environment variables. API keys, database credentials, and provider tokens sit in environment configuration, never committed to source code.
• Constant-time secret comparison. Automated-job and webhook shared secrets are compared with a constant-time check to reduce the risk of timing attacks.
• Passwords. Your password is stored and hashed by our authentication provider. We never keep it in our own tables.
• Card data. We do not store card numbers, expiry dates, or security codes. All of that is handled by our payment processor. We hold only the identifiers and subscription details it gives us.

4. Application and integration safeguards

• Payment webhook verification. Incoming billing events from our payment processor are checked against its signature before we act on them, so we never process a forged billing event.
• Open-redirect protection. Our sign-in callback validates where it sends you before forwarding, so the login flow cannot be abused to push you to an untrusted destination.
• IP rate limiting. Signup, the free lead-count preview, and agent requests are rate limited by source IP to blunt automated abuse and brute-force attempts.
• Spend kill-switches on paid sourcing. Paid lead-sourcing runs are bounded by layered spend caps (per-run limits, plan-period budgets, and a global monthly kill-switch), so a fault or abuse cannot run up uncontrolled cost or volume.
• Human approval before sending. Nothing goes out until you review a campaign and approve it. No background job starts sending on its own. This is a core safety control, covered further in our Abuse Prevention Policy and Terms of Service.

5. Provider security

outr runs on a handful of trusted providers: our hosting and database provider, our payment processor, our email-sending infrastructure, and others listed in our Sub-processor List. Each brings its own security controls, encryption, and certifications for the part of the service it powers. We pick providers on their security posture and put data-processing terms in place with them. We stay responsible to you for the parts of the service we run.

6. Certifications

We do not currently claim any certifications, audits, or attestations, and we will not state one we have not completed. When we obtain a formal certification or independent audit, we will say so here.

7. Shared responsibility

Security is shared. We secure the service, our infrastructure, and the way we handle your data. You are responsible for:

• keeping your login confidential and using a strong, unique password;
• controlling who can get into your account and the sending inboxes and data inside it;
• the lawfulness of the recipients you target, the content you approve, and your own compliance obligations, as set out in our Terms of Service and Acceptable Use Policy; and
• telling us promptly if you think your account has been compromised.

8. Reporting a vulnerability

If you think you have found a security vulnerability in outr, report it to us at support@tryoutr.io. Give us enough detail to reproduce and assess it: the affected URL or endpoint, what the behavior was, and the steps to trigger it. Please give us a fair chance to investigate and fix it before any public disclosure, and do not access, change, or delete data that is not yours while you test. We appreciate responsible disclosure and will acknowledge legitimate reports.

9. No method is completely secure

We work hard to protect your data, but no way of sending data over the internet and no way of storing it electronically is completely secure, so we cannot promise absolute security. We run the measures described here and improve them over time, and we handle security incidents under our internal incident-response process, including any breach-notification duties the law puts on us.

10. Changes

We may update this statement as our security measures change. Material changes show up here with a new version and date.

11. Contact

For security matters, including vulnerability reports, and for general or legal questions, email us at support@tryoutr.io.