Where ArboRule runs
ArboRule runs entirely on Amazon Web Services, in the us-east-1 region. We operate no hardware of our own, and no part of the service runs in an office.
AWS holds ISO/IEC 27001 certification and a SOC 2 Type II report for the infrastructure underneath us. That covers the data centres, the physical access controls, and the hardware. It does not cover our application, and we do not present it as though it does. See the last clause for what we hold ourselves.
The decision engine runs as an isolated AWS Lambda function. The application, the database, and the file storage are separate systems, and the engine reaches the application only through a signed, short-lived token that is scoped to one workspace.
Encryption
Everything is encrypted in transit and at rest. There is no unencrypted path in or out.
- In transit
- HTTPS everywhere, with certificates issued and renewed automatically. Every response carries HSTS for one year, including subdomains. Plain HTTP is redirected, never served.
- At rest
- Both disks on the application server are encrypted volumes. The file storage bucket is server-side encrypted, blocks all public access, and keeps object versions so a deleted file can be recovered. The container registry is encrypted as well.
- Secrets
- Your connection credentials, your webhook signing secrets, your trigger settings, and your AI provider keys are encrypted a second time inside the database, under application keys. A copy of the database alone does not reveal them.
- Passwords
- Hashed with bcrypt. We never store a password, and we cannot read one.
- Payment cards
- Handled by Stripe and never sent to us. We hold no card number.
Browsers are also sent a content-type, framing, referrer, and permissions policy on every page, so a mistake in one layer does not become a browser-level exploit in another.
Who can reach your data
Access is decided per workspace, and it is checked on the server for every request. A role in the browser decides what is drawn; it does not decide what is allowed.
- Roles
- Four workspace roles — admin, editor, viewer, and reviewer — plus two organization roles. A reviewer can clear a queue without being able to edit the flow that filled it.
- Single sign-on
- SAML and OIDC, with verified-domain discovery. Your identity provider stays the authority, so your own multi-factor and conditional-access rules apply to ArboRule too.
- Directory sync
- SCIM. A person removed in your directory loses access here, without anybody having to remember to do it.
- API keys
- Scoped per workspace and per environment, listed in settings, and revocable at any moment.
- Our own staff
- Nobody at ArboRule browses a customer workspace casually. Support access requires a written reason, expires automatically after 30 minutes, and is recorded with the name of the person who opened it.
The audit log
Every organization has an audit log that records who did what, and when. It covers sign-ins, permission changes, flow publication, connection changes, key creation, and support access.
It cannot be edited or deleted — by you, and equally by us. The database itself refuses the change, through a rule that sits below the application. An operator with full database access still cannot rewrite an entry. That is a deliberate design: an audit log an administrator can quietly amend is not evidence of anything.
You can read it in settings and export it as CSV, so it can go into your own archive rather than living only here.
How we build and ship
Every change reaches production through a pull request, and that pull request runs the following checks automatically.
- Static analysis for the common web vulnerability classes, over the whole application.
- A check of every dependency against the published vulnerability database. A known-vulnerable library fails the build.
- The full test suite, with a minimum line-coverage floor that fails the build when a new subsystem lands untested.
- Style and type checks on both the server and the browser code.
- A vulnerability scan of the container image, run when the image is pushed.
Dependency updates are proposed automatically every week for the server, the browser bundle, and the build pipeline itself. Production credentials are never in the repository: they live in AWS Parameter Store as encrypted values, and the application reads them through an instance role rather than a stored key.
Network and platform
- A dedicated virtual private cloud. Only the web ports are open to the internet.
- Administrative access over SSH is restricted to named addresses, with repeated-failure blocking on top.
- Instance metadata requires a session token, so a request-forgery bug cannot read the server's cloud credentials.
- Rate limits on sign-in, on sign-up, on the decision API, and on every public receiver, keyed so one noisy integration cannot starve another.
- Outbound webhooks are protected against request forgery and are signed with a rotatable secret, so a receiver can verify the message came from us.
- Bot protection on the public sign-up and demo forms.
- Errors are reported to a monitoring service that is configured to exclude personal data.
Backups and recovery
The database is dumped every night on the server, and an encrypted copy is written to separate object storage the same day. The offsite archive keeps 7 daily, 4 weekly, and 6 monthly copies, and it verifies its own integrity on every run. Uploaded files live in versioned storage, so a deletion can be undone for 30 days.
Platform logs are kept for 12 months, which is long enough to investigate a problem reported months after it happened. The full retention rules are in the privacy policy.
Stated plainly: the service runs in one region and one availability zone, and a restore is performed by an operator rather than automatically. We are not going to describe that as high availability. It is on the list below.
Your data, and your rights over it
For the content you put into a workspace, you are the controller and we are the processor. We do not use your workspace content to train models, and we do not sell personal data.
You do not have to ask us to exercise a data right. An organization admin can export the account, erase an individual user, or close the account entirely from within the product. A closure is armed 14 days ahead so an admin can cancel a mistake, and it then removes every workspace, flow, decision record, case, and file.
The privacy policy names every sub-processor that receives personal data, what each one does with it, and where it does it.
What we do not have yet
This clause is the reason the page is worth reading. Every vendor lists what it has. The useful question is what it does not have, and we would rather you learned it here than three weeks into a procurement review.
- ArboRule holds no ISO 27001 certificate of its own, and no SOC 2 report of its own. Our infrastructure provider holds both. A programme to certify the application is under way; ask us for the current stage.
- No third-party penetration test has been performed yet. One is planned.
- No data processing agreement is published yet. Ask us and we will tell you honestly where the draft stands.
- One region only. There is no choice of data residency, and no failover to a second region.
- Multi-factor authentication is not built into password sign-in. Organizations that connect single sign-on already get their identity provider's factors today, and that is the route we recommend.
- No published uptime commitment. We will not print a number we do not measure against a contract.
If one of these blocks a purchase, say so. Knowing which gap costs a real deal is how it gets prioritized.
Report a vulnerability
Write to hello@arborule.com with the words "security report" in the subject. Machine-readable details are published at /.well-known/security.txt.
Tell us what you found, how to reproduce it, and what an attacker could do with it. We aim to acknowledge a report within three business days, and we will tell you when the fix ships.
We will not pursue legal action against research carried out in good faith under the terms below. Test only accounts you own, do not run denial-of-service or automated scanning against production, do not access another customer's data, and give us a reasonable period to fix the problem before you publish.
We do not run a paid bounty programme. We do credit reporters who want to be credited.