Security, tenant isolation and audit for your HR data
Ascend keeps each organization's people data isolated in the database itself, limits every person and every AI agent to what their role allows, and records who changed what in an audit trail that the application cannot edit or delete.
One organization cannot read another's rows, and the database enforces it.
Ascend is multi-tenant, so isolation is the first thing to check. It is not a filter in application code that a new query could forget. Every tenant-scoped table has Postgres row-level security switched on and forced, and the application connects as a restricted database role that is not a superuser, cannot bypass row-level security, and owns none of the tables it reads. A session with no organization set sees zero rows, not everyone's.
- Automated tests connect as that restricted role and attempt cross-tenant reads, updates, deletes and inserts; all of them must fail. The tests run against a real Postgres in CI on every change.
- A separate test fails the build if any tenant-scoped table is missing its row-level security policy.
- Inside an organization, access follows roles and the reporting line: an employee reaches their own record, a manager their reports, an admin the organization. Anyone else gets a refusal.
- Documents in the company brain carry grants, and search results are filtered by those grants in the database, so an answer cannot quote a document the person asking could not open.
Sign-in runs on identity infrastructure Ascend operates itself.
Authentication runs on Keycloak, self-hosted as part of Ascend rather than bought from a third-party identity vendor, so login records and sessions do not sit with another company. The web app signs in over OpenID Connect, and the API checks every token's signature, issuer and audience before it does anything.
- Repeated failed logins trigger a temporary lockout.
- The production web client cannot use the password grant, and a CI check fails the build if that setting is ever turned back on.
- Keycloak configuration is kept in the repository as a reviewable file, not as settings clicked into an admin console.
- A token that belongs to more than one organization is refused rather than guessed at.
AI agents propose. A named person decides.
Each organization sets an autonomy level per domain. At observed, the default for every domain on a new tenant, an AI agent proposes changes and never makes them. At assisted, it may carry out reversible actions and must ask before anything irreversible. At autopilot, it acts and reports what it did.
- Performance reviews, succession and offboarding can never be set to autopilot. The API refuses it, and a database constraint refuses it again if a later screen forgets to.
- Whatever the setting, an agent action that would touch more than ten people is held for confirmation.
- An AI agent calls the same API a person does, with that person's own credentials, so it cannot see or change anything its human could not.
- A performance review publishes only after a human has approved every section and a named person presses publish; both are recorded.
An audit trail the application cannot rewrite.
Changes across the product write to one audit log, in the same database transaction as the change itself. The application's database role has had UPDATE and DELETE revoked on that table, so a row, once written, stays as it was.
- Each entry records the accountable person, the action, the record it touched and what changed.
- When an agent carried out the action, the entry names the agent as well as the person who asked. The accountable party is always a human.
- Admins can filter the trail by person, action, record and date in the product and export it to CSV. The export writes its own entry, so pulling the log is itself on the log.
| Control | How Ascend implements it | What you can check |
|---|---|---|
| Tenant isolation | Postgres row-level security, forced, on every tenant-scoped table; the app connects as a role that cannot bypass it | The cross-tenant tests, and a second test organization that sees none of your data |
| Access within an organization | Role checks on each route, plus reporting-line checks on people records | Sign in as an employee and open a colleague's record: the API refuses |
| Identity | Self-hosted Keycloak, OpenID Connect, audience-checked tokens, lockout after repeated failures | The realm configuration file and the sign-in flow |
| Agent limits | Per-domain autonomy levels, a ten-person ceiling on unattended actions, three domains blocked from autopilot | Try to set performance reviews to autopilot: the change is rejected |
| Audit trail | One append-only log; update and delete revoked from the application's database role | The audit page and its CSV export, including the entry the export writes |
| Application hardening | Per-caller rate limits, security headers including a content security policy, containers running as non-root users | Response headers on any page or API call |
| Supply chain | Dependency audits for both apps and secret scanning over full git history, both blocking the build | The CI configuration, on request |
What stays inside Ascend, and what does not.
Document search, reranking, agent tracing and the voice used in role-play simulations all run on models and services Ascend hosts itself. Your documents are not sent to a hosted embedding or search service to be indexed.
The language model calls behind drafting, scoring and the assistant go to Anthropic, so the text those tasks need does leave Ascend's own services. We say so up front because it is the first question a data protection officer should ask.
Ascend is not yet hosted in a specific region. Everything it runs is packaged as containers, and where a pilot is hosted is agreed with each customer before any employee data is loaded.
What security and data protection teams ask.
- Where is our data stored?
- In your organization's partition of Ascend's Postgres database, isolated by row-level security. Ascend is not yet hosted in a fixed region: where a pilot runs is agreed with each customer before any employee data is loaded. Language model calls go to Anthropic.
- Who can see an employee's performance review?
- The employee's manager writes, approves and publishes it; the employee reads it once published and can attach a written response. Peer feedback reaches the manager, attributed, and is never shown to the employee. Admins open and close review cycles, and write a review only for someone who has no manager.
- Can an AI agent act on a person without a human?
- Not on performance reviews, succession or offboarding, which cannot be set to autopilot. Elsewhere the default is propose-only, anything touching more than ten people waits for confirmation, and every agent action is recorded against the person who asked.
- Do you hold SOC 2 or ISO 27001 certification?
- No. We would rather show you the controls on this page working in your pilot than point to a badge we do not have.
- How do we get the data processing agreement?
- Email [email protected] with your organization's name and the contact who should receive it. See the DPA page for how it is handled.
Related pages.
Bring one job role. We'll run the loop on it.
Thirty minutes, your own documents, one job role. You'll see the company brain built, the drafts it produces, the sources behind them, and where the autonomy dial sits before anything publishes.