Hybrid Agentic Work: Self-Hosted and Cloud Models for Sensitive Information

This chapter applies the hybrid patterns of Chapter 14 where they are hardest to hold: agentic work tools on the desks of engineers, analysts, and operators. A coding or task agent, Mode 3 in Chapter 2's terms, reads files, runs commands, and sends everything it gathers to a model. It works best with a cloud frontier model, yet much valuable work must not leave the organisation's control. The chapter shows how a provider-neutral agent, with OpenCode as the worked example, lets one workflow use a self-hosted model for sensitive information and a cloud model for the rest, and what must surround it for that routing to be a control rather than a hope. Chapters 11 and 19 supply bounded autonomy and containment; this chapter adds which model may see which information.

One workflow, two model tiers

The hybrid pattern keeps everything except the model constant: the agent definitions, skills, and MCP servers of Chapter 8 are the same in every workspace, while public and internal work uses a cloud frontier model and confidential and protected work a self-hosted open-weight model.

The decisive fact is what the model sees. An agent sends whatever context it gathers to the selected model: file contents, command output, test logs, MCP tool results, and its own earlier turns. Sensitive information disclosure through that context is the second risk in the OWASP list (27, OWASP, 2025). Once a session against a cloud model has read a protected file, the disclosure has happened; switching model halfway does not recall it, and a compacted history carries it forward. Routing must therefore be decided before the session starts, by the classification of the workspace, never per prompt.

Class Examples Permitted model tier Workspace
Public Open-source code, published documents Cloud or self-hosted Standard workstation
Internal Internal tools, non-sensitive configuration Cloud with EU region and no training use, or self-hosted Standard workstation
Confidential Business logic, customer data in test sets, infrastructure code Self-hosted, or a cloud service that has passed the controls guide for this class Managed development environment
Protected Personal data under Article 9 of the GDPR (2, European Union, 2016), security-protected information, trade secrets Self-hosted in an isolated zone only Separate environment without internet egress

Classification-routed hybrid agentic work: the workspace fixes the classification, and the AI gateway routes model traffic to a cloud model, a restricted-zone model or an isolated enclave

Figure 15.1: The workspace fixes the classification before the session starts; all model traffic passes the AI gateway, which permits the cloud tier only for public and internal workspaces and sends protected work to an isolated self-hosted model. Direct egress from the agent is blocked.

The confidential row admits a cloud service that has passed Chapter 14's controls guide, a legitimate choice for code that is commercially sensitive but holds no personal data. The protected row admits no such exception, because special-category rules, security-classification rules, and trade-secret protection are not satisfied by contract terms alone.

OpenCode and sensitive information

OpenCode makes the pattern concrete; the controls apply to any agent that accepts an OpenAI-compatible endpoint and a centrally managed configuration.

What OpenCode is

OpenCode describes itself as an open-source AI coding agent, available as a terminal interface, desktop application, or IDE extension (218, OpenCode, 2026), and its repository is published under the MIT licence (226, Anomaly, 2025). It supports more than 75 providers and runs local models through any OpenAI-compatible endpoint, configured as a custom provider with the @ai-sdk/openai-compatible package, a baseURL, and a map of models with optional context limits; the documentation gives examples for Ollama, LM Studio, and llama.cpp (220, Anomaly, 2026). vLLM and Ollama both serve such an endpoint (227, vLLM, 2026) (228, Ollama, 2026).

Configuration files are JSON, merged from a remote organisational default through user and project files to managed files under /etc/opencode/ on Linux. The documentation states that managed settings "override everything" and that users cannot modify them without administrator rights. enabled_providers is an allowlist, disabled_providers takes priority over it, and the published schema offers share with the values manual, auto, and disabled and an experimental policy list that can deny provider.use (219, Anomaly, 2026). Agents carry their own model, prompt, and permissions (221, Anomaly, 2026), permissions take allow, ask, or deny per tool (222, Anomaly, 2026), and the documentation warns that MCP servers add to the context (223, Anomaly, 2026).

On data handling, the enterprise page states that OpenCode "does not store any of your code or context data" and recommends disabling share pages (224, Anomaly, 2026). The privacy policy for the vendor's hosted services lists prompts as passed to the upstream provider and not stored, and mentions analytics providers (225, Anomaly, 2026). The documentation I read in November 2026 does not describe client telemetry either way, so verify actual network behaviour in the pilot.

Other provider-agnostic agents

The table lists open-source agents whose official documentation, read on 1 November 2026, describes both self-hosted and cloud models.

Tool Licence Self-hosted models Central configuration Provider and sharing controls
OpenCode MIT Any OpenAI-compatible endpoint (220, Anomaly, 2026) Remote default, administrator-only managed files (219, Anomaly, 2026) Provider allowlist and denylist; sharing can be disabled
Codex CLI Apache-2.0 Ollama or LM Studio; custom providers (236, OpenAI, 2026) Enforced requirements and managed defaults (237, OpenAI, 2026) No provider allowlist found
Cline Apache-2.0 Ollama, LM Studio, OpenAI-compatible (231, Cline, 2026) From the vendor's hosted admin console (230, Cline, 2026) Administrator-set providers
Continue Apache-2.0 Custom base URL; LiteLLM (232, Continue, 2026) None found None found
Goose Apache-2.0 Ollama, LM Studio, LiteLLM (234, Goose, 2026) None found Extension allowlist; telemetry off by default
Aider Apache-2.0 Through the LiteLLM library (233, Aider, 2026) None found Analytics opt-in
Crush FSL-1.1-MIT, source-available Ollama, llama.cpp, LiteLLM (235, Charmbracelet, 2026) Project and global files only Metrics can be disabled

OpenCode serves as the example because it is the most established of the provider-neutral open-source alternatives: among the tools in the table whose design treats every model provider alike, rather than starting from one vendor's models, it is the most-starred and most-forked repository, with about 224,000 stars and 30,000 forks on 1 November 2026 (226, Anomaly, 2025). It also combines a permissive licence with a documented managed configuration that includes a provider allowlist and a sharing switch. The claim is deliberately bounded. Codex CLI is open source and can run open-weight models locally, but it is built around one vendor's models, so it is not counted among the provider-neutral tools, and on other measures it leads: the Codex CLI package recorded about 95 million npm downloads in the month to 29 October 2026, against about 14 million for OpenCode's (238, npm, 2026), and it has the fuller enforced-policy model. The choice of example is not a recommendation; any of these tools should pass the supplier evaluation of AI Governance, Chapter 7, and a tool without central configuration needs every control in the workspace image and the network.

Routing by information class and jurisdiction

For a multinational group, a workspace carries two labels set before the session starts: the information class and the owning entity, from which the jurisdiction follows. For a subsidiary in the United Kingdom or Switzerland, reaching a model in the Union, or one whose provider is subject to a third country's law, raises the transfer analysis of Chapter 13 under that entity's own law. Model origin is a third input: the origin policy of AI Governance, Chapter 6 decides which providers and open-weight families may serve each class at all, and it applies to self-hosted weights as much as to the cloud tier.

Label the work, not the user, default unlabelled work to confidential, and bind labels to the source-control platform and workspace identity, so that the gateway never trusts what the client asserts.

Enforcement sits outside the client

A client setting is a convenience, not a control, because a user can install another client or paste a cloud API key into an environment variable. Deny direct egress from agent workspaces and allow model traffic only to the AI gateway, which accepts a request only when the workspace identity may reach the requested model, so that a protected workspace asking for a cloud model is refused and logged. Separate environments per classification, give a protected workspace no cloud credentials at all, and let the managed configuration make the compliant path the easy one, with MCP servers limited to the catalogue following the MCP security guidance on token handling and scope minimisation (229, MCP, 2025).

Routing decides which model may receive a workspace's context; containment (Chapter 19) decides what the agent may do inside it. Neither substitutes for the other, so both are enforced by the platform and tested by attempting the forbidden action.

Capability gaps and evaluation

Tool calling is the usual weak point of self-hosted models: a model that writes good code may still emit malformed tool calls or stop early, and OpenCode's own advice for Ollama is to raise the context window to 16,000 to 32,000 tokens when tool calls fail (220, Anomaly, 2026).

Before relying on a local model, run a task suite built from real tickets in the protected repositories, as Chapter 20 describes, scoring well-formed tool calls, completion within the step budget, passing tests, and reviewer defects. The same suite against the cloud tier gives the baseline, and the gap is the honest cost of routing in capability. Where the local model falls short, restrict the protected workspace to planning and review agents rather than relaxing its routing.

Operating self-hosted models for agentic work

Beyond Chapter 14's readiness check, agentic use adds three demands.

Capacity follows context, not users. A session resends its growing history at each step, so context memory, not the number of engineers, limits concurrency. Size the tier from measured pilot sessions and queue sessions rather than truncating context, which produces malformed tool calls.

Model updates are frequent and must be gated. Treat the model as a pinned artefact in the release manifest of Chapter 8, replaced only after a canary run passes the suite. Serving-engine patches, however, follow the patch-velocity service levels of Chapter 18 and may ship with an abbreviated regression run.

Evaluation has a cadence, not a date. Run the suite on every model or serving change, a regression subset weekly, and the full comparison against the cloud tier each quarter, recording each run with the model digest as Chapter 20 requires.

These demands need a named model owner, evaluation owner, and on-call rota, in the AI platform team of AI Governance, Chapter 12; in a small authority that argues for keeping the protected tier narrow.

What the hybrid costs

The cloud tier is metered, and long agent sessions consume far more tokens per hour than a conversational assistant, so Chapter 22's quotas and spend limits apply. The self-hosted tier is capacity paid for whether used or not, with the utilisation penalty Chapter 14 quantified. The honest comparison is therefore not between token prices: for protected information the alternative is no agent at all, so price the tier as the cost of using agents on that work and judge it against the engineering time saved. Consolidating self-hosted workloads on shared capacity improves the economics.

Evidence, standards and origin

The gateway, not the client, produces the evidence: each session's workspace, user, model, token counts, and refused requests, retained under the rules of the evidence manifest that AI Governance, Chapter 11 describes. In the ISO/IEC 27001 terms used in Chapter 9, the pattern implements classification (5.12), information transfer (5.14), use of cloud services (5.23), configuration management (8.9), logging (8.15), and network security and segregation (8.20 and 8.22) (124, ISO/IEC, 2022) (125, ISO/IEC, 2022). Refused requests are the most informative evidence: one from a protected workspace towards a cloud route deserves a look within the day.

Putting it into practice

The guide and example assume the gateway of Chapter 12 and the managed development environments of Chapter 8. Adapt the thresholds to your own risk appetite and record the adaptation as a decision.

Practical guide: setting up a classification-routed hybrid agent environment

Purpose. Let staff use one agentic workflow across cloud and self-hosted models while guaranteeing that each information class reaches only the models permitted for it.

Roles. The information owner classifies repositories; the AI platform team runs the gateway, models, and managed configuration; the security architect owns egress; the AI governance board approves the routing table.

  1. Classify the work, not the user. Label every repository and data set public, internal, confidential, or protected, and refuse agent access to unlabelled ones. Default: unlabelled counts as confidential. In a multinational group, record the owning entity alongside the class.
  2. Fix the routing table as an AI Decision Record, applied through the model-origin policy of AI Governance, Chapter 6.
  3. Build one workspace image per tier, each with its managed agent configuration in the administrator-only directory and its own network policy. A repository can be cloned only into a workspace whose tier covers its class.
  4. Put the gateway in the path. Expose one OpenAI-compatible route per tier, authenticate workspaces with short-lived workload identity, and deny any route the table does not permit. Cloud API keys live only in the gateway.
  5. Close the side doors. Deny direct egress except to the gateway, the source-control host, and the package mirror; allow only catalogued MCP servers; disable sharing and web fetch in the protected tier.
  6. Evaluate the local model before go-live and after every upgrade. Default: at least 95 per cent valid tool calls and 70 per cent task completion; below that, offer planning and review agents only.
  7. Collect evidence. Log every request at the gateway, alert on refused requests from the protected tier, and check the managed configuration for drift daily.
  8. Treat unattended runs as Mode 5. Agents in CI or on schedules use the same images, with every ask permission turned into deny and the containment sandbox of Chapter 19.

Definition of done. Every repository has a class, every class has a workspace image, a test from each workspace shows that unpermitted models and direct egress are refused and logged, the local model has passed its evaluation, and the routing table is approved and dated.

Worked example: an OpenCode configuration for classification-routed hybrid work

Illustrative example. Hansa Mutual gives its engineers OpenCode in remote development environments on the group platform in Germany. Both providers are routes on Hansa's own gateway, so the client never holds a cloud key. The base file below is the standard image's managed configuration, checked against the published schema in November 2026; that a managed file cannot be overridden rests on the documentation, which Hansa's pilot must confirm.

// /etc/opencode/opencode.json - Hansa Mutual managed base, illustrative example
{
  "$schema": "https://opencode.ai/config.json",
  "share": "disabled",                       // no public session links
  "update": "notify",                        // platform team rolls out versions
  "enabled_providers": ["hansa-local", "hansa-cloud"],
  "provider": {
    "hansa-local": {                         // self-hosted vLLM, via the gateway
      "npm": "@ai-sdk/openai-compatible",
      "options": {
        "baseURL": "https://ai-gateway.hansa.internal/local/v1",
        "apiKey": "{env:HANSA_GATEWAY_TOKEN}"  // short-lived workload token
      },
      "models": { "code-32b": { "limit": { "context": 65536, "output": 8192 } } }
    },
    "hansa-cloud": {                         // cloud frontier model, via the gateway
      "npm": "@ai-sdk/openai-compatible",
      "options": {
        "baseURL": "https://ai-gateway.hansa.internal/cloud/v1",
        "apiKey": "{env:HANSA_GATEWAY_TOKEN}"
      },
      "models": { "frontier-eu": { "name": "Frontier model, EU region" } }
    }
  },
  "model": "hansa-cloud/frontier-eu",
  "permission": {
    "edit": "ask",
    "webfetch": "deny",
    "bash": { "*": "ask", "git status*": "allow", "curl *": "deny", "ssh *": "deny" }
  }
}

The protected image enables only hansa-local on a separate gateway host and disables hansa-cloud. The gateway and network policy, however, carry the control: even with a replaced client, the protected workspace has no route or credential for a cloud model.

# agent-routing-policy.yaml - Hansa Mutual, illustrative example
# Enforced by the AI gateway and the workspace network policy, not by the client.
apiVersion: ai-platform.example.org/v1
kind: AgentRoutingPolicy
metadata:
  name: classification-routed-agents
  owner: ai-platform
workspaces:                       # identity = workload certificate of the environment
  standard:     {classes: [public, internal]}
  confidential: {classes: [confidential], includes: [pl-claims-centre-data]}
  protected:    {classes: [protected], includes: [life-health-art9-data],
                 gateway: ai-gateway.protected.hansa.internal}
jurisdiction:
  entities: [de, nl, se, pl, no, uk, ch]
  cloud_route_requires_transfer_assessment: [uk, ch]
routes:
  /cloud/v1:
    upstream: approved-cloud-ai-services/frontier-eu
    allow_workspaces: [standard]
    require: [cloud_controls_passed, eu_region, training_use_off, zero_retention]
  /local/v1:
    upstream: group-platform-de/code-32b
    allow_workspaces: [standard, confidential, protected]
default: deny                     # unknown workspace or model is refused and logged
egress:
  protected: {allow: [ai-gateway.protected.hansa.internal, git.protected.hansa.internal]}
credentials:
  gateway_token: {issuer: workload-identity, ttl_minutes: 60, bound_to: workspace}
  cloud_api_keys: gateway-only    # never present in any workspace
evidence:
  per_request: [workspace, user, route, model, decision]
  refused_requests: alert-security-on-protected
  retain_days: 2555
evaluation:
  local_model_gate: {suite: agent-tasks-v3, min_task_completion: 0.70, min_tool_call_success: 0.95}

Across the usage modes

The hybrid pattern is a Mode 3 answer, but the same routing reaches neighbouring modes (usage-mode matrix).

Mode Does classification routing apply? What changes
Mode 0 – Ambient AI No Placement is the supplier's; govern through the contract
Mode 1 – Conversational assistants Partly A self-hosted chat service can take the protected class
Mode 2 – Embedded workplace assistants No Placement is fixed by the suite; sensitivity labels limit what it reads
Mode 3 – Agentic work tools Yes, fully Routing per workspace, enforced at the gateway
Mode 4 – Built AI applications Yes, per workload The placement policy of Chapter 14 decides the tier at design time
Mode 5 – Autonomous production agents Yes, per agent Same images and routing, every ask turned into deny, inside the containment of Chapter 19

Run unattended, in CI or on a schedule, the same agent becomes Mode 5: the line between the modes is not the tool but whether a person is present to answer a prompt.

Nordvik Region and Hansa Mutual

Nordvik Region limits agentic work tools to a small platform team. Public and internal work may use an approved cloud model, and anything above internal uses only a self-hosted code model on the platform that runs the case-note summariser. The constraint is people rather than hardware, so the Region keeps one pinned code model, upgrades it at most twice a year, and limits the protected workspace to planning and review agents until the model passes the gate.

Hansa Mutual routes by owning entity as well as by class, across seven jurisdictions. The self-hosted tier in Frankfurt carries confidential and protected work, including claims data from the Polish service centre and health data from the life and supplementary health lines, and UK and Swiss repositories default to it unless their transfer assessments permit otherwise. Hansa's scale makes the tier economic to share and justifies dedicated owners. Its risk is the reverse of Nordvik's: many teams, many repositories, and a routing table that must keep pace with reorganisations and new entities. Nordvik's hybrid is narrow by necessity; Hansa's is broad by design and needs the evidence to prove it holds.

Summary

Provider-neutral agentic work tools, with OpenCode as the worked example, extend the hybrid pattern of Chapter 14 to the desktop: the same workflow runs on a self-hosted model for confidential and protected information and on a cloud model for the rest. Because an agent sends whatever context it gathers to the model, routing is fixed per workspace before the session starts, by information class and, in a multinational group, by owning entity, never per prompt.

The gateway, egress control, separate workspaces, and credential scoping are the control, not the client's settings. A task suite from real work decides whether the protected tier offers full agents or planning and review only, and the tier is sized for context rather than users and judged against having no agent at all on protected work.

This chapter closes Part III. Part IV turns to securing what runs on the platform, beginning in Chapter 16 with the parts of an AI system that classical controls do not reach.

Sources

  1. OWASP Foundation. OWASP Top 10 for LLM Applications 2025. OWASP GenAI Security Project. (27, OWASP, 2025)
  2. European Parliament and Council of the European Union. Regulation (EU) 2016/679 on the protection of natural persons with regard to the processing of personal data (General Data Protection Regulation). Official Journal of the European Union, 4 May 2016. (2, European Union, 2016)
  3. OpenCode (2026). OpenCode documentation: Intro, with the linked Providers and Agents pages. Last updated 1 November 2026; repository licensed under MIT. (218, OpenCode, 2026)
  4. Anomaly (2025). opencode: The open source coding agent, LICENSE file (MIT License, copyright 2025 opencode). GitHub repository anomalyco/opencode, formerly sst/opencode. (226, Anomaly, 2025)
  5. Anomaly (2026). Providers. OpenCode documentation, read 1 November 2026. (220, Anomaly, 2026)
  6. vLLM project (2026). OpenAI-Compatible Server. vLLM documentation (latest), read 1 November 2026. (227, vLLM, 2026)
  7. Ollama (2026). OpenAI compatibility. Ollama documentation, read 1 November 2026. (228, Ollama, 2026)
  8. Anomaly (2026). Config, with the published configuration schema. OpenCode documentation, read 1 November 2026. (219, Anomaly, 2026)
  9. Anomaly (2026). Agents. OpenCode documentation, read 1 November 2026. (221, Anomaly, 2026)
  10. Anomaly (2026). Permissions. OpenCode documentation, read 1 November 2026. (222, Anomaly, 2026)
  11. Anomaly (2026). MCP servers. OpenCode documentation, read 1 November 2026. (223, Anomaly, 2026)
  12. Anomaly (2026). Enterprise. OpenCode documentation, read 1 November 2026. (224, Anomaly, 2026)
  13. Anomaly (2026). OpenCode Privacy Policy. Effective 6 March 2026. (225, Anomaly, 2026)
  14. OpenAI (2026). Advanced configuration (Codex CLI: open-source model providers and custom model providers). Codex documentation, read 1 November 2026. (236, OpenAI, 2026)
  15. OpenAI (2026). Managed configuration (Codex requirements and managed defaults). Codex documentation, read 1 November 2026. (237, OpenAI, 2026)
  16. Cline (2026). Local models and Ollama. Cline documentation, read 1 November 2026. (231, Cline, 2026)
  17. Cline (2026). Enterprise Provider Configuration (remote configuration). Cline documentation, read 1 November 2026. (230, Cline, 2026)
  18. Continue (2026). OpenAI model provider. Continue documentation, read 1 November 2026. (232, Continue, 2026)
  19. Goose (2026). Configure LLM Provider and Configuration files. goose documentation, Agentic AI Foundation, read 1 November 2026. (234, Goose, 2026)
  20. Aider (2026). Other LLMs and Ollama. Aider documentation, read 1 November 2026. (233, Aider, 2026)
  21. Charmbracelet (2026). Crush README and LICENSE (Functional Source License 1.1, MIT Future License). GitHub repository charmbracelet/crush, read 1 November 2026. (235, Charmbracelet, 2026)
  22. npm (2026). Download counts for the packages @openai/codex and opencode-ai, 30 September to 29 October 2026. npm registry downloads API; the second package at https://api.npmjs.org/downloads/point/last-month/opencode-ai. (238, npm, 2026)
  23. Model Context Protocol (2025). Security Best Practices. MCP specification version 2025-11-25. (229, MCP, 2025)
  24. International Organization for Standardization and International Electrotechnical Commission (2022). ISO/IEC 27001:2022 Information security, cybersecurity and privacy protection — Information security management systems — Requirements. Geneva: ISO, October 2022. (124, ISO/IEC, 2022)
  25. International Organization for Standardization and International Electrotechnical Commission (2022). ISO/IEC 27002:2022 Information security, cybersecurity and privacy protection — Information security controls. Geneva: ISO, February 2022. (125, ISO/IEC, 2022)