AttexaTrust Fabric · Deployment
amotivv · Attexa

Sovereign Deployment

For work that cannot leave infrastructure you control, amotivv runs agents on its own dedicated, hardware-isolated infrastructure, independent of any single model vendor, with the governance and evidence layer unchanged.

Dedicated, single-tenant infrastructure Model-independent Up to zero data egress
01 · What it is

The deployment layer for work that cannot leave your control.

Sovereign Deployment is where Attexa runs when control matters more than convenience: on infrastructure you choose, independent of any single model vendor, up to a fully closed-loop environment with no data egress at all.

It is the same agent platform and the same governance floor described elsewhere in this library, placed on a different footing. The orchestration, the policy boundary, and the customer-held evidence do not change. What changes is where the agents run and who holds the metal underneath them.

For the strictest requirements, amotivv operates its own dedicated, single-tenant, HIPAA-aligned infrastructure, so the answer to where does my data physically live and where do my models run can be an exact one rather than a description of a vendor's internal topology.


02 · Where it can run

You choose the custody model. The governance stays constant.

Your certified cloud

Inside contracts you already hold

Run in your own AWS, Google Cloud, or Azure account, on infrastructure your compliance program already covers. The governance and evidence layer sits on top of the trust boundary you operate every day.

Dedicated hardware

Single-tenant, physical custody

Run on dedicated, single-tenant infrastructure amotivv operates, where the exact physical infrastructure and the network path your data travels can be documented down to the physical layer.

Closed-loop enclave

No data egress at all

For the most sensitive workflows, a hardware-attested, closed-loop environment where your regulated data never leaves the boundary you approved.

These are points on one continuum, not separate products. A workload can start in your cloud and move toward dedicated hardware or an enclave as your requirements tighten, without changing the governance model or re-learning the platform.

03 · What stays identical, wherever it runs

The software guarantees travel with the workload.

These are enforced by the platform in software, so they are the same on your own cloud, on dedicated hardware, and in an enclave. If your reason for asking is governance and auditability, that reason is fully satisfied wherever you run.

Per-agent hardware isolation. Each agent runs in its own microVM with dropped-privilege isolation. A compromised agent lands in an empty jail, not on the host.
Default-deny networking. Each agent reaches only the destinations you allow, enforced at the host firewall, per agent.
Secrets stay out of the workload. Credentials are held by the control plane; the agent never sees them.
The governed action boundary. Consequential actions are checked against your policy before they run.
The Witness evidence layer. Every consequential action produces signed, independently verifiable evidence, co-signed by a node you hold.
Customer-chosen inference. The model path is yours to approve, up to a fully closed-loop model with no egress.
Encryption of data volumes and snapshots. The platform's stored data is encrypted at rest.
The same audit story. Portable, verifiable evidence that does not depend on who owns the metal.

The action governance, the evidence chain, and the customer-held witness node do not depend on who owns the metal. They are the same on a managed cloud instance and on dedicated hardware.


04 · What changes off dedicated hardware

Be clear-eyed: only the physical-custody guarantees shift.

Dedicated hardware gives a set of physical-custody guarantees that a managed cloud instance moves to your cloud provider. The platform's software guarantees above are unaffected. The custody guarantees shift as follows.

GuaranteeDedicated hardwareManaged cloud instance
Physical custody of the disk and mediaamotivv or you, directlyYour cloud provider
The host hypervisor and host kernelControlled by amotivvControlled by your cloud provider
Physical and environmental securityThe datacenter under amotivv's agreementYour cloud provider's certified facilities
Tenancy at the hardware layerSingle tenantShared, unless you select a dedicated or bare-metal tier
"Show the exact rack and draw the physical network"AvailableReplaced by your provider's region and attestation evidence

The practical reading: on a managed cloud instance, the answer to where is my data physically becomes "in your cloud provider's region, under the SOC 2, ISO, and HIPAA attestations you already accept from them," rather than "on this specific machine." For most enterprises already running regulated workloads on a major cloud, that is the same trust boundary they operate under every day, with the governance and evidence layer added on top.

If your requirements call for physical custody, single tenancy at the hardware layer, or zero data egress, dedicated hardware or a closed-loop enclave remains available. You choose the custody model; the governance model stays constant.


05 · Model independence

No dependence on a single model vendor. Enforced, not assumed.

The inference path is chosen by you and enforced by the platform, rather than left to the agent. The range runs from a provider already covered by your own agreements to a fully closed-loop model with no egress.

Choose per workload

Approve the model for each workload independently. A general task can use one provider; a sensitive one can use another, or none that leaves your boundary at all.

Up to fully closed-loop

At the strictest setting, a model hosted in a hardware-attested enclave with no data egress. Your regulated data reaches only the providers you decide it can, if any.


The data path stops being a paragraph of marketing language. It becomes a picture you can hand to an auditor: where the data sits, where the models run, and what each agent did, all provable.

Sovereign Deployment is the footing beneath the platform for the workloads no one will hand over. Same orchestration, same governed action boundary, same customer-co-signed evidence, placed on infrastructure and models your requirements decide.

You choose the custody. The governance does not move.