Astryastry

Nothing leaves without passing the guard.

An egress guard checks every outbound model and embeddings call against a host allowlist you control. Pin inference to EU-only hosts, or run fully local and air-gapped through Ollama. A call to a host you did not approve fails hard, never silently.

Every call is checked before it leaves.

The guard sits on the request path. It reads the destination of each outbound model and embeddings call and compares it to your host allowlist. Anything off the list does not go.

EU-only hosts

Pin routing to an allowlist of EU hosts. Every model and embeddings call is checked against that list before it leaves the boundary.

On the request path

The guard runs on each outbound call, not as a setting that gets read once. There is no path to a model that skips the check.

Fails hard, never silently

A call to a host you did not approve is not quietly dropped or rerouted to another provider. It fails loudly, so a misconfiguration surfaces at once.

Fully local, air-gapped

Loopback, Ollama and internal hosts are always allowed. Switch external routing off and run inference on your own hardware, with nothing leaving the network.

Nothing held on our side

Astry runs in your own cloud under BYOC and holds no credentials to it. The control plane sees only operational metadata, never your content or conversations.

Egress you can prove

Every query, resource, action, latency and cost is written to an append-only log, so you can show exactly which hosts a request reached.
See the audit log

One switch per boundary.

Egress is a workspace setting, not a support ticket. Each control is explicit and independent.

Egress guard
Host allowlist checked on every outbound model and embeddings call.
Off-list calls
Fail hard; never silently dropped or rerouted.
In-VM routes
Loopback, Ollama and internal hosts always allowed.
EU-only inference
Pin routing to an allowlist of EU hosts.
Local inference
Ollama, on your own hardware, air-gapped.
Default state
Off until you enable it, per workspace.
Data region
Compute, storage and KMS in the region you choose.

Residency you can put in a contract.

For a regulated EU team, where the model reads your data is not a preference. It is a clause your auditors and regulators check.

Most assistants route prompts to whichever model is cheapest that minute, often across the Atlantic, with no check on where the request lands. That breaks the moment a supervisor asks where regulated data was processed.

Astry inverts the default. Every model and embeddings call passes an egress guard that checks the destination against a host allowlist you control. A call to a host you did not approve fails hard, in the open, instead of slipping through. When even that is not enough, you switch external routing off and run the model locally, with nothing leaving the network at all.

Good to know.

  • Yes. Pin routing to an allowlist of EU hosts. Every outbound model and embeddings call is checked against that list before it leaves, so a request never reaches a host you did not approve.

Keep it in the region.

See how teams under EU rules pin inference, prove egress, and keep the model on their own ground.