Trust and security

Built for several companies on one platform. Designed so none of them can see each other.

Everything below is a control that exists in the product today. We would rather show you the mechanism than a badge.

Tenant isolation at the query layer

Every tenant table carries an organisation ID. A global scope applied through a shared model trait filters every query automatically, and route-model binding resolves other organisations' records as not found. Cross-organisation isolation is covered by automated tests.

Organisation scope on every model
Cross-org reads, updates and deletes resolve as 404
Super-admin and partner access are explicit, separate paths

Audit trails everywhere

Requests, approvals, assignments, admin actions, partner actions, workflow steps and every connector query are written to audit logs. A unified audit log lets admins filter by actor, department and action.

Request, approval and assignment audits
Super-admin and platform-staff audits
Connector query audit with snapshots

Retention you control

A Data Retention Engine with a deny-by-default registry: a table that is not registered can never be purged, and registered tables carry a class (permanent, audit, operational, cache, temporary). Platform defaults can be overridden per tenant, and tenants can read their own policy inside the product.

Registry of about fifty governed tables
Per-tenant overrides
Tenant-facing retention awareness page

Secrets, keys and signatures

Integration secrets and AI keys are stored encrypted with a rotation command. Inbound webhooks are HMAC-verified with nonces and replay protection; outbound webhooks are signed. Rate limits protect public and integration endpoints.

Encrypted secrets with key rotation
HMAC-signed webhooks, replay protection
Rate limiting on public and API routes

Read-only connectors with an egress guard

Client Data Connect only ever reads. Queries are validated against templates, blocked by an egress guard if they are not permitted lookups, and every query is logged. A go-live checklist and a DPA template ship with the feature.

MySQL and HTTP drivers, read-only
Query validation and templates
Go-live checklist and DPA template

Access, roles and sessions

Granular staff permissions, platform permissions for internal staff, email verification and password reset for every user type, and audited impersonation for support cases. Confidential requests can be limited to a named viewer list.

Granular staff and platform permissions
Email verification for staff, clients and partners
Audited impersonation

AI and your data

The AI is advisory, and the keys can be yours.

Each organisation can bring its own API keys for Anthropic, OpenAI, Google Gemini or xAI Grok, so requests to a model provider run under your account and your terms. Usage caps and a circuit breaker limit cost and failure. Every AI feature has an organisation-level switch, and the customer brief is built only from verified facts in the record.

Published documents

Documents are versioned in the product's Legal CMS; acceptance is tracked per user. Questions: support@aurdesk.com.

Questions, answered

Security questions we get asked

On AWS infrastructure operated by us; inbound email runs through AWS SES in the Mumbai (ap-south-1) region. Attachments are stored in S3. Ask us for the current infrastructure note for your due-diligence file.

Yes. Retention policies govern routine purging, and on exit we remove your organisation's data on request under the data processing agreement.

Not today. We publish the mechanisms above instead of claiming a certification we do not hold, and we will share our security overview and answer questionnaires.

Platform staff with explicit platform permissions, through audited paths (including impersonation, which is logged). Access is limited to support and operations needs.

Have a security questionnaire?

Send it over. We answer with the actual mechanism, and we will walk your IT team through the product.

Book a demo Try the interactive tour