Security and data flow

This page is for the security reviewer. It says where a request goes, what is kept and where, which controls exist today, and which do not exist yet. Section references such as "platform spec §6.3" point to TerraFlow's design specification, which Altius can share on request.

The boundary, stated plainly

The preview is not inside your boundary. It runs on one server in AWS ap-south-1 (Mumbai), operated by Altius. Your prompts and the answers to them are sent to Anthropic, Microsoft Azure OpenAI and Google under Altius's provider accounts and terms. Use synthetic or public data only. TerraFlow's own promise, that your data never leaves your boundary, holds only in a Pilot installed inside it, with your models, your keys and your identity provider. Real customer data belongs only there.

How a request flows

Your code (OpenAI or Anthropic SDK)
   |  HTTPS to your workspace's own host
   v
Edge (Caddy): TLS; only /v1, /api and /console are forwarded; security headers;
   |          per-IP rate limits; 2 MB body cap; client IP logged for 14 days
   v
Your workspace's TerraFlow plane (its own container, database, cache and keys)
   |  1 identify the key, the workload and its contract
   |  2 classify the data: declared class, then a scan of everything a model would receive
   |  3 Cedar policy over every model: which may receive this request?
   |  4 cache, then choose a permitted model and its fallbacks
   |  5 reserve budget; the spend guard reserves the call's worst-case cost
   |  6 call the model                                   ---> provider (prompt leaves the server)
   |  7 check the answer; settle cost; append evidence   <--- answer
   v
Response with x-terraflow-* headers; evidence in your workspace's ledger

A request that is refused at steps 1 to 5 never reaches a provider. Every outcome, refused or answered, is recorded in the evidence ledger, and the routing decision is committed to it before any model is called.

Where data is held

Controls that exist

The spend guard

Every call to a paid provider, including health probes, cache verification, shadow comparisons and quality checks, first reserves its worst-case cost with a spend guard that runs outside the workspaces. A call is made only if it fits the workspace's lifetime allowance ($5), the preview's monthly ceiling ($100 across all workspaces) and the workspace's provider calls per minute. If the guard cannot answer within 250 milliseconds the call is refused (SPEND_GUARD_UNAVAILABLE, fail closed). No setting in a workspace can raise these limits.

Known limit, stated in full. Each workspace reaches the guard with its own credentials. Redis's access control confines it to its own counters, plus adding to (never setting or deleting) the shared monthly counter, but Redis checks every command the guard runs against the caller's own rights, so a workspace must itself be able to write those counters. Access control alone therefore cannot confine a compromised plane. A workspace plane taken over by an attacker able to run code could:

• falsify its own counters, and so lift its own allowance;
• add to the shared monthly counter, and so push the whole preview to its ceiling for everyone;
• fill the guard's memory, or slow it, with its own reservation records. The guard never evicts data (an evicted counter would silently reset spend), so when its memory is full every workspace's paid calls fail closed with SPEND_GUARD_UNAVAILABLE.

Prospects have no path to run code in a plane. A check of the monthly counter against the workspaces' shares finds bookkeeping faults, not a compromised plane, which can move both together. The backstops are outside TerraFlow, and they are not all hard stops:

and the operator's monthly check of the provider bills. A broker that alone may write the counters is planned for Phase 5.

What is shared

Workspaces are separate TerraFlow planes, but they share:

• the server, its Docker daemon and its operating system;
• one PostgreSQL server, with a separate database and login role per workspace;
• the spend-guard Redis, with a separate access-controlled user per workspace;
• the on-server embedding model (Ollama);
• the edge (Caddy) and its access log;
• Altius's provider accounts and keys, and so the providers' rate limits and account-scoped prompt caches. Because of those caches, confidential data is kept off every external model.

Residual risk: the shared provider prompt cache. Every external model in the preview is marked as sharing its provider's prompt cache across all workspaces, because the cache belongs to Altius's provider account, not to your workspace. Providers cache long prompt prefixes on their own (Azure OpenAI does so automatically for prompts of 1,024 tokens or more), and TerraFlow passes the provider's cached-token count back in the usage it returns (cached_tokens, cache_read_input_tokens) and records it in the evidence. So a prospect who sends a long prompt can tell, from the response time or from that count, whether someone, possibly another prospect, sent the same prefix shortly before. It does not reveal the other prompt's text or who sent it, and the preview bills every cached token at the full input price. This is one more reason the preview is for synthetic or public data only; in a Pilot the provider accounts, and so their caches, are your own.

Controls that do not exist yet

TerraFlow holds no security certification, and this preview is not production software.