Security and trust
A page about security that lists adjectives is worth nothing. This one lists mechanisms: what the platform does, where it does it, and what is switched on today versus built and waiting.
Last updated 19 September 2026.
Where things stand today
The platform runs on synthetic data only. No real client, family or caregiver record exists in it, so no health-privacy obligation has yet been triggered. Everything that those obligations require of a system is built in now, so that it is switched on and not retrofitted when the first real record arrives. In the product specification's own words, the switch list is:
- a business associate agreement with our hosting provider;
- moving language-model traffic to a transport covered by that agreement;
- agreements with every vendor in the data path, on the rule that no agreement means no real data through that vendor;
- a named security officer, a risk assessment, access and audit policies, an incident-response plan, and workforce training;
- consumer AI tiers prohibited by written policy.
The trigger is the first real client or caregiver record, not a date. The obligations that attach to background checks under the Fair Credit Reporting Act are live already, because they attach to the check, not to health information.
Certifications Roost does not hold
Roost holds no SOC 2 report, no ISO 27001 certificate, no HITRUST certification and no payment-card attestation of its own. Nothing is "HIPAA certified", because no such certification exists. Roost is not a licensed home care agency, and does not need to be for what it does: it introduces people and does not provide care.
What does exist is a written security program that maps what is built here to the six functions of the NIST Cybersecurity Framework, names the file or test behind every line, and says out loud what is missing. Organising a program around a framework is not the same as being assessed against one, and this page says nothing stronger than that.
One agency cannot see another
Every table that holds an agency's records carries a row-level policy enforced by the database itself, keyed on the agency the signed-in person belongs to. A query with no agency in scope returns nothing rather than everything. The policy applies to the application's own database role, so a mistake in a screen cannot widen what a query returns. A test enumerates every table in the database and fails if one is added without a policy.
Within an agency, access is by role, and the sensitive actions, ordering a background check or exporting records among them, require the person to have signed in again recently.
A log that cannot be quietly edited
Every action that changes a record writes an entry to an audit log that the application can add to and cannot update or delete; the database grants make that so, and a test checks the grants. Each entry is then hashed together with the one before it and sealed with a key held outside the database, so a change to any entry, or the removal of one, is visible as a break in the chain. The chain is verified in our integration pipeline on every change, and an agency administrator can read their own agency's entries and nobody else's.
Signing in
- Staff accounts require a second factor, a time-based code from an authenticator app, and cannot do anything until it is entered. Recovery codes are issued once and stored only as hashes.
- Sessions live in a cookie the browser keeps away from scripts, expire after a period of inactivity and after an absolute lifetime, and can be revoked.
- Sign-in, second-factor and password-reset attempts are rate-limited, and the limits are shared across every server.
- Passwords are stored as salted hashes, never in a form we can read back.
- When our support staff need to see an agency's screen as one of its users, the access is time-limited, requires a written reason, is marked on every screen, and is logged at both ends.
Encryption
Everything in transit is over TLS, and browsers are told to insist on it. The production environment is defined entirely in code that is checked on every change: it encrypts database storage and files at rest with keys we manage, keeps the database off the public internet, and writes the audit archive to storage that cannot be overwritten for six years. Employer identification numbers are encrypted at the field level and never read back to a screen.
Outside services and the vendor gate
Every outside service sits behind an adapter with a stand-in that runs the whole loop locally, so no data leaves the system until a real adapter is switched on. A real adapter cannot even start without its credentials, and switching one on requires the agreement register to be updated in the same change. This is the public half of that register:
| Service | What it would handle | Agreement |
|---|---|---|
| Amazon Web Services | Hosting, the database, file storage and the archive | Required before real data; not yet executed |
| Postmark | Email notices | Vendor selected; agreement to be executed before the first real message |
| Twilio | Text messages | Required before real data; not yet executed |
| Telnyx | Clock-in by phone call | Required before real data; not yet executed |
| Checkr | Background checks | Required before real data; not yet executed |
| Dropbox Sign | Signing background-check disclosures | Required before real data; not yet executed |
| Stedi | Billing a payer and checking coverage | Required before real data; not yet executed |
| HHAeXchange and Sandata | State visit-verification systems | State data agreement, per state; not yet executed |
| Mapbox | Turning an address into a map position | Required before real data; not yet executed |
| Anthropic, via Amazon Bedrock once real data exists | Drafting and summarising | Required before real data; not yet executed |
| Temporal Cloud | Running long-lived workflows | Required before real data; not yet executed |
| Sentry | Tracking faults in the software | Required before real data; not yet executed |
| Stripe | Card payments for private-pay families | Not enabled; agreement required before it is |
| OIG exclusion list | Checking staff against the federal exclusion list | Not needed: a public file is downloaded, nothing is sent |
Two lines the adapters hold regardless of vendor: a background-check report is never stored, only its result and a link to it at the provider; and identity-document numbers never cross the employment-verification adapter at all.
Software that assists
All language-model traffic goes through one gateway with a monthly spending cap shared across every server and a kill switch per feature. With a switch off, that feature makes no call at all, which is proven per feature by a test. The models draft, explain and flag; a person reviews every output before it counts, and no model decides whose application is approved, who a family meets, what is charged or what a reading means. No software scores, ranks or grades applicants.
Reporting a vulnerability
If you have found a security problem in this site or the app, write to security@roost.us. A person reads it. Tell us what you found, how to reproduce it, and how to reach you. Please give us a reasonable time to fix it before you publish, do not open or change records that are not yours, and do not degrade the service for the people using it. We do not pursue good-faith research that stays within those lines.
For anything that is not a vulnerability, the contact page has the support address, support@roost.us. Whether the platform is up right now is on the status page.