Security

Amblash AI is a SaaS (software as a service) platform of Adforn LLC, a company registered at 1007 Orange St, Wilmington, DE 19801 ("Amblash AI," "we," "us," or "our").

1. Security by Design

Amblash AI runs outbound email campaigns for business teams, which means it holds your company's campaigns, your prospects and the emails written for them. We build the Services so that this information is protected by default, without any setting you have to find and switch on.

Three principles shape that work:

Your company's data belongs to your company alone. Every campaign, prospect and record is tied to your company, and the Services are designed so that no other customer or Amblash AI can see it.
Every customer is protected equally. The same protections apply on every plan. No plan buys stronger security, and no plan gets weaker security.
Permissions are checked on our servers. What each person on your team can see and do is checked on our servers, not only in the screens of the app.

This page describes the practices we follow today, as of the Last Updated date shown on this page. It is not a certification or an audit report, and we do not hold any third party security certification. No method of sending or storing data over the internet is completely secure, and we cannot guarantee absolute security.

2. Behind the Scenes

The rest of this page explains four areas of our work:

Protecting your data: how we keep your account and your information safe while you use the Services.
Building a secure product: how we plan, build and release changes.
Security standards and testing: the independent standards we are working towards and the testing we carry out.
Hosting and incident handling: where the Services run and what we do if something goes wrong.

3. Protecting Your Data

3.1 Encryption in Transit (TLS/SSL)

Encrypted connections only. Our servers tell your browser to connect to us only over encrypted connections, and not to display our pages inside other websites.
Secure session cookies. The cookies that keep you signed in are marked secure, so your browser sends them only over encrypted connections, and scripts on a web page cannot read them.

3.2 Role Based Access Control (RBAC)

Roles. Every person in your company's account is either an Admin or a member.
Permissions. Your Admins decide what each member can see and do, feature by feature. For example, a member can be allowed to view prospects without being allowed to export them.
Checked on our servers. Every permission is checked on our servers on every request, not only in the screens of the app.
Your company's data stays with your company. Each company's data is kept within that company's account.
Platform administration. Access to our own platform administration is restricted separately from customer accounts.

3.3 Authentication

Passwords. We never store your password as written. We store it only with strong one way hashing, so it cannot be turned back into the password. When you create an account or change your password, we also check that the password has not appeared in a known public data breach, without ever sending your password to that check.
Verified email addresses. A new account's email address is verified with a one time code before the first sign in.
Business email addresses. Amblash AI is built for business use, so sign up from common personal email providers is refused.
Secure sessions. Your sign in session uses short lived credentials that are renewed automatically and replaced each time. If an old credential is ever presented again, which is a sign it may have been copied, we sign out every session on the account at once.
A second verification step. Anyone can add a second verification step at sign in, using codes from an authenticator app, with single use backup codes for recovery. The secret behind your authenticator app codes is encrypted before we store it, and it is shown to you only once, when you set it up.
Confirming it is really you. Certain sensitive actions, such as turning off the second verification step, removing a teammate, changing or cancelling your plan, and deleting your account, require you to confirm your identity again even though you are already signed in.
Your devices. You can see where your account is signed in and sign out any device, or every device except the one you are using.

3.4 Network Defenses

Separate networks. Our public website runs on a network separate from the application and your data. Our databases are not exposed to the internet by default.
Limits on requests. We limit how often requests can be made to every part of the Services, public and signed in, including signing in and other sensitive actions, to slow down automated attacks and password guessing.
Protection against forged requests. Every signed in action is protected against cross site request forgery, so another website cannot trick your browser into acting on your behalf.
Browser protections. Our pages cannot be shown inside other websites. Browsers are told not to guess the type of content we send, and we limit the information your browser shares about our pages when you follow a link elsewhere.
Approved addresses only. Only our own approved website addresses can call the Services from a browser.
Safe handling of website addresses. When you ask us to analyze your company's website, the request passes through safeguards that stop it from reaching our internal systems or any other address it should not reach.
Request size limits. Requests sent to the Services are limited in size.
Error messages. Error messages never reveal internal details of our systems.
Least privilege. The parts of the Services run without administrator privileges.

3.5 Other Security Protocols

Payments. Card payments are made through Stripe's hosted checkout and billing portal. Your card number and other card details go directly to Stripe and never reach our servers.
Verified notifications. Notifications we receive from Stripe and from our email delivery infrastructure are verified by digital signature before we act on them.
Verified sending domains. Sending domains are verified with SPF and DKIM records, which help receiving mail servers confirm that your email really comes from you.

3.6 Abuse and Spam Protection

Sending limits. Every company has a daily limit on the number of emails it can send.
Gradual warm up. A new sending mailbox starts with a small number of emails and increases gradually, which protects your sending reputation and the people you contact.

4. Building a Secure Product

4.1 Planning and Documentation

We describe changes in our written product and technical documentation, and review them, as part of building them.

4.2 DevOps

The Services run in containers built from our source code. Every release is produced by the same build process, and each part of the Services is built and released separately.

4.3 Quality Assurance

Our release builds run automated checks, including checks of the code's structure and types and, for our web applications, automated tests. If a check fails, the build stops.

4.4 Version Control

All of our source code is kept under version control, so every change is recorded and can be traced.

5. Security Standards and Testing

SOC 2. We are working towards a SOC 2 report, an independent audit of our security controls by a certified public accounting firm.

ISO 27001. We are working towards ISO 27001 certification, the international standard for information security management.

Penetration and vulnerability testing. Our platform has been through penetration testing and vulnerability testing. We review the results and fix any issues found.

We will update this page when our SOC 2 report and ISO 27001 certificate are issued.

6. Hosting and Incident Handling

6.1 Hosting

The Services are hosted on Amazon Web Services (AWS). The Services are divided across 6 separate, secured AWS EC2 servers.

6.2 Incident and Breach Management

If we become aware of a breach of security affecting personal data we process on your behalf, we will notify you without undue delay, as set out in our Data Processing Agreement.

Last Updated: September 2026

Effective: October 2026