Environments

One estate, several environments

Heliast treats every place a model can run as an execution environment, and applies the same admission and the same ledger to all of them. There are four classes:

A hosted provider is one more environment, not a special case. A call to one still passes identity, the admission join, your policy and the ledger. Nothing bypasses the enforcement hook.

Hosted providers are off by default

With no provider configured, your deployment behaves as it would with none: the only outbound destination is your identity provider. To use a provider you add one configuration object for it, in your own Git beside your Rego policy. Each object carries:

• name and base_url (https only);
• credential_ref, a reference to a secret in your secret store (secret://, vault:// or k8s://). An inline key is refused. The credential stays on the server and never reaches users;
• models, each mapping a served_model (the name the provider's API uses) to an admitted_model_id and a host_record_id;
• enabled, per_workload and data_classes;
• egress_allowlist_entry, with name, url, cidr and port. A CIDR of 0.0.0.0/0 is refused.

A provider is reachable only when all of these hold:

1. it is configured and enabled;
2. the asking workload is in per_workload;
3. the request's data class is in data_classes;
4. the model maps to an admitted record;
5. the host record for that model is admitted and has not gone stale.

An empty per_workload or data_classes list means nothing is permitted. Data class restricted may never leave the local environment under the reference policy.

The configuration has no field for rate limits or budgets.

The egress allow-list

The env-check tool reads your provider configuration and generates the egress allow-list from it: one entry for your identity provider, plus one entry per enabled provider. A disabled provider adds nothing. Removing a provider removes its entry. Run it like this:

env-check verify -instances <instances.json> -providers <dir>

It prints the number of providers and enabled providers, and the resulting count of allow-list entries. An absent or empty directory means no providers.

Host records and verdicts

Admitting the weights is one check. Admitting where they are served is a second. A host record is the second check: one record per provider and model, stating what the host claims about the weights it serves, where prompts and outputs go and who may keep them, what obligations flow down from the model licence, and a verdict with the reason.

A host record can be admitted only if the model it names is itself admitted. A missing, held or stale record all produce one result: the route is refused, with the reason written to the ledger.

Held and rejected records are kept with the other holds, and admitted ones with the host records.

Why a hosted route is never labelled verified

Heliast can byte-check weights it holds. It cannot do that on someone else's server. So every hosted route carries this label on its host record:

provenance by host attestation, not verified

The label records that the provider says it serves the model, and that we have not checked it. A hosted record cannot carry the label verified, and its concluded fidelity cannot be an exact checkpoint. Where the host says nothing about how it serves the model, the record says so as "not stated". Nothing is filled in by inference.

What the console shows

Each model's page in the console has a "Where it can run" section. It lists local, private cloud, and every named provider that has a host record, and for each one shows:

• available or unavailable;
• the host verdict, and a note when the record is stale, with its review date;
• the reason, as written on the record;
• the provenance label, where it differs from the others.

A model that is not admitted shows nothing as available. A model with no host record in an environment shows that environment as unavailable, with the reason that a missing, stale or held record fails closed.

Limits and what this does not cover

• The hosted-provider rules in the reference policy have been tested against fixtures. They have not run in a real estate, and the hook sending the environment and provider configuration to the policy on live requests is not confirmed. Confirm the current state with your Heliast contact before relying on them.
• The count of environments that env-check prints is a count of configured records. It is not proof that an environment is deployed.
• Host records are evidence of what a provider has published as of a capture date. They are not a guarantee of how the provider behaves.