01 · One door out
Every model call leaves through the same engine.
The assistant has many agents but a single path to a language model.
Each call carries a label naming the kind of work
(review_mr, analyse_manifest,
chart_upgrade…), and that label decides which profile,
and so which endpoint, it goes to.
A test suite pins that door: a new place in the code that talks to a
model provider directly fails the build until it is classified.
02 · Classify what is in the prompt
Redact, pseudonymise, or pass. Decided by rules, not by a model.
Before anything leaves, the prompt is sorted into data classes by a
deterministic rule pack. No model classifies it, because the payload
would have to leave first.
- Redact: secret material, by a separate, older secret scrub on the paths that can carry it, backed by a fail-closed check on every write to your forge.
- Pseudonymise: your company and project names, public hostnames, private IP addresses, email addresses, cluster ids, Vault mount paths.
- Pass: Kubernetes kinds and label keys, public chart and image names,
cluster.local, upstream documentation hosts.
03 · Where is it going?
Destinations are declared, never inferred.
Every profile is declared in config as one of three destination
classes. A self-hosted box you run is local controlled: no
third party sees the data. A provider you have accepted for masked
payloads is approved remote, whether it is a regional provider
or a frontier model. Anything not declared is denied.
The endpoint URL is not trusted as evidence. A profile missing from
the declaration is refused, not guessed.
04 · What does the tenant require? In development
Each tenant states its own floor.
A tenant's egress requirement is one of any,
pseudonymised or local_only. The checks
are built. Until every call carries reliable tenant provenance, a
shared engine applies the strictest requirement configured to every
call, so one cautious tenant raises the floor for all.
pseudonymised lets a call reach an approved remote
provider only as a validated masked envelope. local_only
keeps it on your own hardware.
05 · Mask the identifiers
Same shape, obviously fake, consistent within the request.
Each identifier becomes an alias that keeps its grammar: a hostname
stays a valid hostname under the reserved .invalid
domain, a private address becomes a documentation-range address with
the same prefix width. The same value always gets the same alias, so
the model can still reason about "this host talks to that host".
There is no stored table of real names and aliases. The mapping is
rebuilt per request from what is actually in it.
06 · Restore on the way back
The answer comes back in your terms, or not at all.
Aliases in the reply are swapped back to the real values before any
other code sees them. An alias that cannot be restored, or one that
would end up in a file, an MR or a tool argument, rejects the reply
instead of leaking a fake name into your repo.
A model is only allowed on a masked lane after a paired run proves
its replies restore cleanly. The evidence is bound to that exact
provider, endpoint and model.
07 · When the only allowed endpoint is down In development
It stops and asks. It does not quietly go elsewhere.
Profiles can fall back to another tier when an endpoint fails. Every
fallback is checked again against the policy of the tier it lands on.
There is no automatic reroute to a different residency.
If a local_only tenant's box is down, the engine enters
a named HALT state and waits for a person. Losing a night of
work is the designed cost; sending that tenant's data to a cloud
model is not an option.
08 · Mix and match
Route each class of problem to the model that suits it.
A profile maps call labels to endpoints. Bulk, high-volume
work goes to a small, cheap model. Careful generation of a diff goes
to a stronger one. The review of the finished MR goes to a
different family again, so it is not marking its own homework.
Unmapped labels fall through to the profile's default. A mapping
that names a profile which does not exist is reported at startup.