Trust
Security
Encryption in transit and at rest with customer-managed keys, each customer's data kept separate in both the database and storage, Auth0 for authentication and hosting in AWS Sydney with backups in a separate Australian region.
This page describes the hosted Aicura service, the platform at aicura.app that Aicura runs for its customers.
Hosting
Aicura runs in AWS and has one hosting region today, in Australia. Every customer is served from it, wherever the customer is based. Application servers, database, object storage, workflow engine and embeddings all sit in ap-southeast-2 (Sydney). Model calls go through Amazon Bedrock's Australian cross-region inference, so each one runs in Sydney or ap-southeast-4 (Melbourne). Backups are written to a separate AWS region inside Australia, ap-southeast-4 (Melbourne), in a different AWS account locked down for backup-only use. Customer document content does not leave Australia in the normal course of operations.
Encryption
- In transit. All traffic over public networks uses TLS 1.2 or 1.3, and older versions are rejected at the load balancer. Inside the platform, connections to the database, to AWS APIs and to the workflow engine use TLS, and traffic between the load balancers and application servers stays on private, access-controlled networks.
- At rest. The database, object storage, secrets store and backup vault are all encrypted using customer-managed AWS KMS keys with automatic annual rotation. Keys are scoped per environment and per data class, and held in an AWS account separate from the application accounts. The most sensitive store, the Evidence Vault, has its own dedicated key.
Keeping each customer's data separate
Aicura is a multi-tenant platform, meaning many customer organisations (tenants) share the same service, and tenant boundaries are enforced in two independent layers.
- At the database. PostgreSQL row-level security. Every tenant-scoped table carries a tenant identifier, the role used by the tenant-facing API runs without permission to bypass row-level security, and the identifier is set at the start of every request transaction so any query that doesn't match it returns no rows. Cross-tenant access through the tenant API is not merely unintended, because the database refuses it.
- At the storage layer. For object storage, the tenant API does not use a broad credential. It assumes a narrowly-scoped role per request with a session policy that pins the credentials to a single tenant's storage prefix. A wrong tenant identifier anywhere in the code path is denied by AWS IAM, not by application logic.
What runs in your environment, and which way the connection goes
Aicura's enforcement and monitoring components are deployed and operated by the customer, not hosted by Aicura. The AI gateway, the input and output scanners and drift monitoring all run inside your environment and report to a Hub, a small service you also run that links your environment to Aicura.
The Hub calls into Aicura. Aicura never calls into you. Every connection between your environment and the Service is outbound from your network, which means you open no inbound firewall rule for Aicura, expose no endpoint to us and issue us no credentials that reach into your systems. If you disconnect the Hub, the link is closed from your side.
What travels on that link is guardrail bundles (the rules you publish) going out to your environment and results coming back, meaning what fired, under which rule and when. Your AI traffic does not travel on it. Prompts and responses passing through your gateway stay inside your own network boundary and never reach Aicura's infrastructure. What Aicura holds is the governance record described above.
Evidence nobody can change or delete
Snapshots of governance events are written to a dedicated Evidence Vault under AWS S3 Object Lock in compliance mode, so once written, a snapshot cannot be deleted or modified for its 10-year retention period by anyone, including Aicura. General document storage uses Object Lock in governance mode (7 years) with controlled deletion.
Authentication
User authentication is handled by Auth0 in an Australian tenant. Passwords never touch Aicura's servers. Auth0 handles password policy, session management, multi-factor authentication and password resets. MFA is enabled, enforced for administrative roles and prompted adaptively based on risk signals for others. Tenant and backoffice users live in separate identity connections, and neither can authenticate into the other's application. Aicura validates the JWTs Auth0 issues and authorises requests from the claims.
Access controls
Within a tenant, what each person can see and do is set by the roles they hold. A role grants read or write access to each area of the product, within what the plan includes, and can be narrowed to business units. A role is held through the identity provider group of the same name, or assigned by an administrator. A new tenant starts with one built-in Administrator role, which holds every permission the plan allows and cannot be edited or disabled, and the tenant always keeps at least one administrator. Every role change is captured as a snapshot in the Evidence Vault.
Operator access
Aicura operators access AWS through IAM Identity Center with federated SSO and multi-factor authentication. There is no standing administrative access, no long-lived database credentials and no public database endpoints, and by deliberate design no break-glass path to the production database at all. All administrative access is brokered through controlled, audited mechanisms. Changes operators make to your data are recorded in the audit log alongside changes you make yourself.
Security tooling
The platform runs under AWS's native security services, namely GuardDuty (threat detection), Inspector (vulnerability scanning of compute and container images), Security Hub (control monitoring), Config (drift detection) and CloudTrail (full account-level activity logging). CloudTrail logs are written to a dedicated audit account the application accounts can't write back to, with log-file validation enabled.
Audit trail
Two logs run alongside the product. A change log records create/update/patch/delete operations on tenant records (who, when, old/new values), written in the same database transaction as the change so the two can never disagree, and retained 7 years. An LLM call log records every AI call (function, provider, model, prompt, response, token counts, latency) and is retained up to 90 days, then deleted. Both are tenant-scoped. Authentication events from Auth0 are exported into a dedicated audit bucket under Object Lock (compliance) for 7 years, immutable to any account holder, including Aicura.
Backups and recovery
The database runs with point-in-time recovery and daily snapshots, copied cross-region from Sydney to Melbourne into a backup vault under a compliance-mode vault lock, with a minimum retention of 90 days. The Melbourne copies are kept for up to 7 years. Object storage uses versioning, Object Lock, cross-region replication to the Melbourne backup account and lifecycle rules for long-term storage tiers.
Certifications
Aicura is not ISO 27001 certified and has not been IRAP assessed, and we don't claim either. Infrastructure reviews produce a tracked list of improvements that we work through, rather than presenting the platform as finished.
Questions
Is Aicura ISO 27001 certified?
No. Aicura is not ISO 27001 certified and has not been IRAP assessed, and we don't claim either.
How is each customer's data kept separate?
Tenant boundaries are enforced in two independent layers. At the database, PostgreSQL row-level security refuses any query that doesn't match the tenant. At the storage layer, credentials are pinned to a single tenant's storage prefix, so a wrong tenant identifier is denied by AWS IAM.
Does Aicura need inbound access to our network?
No. The Hub you run calls into Aicura, and Aicura never calls into you. Every connection is outbound from your network, so you open no inbound firewall rule for Aicura and issue us no credentials that reach into your systems.
