Harness, model, and tools—plus the boundaries that make the stack governable. With Mikhail Trifonov, ↗cloud.ru.
Harness, model, and tools—plus the boundaries that make the stack governable. With Mikhail Trifonov, Cloud.ru.
Open clients, local models, and MCP differ
Open source ≠ local inference
Self-hosted ≠ safe actions
Internal MCP ≠ narrow privileges
External API ≠ a leak by default
Governability appears only with identity and technically enforced execution boundaries
These properties do not imply one another and must be assessed separately
Each axis has its own data path, cost, failure point, and lock-in
Docs confirm capabilities, not deployment security
Observed
Open clients: OpenCode and Codex
Codex supports custom providers
Claude has multiple delivery paths
Not implied
Local, open model
Equal tool use
Sufficient sandbox
The model gateway governs data routing; the tool gateway governs authority and effect
Architectural patterns with different trade-offs in control, speed, and operations
Not a ranking but eight combinations of the data path and the authority path
Two local modes
1 · Autonomous stack
Air gap and pinned versions
Full operational ownership
GPU, serving, evals, updates
3 · Client + local model
Ready-made UX and tool loop
Evals prove compatibility
The workstation remains the boundary
Frontier planning; authority stays inside
2 · Owned harness
Owned process and tools
Frontier quality without owned GPUs
A gateway filters secrets
7 · Planner + executor
Only a typed plan leaves
Credentials stay inside
Policy checks business invariants
Separate vendor UX from corporate authority
4 · Agent + internal gateway
Strong UX and current model
Capabilities stay internal
OBO, policy, trace at gateway
5 · Full SaaS
Shortest time to pilot
Tenant, connectors, retention
High control-plane lock-in
Routing needs evals; user stacks need boundaries
6 · Multi-model router
Price, quality, latency, region
Safe fallback by data class
Evals for every route
8 · User stack
Fast personal workflow
Shadow tokens, supply chain
Registry, scopes, test tenant
Properties depend on deployment context
Air gap requires configuration 1
A fast pilot points to 5
Enterprise actions point to 4
High risk points to 7
A threat model from user intent to the actual system change
Each boundary adds a leakage channel, confused deputy, or goal substitution
An issue, email, README, or log becomes another control channel
Label external data
Filter results and errors
Narrow subsequent capabilities
Test repeated attacks
The model proposes an action; permission to execute it is checked outside the model
Start with the allowed data path, then the cost of action and operational ownership
Three questions quickly narrow eight configurations to an admissible set
Choose the smallest configuration enforcing required boundaries
Pilot · 4 / 5 — One repo, read-only or PR
Enterprise platform · 4 → 6 — Gateway and evals first
Regulated environment · 1 / 7 — Fail closed, OBO, sandbox
Multiple clients and models can operate around owned model and tool gateways
Official repositories, vendor documentation, MCP, NIST, and OWASP
OpenCode · Codex · Claude Code
GLM-5 · GigaChat API
MCP authorization and transports
NIST agent hijacking · OWASP
Record the full stack tuple
Map data and authority
Own the two choke points
Negative-test the policy
Control the path from intent to actual change