Your Cloud Fallback Needs Its Own Permission

Self-hosting covers the model you installed; every alternative destination needs its own approval. A fallback is another route the software tries when the usual service cannot complete a request. It might use the same model elsewhere or a different provider entirely. Either change deserves a decision about what data that destination may receive.

The Decoder's report on Mistral Large 4 pairs coding comparisons with self-hosting and sovereignty claims. Mistral's announcement describes downloadable weights and deployment on an organization's own infrastructure. That gives buyers a local option. It doesn't establish where their agent will send context during an outage.

Our earlier self-hosting readiness check asks whether you can obtain and operate the actual release. This is the next examination: stop that working installation and watch the rest of the factory. The failure path needs to honor the same data restrictions as the ordinary path.

Approve which destination may receive which kind of information, for which job. Record the service, account and deployment location alongside the permitted data. A model name alone leaves too much unanswered. The same model reached through another service is another operating route.

Separate public documentation work from work carrying private repository contents. Include instructions, source files, tool results and conversation history when deciding what a request contains. If the next worker resumes a failed run, inspect what gets carried over. Calling the new request a retry doesn't make its contents public.

Gunner Technology recommends keeping this decision in policy the worker cannot edit. The person responsible for the data approves the destinations; the platform team turns that approval into an enforceable route. When a task's contents cannot be classified confidently, hold it for clarification. The agent's urgency to finish cannot fill that gap.

Enforce the restriction where requests leave the worker, with controls the worker cannot change. Egress means outbound network traffic. Restrict that traffic and require the request router to check the task's data permissions before forwarding context. A sentence in the agent's instructions cannot replace those controls.

For Kubernetes deployments, the NetworkPolicy documentation describes denying outbound traffic by default and allowing selected connections. Enforcement requires a supporting network plugin, and permissions from applicable policies combine. Check the effective configuration; adding a restrictive policy doesn't cancel another policy's broad allowance.

Follow allowed connections through to their destinations. An internal proxy that forwards requests elsewhere belongs in the same review. Give the worker only the credentials it needs, keep policy administration separate, and inspect tools and diagnostic reporting for other ways context could leave. As we argue in The Harness Is a Security Boundary, the machinery around the model needs its own controls.

Run a controlled outage exercise with synthetic data marked as private and observe the attempted destinations independently of the worker. Use a harmless marker in the test context so you can trace it without putting real source code at risk. Make the normal model unavailable, then exercise the actual retry and fallback configuration.

Test a connection failure, a timeout and an unusable model response. For each case, require either an approved alternative that completes the task or a recorded stop before context reaches an unapproved service. Also test work that is allowed to use the alternative. A broken network that blocks every job hasn't demonstrated correct routing.

Keep the configuration version, route decisions and network observations with the result. Don't rely on the agent's claim that it stayed local. Have a separate check trace the marker. If you couldn't observe a route, record that gap instead of claiming it was clear. Repeat the exercise when the router, credentials or fallback settings change.

When the approved routes are unavailable, save the task inside the permitted environment and send a concise escalation. Say which service failed, what work is waiting and which approved choices remain. Keep private context out of the notification itself. The person deciding should understand the consequence without receiving a copy of the repository in chat.

That person can choose to wait, restore the local service or authorize a suitable alternative through the existing approval process. Keep the decision tied to the affected data and destination. Permission to recover a service should never silently become permission to send every queued task to a new provider.

Start with a bounded queue in a repository you own. Rehearse its outage before relying on automatic recovery, and keep the exercise as a check on future configuration changes. People decide where their data may go. The factory should carry that decision through the moment when finishing the job gets difficult.