Security at Able
Search Rebel Inc., d/b/a Able Software (“Able”), builds and operates the Able platform. This page states how customer data is protected and how to reach us about security.
Where your data lives
The platform runs entirely in Amazon Web Services, in the us-west-2 region (Oregon), with the backup replica in us-east-1.
Each customer application has its own PostgreSQL database, storage paths, worker microVM (Firecracker) and token signing key; a session token minted for one app never validates against another. Access to data is role-based and deny-by-default, enforced at the data layer.
Requests enter only through Amazon CloudFront and AWS WAF; the application service, databases and microVMs are not reachable from the internet directly.
Encryption
- At rest: the databases, file storage and workspace are encrypted under AWS KMS or S3 server-side encryption (AES-256).
- In transit: every request to the platform, and every connection to a vendor, a database or a customer system, runs over TLS.
- Secrets: tokens, API keys and credentials are encrypted with AES-256-GCM under KMS-wrapped keys and referenced by handle, never written in code or logs. Passwords are stored as bcrypt hashes.
Access
- Able’s staff reach production under individual identities with multi-factor authentication, only to operate the service, through audited doors; there is no shared production login.
- Access is granted by role, with least privilege, and reviewed every quarter across GitHub, AWS, Google Workspace and the platform’s operator grants.
- A departing person’s accounts are removed or suspended within one business day, and the secrets they could read are rotated.
- Every person signs a confidentiality agreement and trains in security every year.
Monitoring and logging
- Every component logs centrally to Amazon CloudWatch; production logs are kept 365 days and never carry a secret. AWS CloudTrail records every control-plane call.
- Every error-level event becomes a tracked issue, posted to the operators’ channel and closed with its fix.
- Amazon GuardDuty threat findings of medium severity or above, and every root sign-in, reach the same channel; a health check probes the platform every 30 seconds from eight regions.
- Each app with a daily digest receives it every morning; a watchdog alerts when one is missing.
Backups and continuity
- Every night each app’s database, the shared platform catalog and the file workspace are backed up to Amazon S3; daily copies are kept 3 days, weekly copies 90 days and monthly copies 180 days.
- The production database keeps seven days of point-in-time recovery; the database backups are replicated to a second region, us-east-1.
- Recovery objectives (point / time): 1 hour / 4 hours for lost or corrupted production data; 24 hours / 8 hours for the loss of the region.
- Every deploy is verified, and can be undone with one command.
Incident response
Every incident is rated and handled within its severity’s target:
- SEV-1 — a confirmed data exposure, an authentication bypass, a leaked credential with access to customer data, or a complete outage: contained within the hour.
- SEV-2 — a vulnerability that is exploitable but not exploited, or a partial outage: the same day.
- SEV-3 — a degraded surface with no data at risk: the next business day.
Containment comes first. Affected customers are notified within 72 hours of confirming an incident that affects their data. Every SEV-1 and SEV-2 incident closes with a written post-mortem; the plan is rehearsed every year.
Development
- Every change is a git commit under a named person’s identity. Able practices AI-assisted development under a person’s direction: an agent works only inside a session a named person started and directs, and that person owns its changes.
- Every platform build runs blocking security gates (static analysis, dependency analysis, tests, a software bill of materials); a failed gate deploys nothing. Every repository is scanned for exposed secrets.
- Production changes only through a merge and a build started by an authorized operator, recorded in CloudTrail; production branches cannot be deleted or force-pushed. In production an agent changes or deploys only on its owner’s explicit confirmation.
- A vulnerability the gates do not block is fixed within 7 days (critical, high), 30 days (medium) or 90 days (low, or accepted in writing).
Subprocessors
Amazon Web Services hosts the platform and is its subservice organization; its data centers, hardware and managed services are covered by AWS’s own SOC 2 report, which Able reviews every year.
Every other third party, model providers and messaging carriers included, is managed as a vendor under Able’s Vendor Management Policy.
Compliance
Able’s controls are mapped to the SOC 2 Trust Services Criteria for Security, Availability and Confidentiality; each control has an owner, a frequency, an automated test where one is possible, and current evidence in Able’s own review application. The controls matrix is available to customers on request.
Able holds a CASA Tier 2 (App Defense Alliance) Statement of Validation from TAC Security, issued August 7, 2026 and valid until August 8, 2027.
Report a vulnerability
Email security@ablesoftware.io with the product or address affected, what you found and the steps to reproduce it, and how to reach you. We acknowledge every report within 72 hours. There is no public bug bounty. The machine-readable contact is at /.well-known/security.txt.
Policies on request
Able’s security program is written in twenty policies, available under NDA on request:
- Acceptable Use Policy
- Access Control Policy
- AI-Assisted Development Policy
- Asset Management Policy
- Business Continuity and Disaster Recovery Policy
- Change Management Policy
- Code of Conduct
- Data Classification and Handling Policy
- Data Retention and Disposal Policy
- Encryption and Key Management Policy
- Government and Public Authority Data Request Policy
- Human Resources Security Policy
- Incident Response Policy
- Information Security Policy
- Logging and Monitoring Policy
- Physical Security Policy
- Risk Management Policy
- Secure Development Policy
- Vendor Management Policy
- Vulnerability Management Policy
Last updated October 17, 2026. This page is reviewed with Able’s policies once a year.