Part 3 of 3 · Own
The Autessa Private Cloud keeps your apps, data, and AI in one governed environment.
Everything Autessa builds runs in one environment with one access model and one audit trail. You own your applications, data, and model inside it. You choose the deployment model and where inference runs, and your data stays contained by default.
Deployment models
There are two ways to deploy, and both share one audited control base.
Both models run on AWS in US regions and rest on the same SOC 2 and ISO-audited controls. They differ in how isolation is enforced and in who can own the account.
Shared environment, private tenant
This is the default model. Customers share infrastructure, but each tenant sits inside a private, cryptographically separated boundary: its own tables, tenant-ID scoping, and a per-tenant encryption key. Private here means per-tenant encryption and logical isolation, and this is the configuration covered by the SOC 2 Type II examination.
Dedicated AWS account
The whole stack is provisioned in one AWS account dedicated to you, raising isolation from logical to account level. The account can be Autessa-owned or customer-owned, in your chosen AWS region, with Autessa managing and operating it either way. It inherits the audited baseline controls.
Customer-held keys are available on both deployment models.
Where your data goes
Your data stays inside the boundary unless you choose otherwise.
Customer data stays inside the Autessa VPC at every stage of processing. There is one exception: if you choose an external model for inference, data leaves to that chosen provider. With the private model or the fine-tuned private model, inference runs inside the boundary and your data never reaches a third party at all.
Contained by default
With a private or fine-tuned private model, inference happens inside the VPC and customer data never reaches any third party.
You hold the key
With Customer-Controlled Key Encryption, your key is required before a model can decrypt data for inference. Withdraw it and inference stops, without disrupting ordinary operations.
External model safeguards
If you do use an external model, the provider is bound by zero-retention and no-training terms, and you can apply automated pre-egress PII redaction.
Audited and attributable
Every agent action is recorded to an audit trail, so you can reconstruct what happened, when, and on whose authority.
Model execution
You choose where model inference runs.
By default every environment includes a private model trained on your data alone, running inside your boundary. The other options are available where your capability or cost needs call for them, each with the exposure profile shown.
Fine-tuned private model
Stays in boundaryA model tuned specifically for your business, running entirely inside your boundary.
Autessa fine-tunes on your own agents and the evaluation results they generate, so the model gets measurably better at your workflows over time. The fine-tuned artifact is treated as your data and destroyed on offboarding.
Private model
Stays in boundaryA dedicated model that runs inside your boundary out of the box.
Trained on your data alone and never pooled with anyone else. Inference happens inside the Autessa VPC, so prompts and data never reach a third party. This is the default in every environment.
External model with your own API key
You own the relationshipAn external foundation model, called under your own provider credentials.
You bring your own API key, so the data relationship is one you own and audit directly with the provider. Autessa routes the call, but the account, terms, and logs are yours.
External model (standard)
Plaintext egressAn external foundation-model API for maximum capability and lowest cost.
Prompts leave the boundary to the provider under zero-retention and no-training terms. This gives you the frontier models when a workload needs them, with contractual protections in place.
Automated pre-egress PII redaction strips sensitive fields before anything leaves the boundary, so you can use an external model while keeping regulated data in.
Data governance
The database controls who sees what, down to the field.
The same database that powers your apps enforces governance at the point where the data is stored. Sensitive values stay protected even from users with database access, and access is scoped to the individual field, not just the table.
Field-level access control
Specify which users or roles can view, query, or modify each column, so a support agent can search by customer ID without ever seeing the underlying SSN or payment details.
Masked columns
Masked columns go beyond encryption. Values can be stored and searched without being read or viewed directly, even by users with database access, which supports identity matching and compliance workflows.
Per-tenant encryption
Every tenant table is encrypted with AES-256 under a distinct per-tenant key, so no single application key spans tenants.
Audited on every action
Reads, writes, and access changes are recorded to the audit trail, so you can reconstruct who touched what, and when.
The unified database is part of the AI Native Runtime. See the database on the Runtime page.
See how your data stays contained.
Book a walkthrough of the deployment models, encryption, and egress controls for your requirements.
Encryption and key custody
Data is encrypted twice at rest, and you can hold the key that gates model access.
Data at rest is protected by two independent encryption steps, so compromising one does not expose your data. On top of that, you can optionally hold the key that decides whether a model is ever allowed to decrypt your data.
Two keys, per tenant
Applied automatically to every environment, with no configuration required.
Customer-Controlled Key Encryption
Added on top of the default. You hold a key that wraps the per-tenant derived key.
FAQ
Questions about deployment, encryption, and the model
What is the Autessa Private Cloud, and how does it fit into Autessa?+
Autessa is AI infrastructure for the enterprise: one platform to build AI agents and apps, run them in production, and keep data and models in your control. The Private Cloud is the third part of that platform, the environment where everything you build lives. In its default form it is Autessa's multi-tenant deployment model and the audited baseline. Customers share infrastructure, but private means each tenant sits in a cryptographically separated boundary created by per-tenant encryption and logical isolation. Autessa operates the environment, and you own your applications, data, and model within it.
What deployment options are there?+
Two. The shared environment with a private tenant is the default, with per-tenant encryption and logical isolation, and it is the SOC 2-audited baseline. The dedicated AWS account provisions the whole stack in an account reserved for you, raising isolation to the account level. That account can be Autessa-owned or customer-owned, in your chosen region, with Autessa managing and operating it either way. Customer-held keys are available on both.
How is our data isolated from other customers?+
Two reinforcing levels. Cryptographically, each tenant's data is encrypted under its own derived key, so no single application key spans tenants. Structurally, each tenant has its own tables in the shared PostgreSQL cluster, and queries are scoped by tenant identifier. Choosing a dedicated AWS account raises this from logical isolation to account-level isolation.
How is data encrypted, and can we hold our own key?+
Data at rest is encrypted twice: AWS KMS encrypts the underlying storage, and above that a key-derivation function produces a per-tenant key that encrypts table data with AES-256. Data in transit uses TLS 1.2 or higher everywhere. You can also add Customer-Controlled Key Encryption, where your key wraps the per-tenant key and is required before a model can decrypt data for inference. Withdraw it and inference stops, with no disruption to ordinary reads and writes.
Does our data ever leave the boundary or train shared models?+
By default, no. Your private model is trained on your data alone and runs inside the boundary, so inference data never reaches a third party. Data leaves only if you choose an external model, and only to that provider. When that happens, the provider is bound by zero-retention and no-training terms, and you can apply automated pre-egress PII redaction.
What compliance and certifications back this up?+
Three independent attestations: ISO/IEC 27001:2022, ISO/IEC 42001:2023 (an AI-management-system certification few vendors hold), and SOC 2 Type II for Security, Availability, and Confidentiality. Autessa also signs Business Associate Agreements for HIPAA, aligns to GDPR as a data processor, and maps its controls to the NIST SP 800-53 Rev. 5 Moderate baseline. The platform is hosted on AWS in US regions.
What owning it means