
Agent stack configurations
Harness, model, and tools—plus the boundaries that make the stack governable. With Mikhail Trifonov, ↗cloud.ru.
Slide contents
1. Agent stack configurations
Harness, model, and tools—plus the boundaries that make the stack governable. With Mikhail Trifonov, Cloud.ru.
2. “Ours or theirs” is a false choice
Open clients, local models, and MCP differ
Open source ≠ local inference
Self-hosted ≠ safe actions
Internal MCP ≠ narrow privileges
External API ≠ leak by default
3. An agent is more than a model
Governability appears only with identity and technically enforced execution boundaries
4. “Ours” means four controls
These properties do not imply one another and must be assessed separately
5. The three axes are independent
Each axis has its own data path, cost, failure point, and lock-in
6. A logo does not define the stack
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
7. Control lives at two gateways
The model gateway governs data routing; the tool gateway governs authority and effect
8. 01. Eight configurations
Architectural patterns with different trade-offs in control, speed, and operations
9. Eight configurations on one map
Not a ranking but eight combinations of the data path and the authority path
10. Locality still requires operations
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
11. External reasoning, internal authority
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
12. Speed costs trust
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
13. Flexibility needs platforms
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
14. No universal configuration ranking
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
15. 02. Chain of authority
A threat model from user intent to the actual system change
16. Attackers target the data-to-action path
Each boundary adds a leakage channel, confused deputy, or goal substitution
17. Tool output is untrusted too
An issue, email, README, or log becomes another control channel
Label external data
Filter results and errors
Narrow subsequent capabilities
Test repeated attacks
18. Policy must be enforced technically
The model proposes an action; permission to execute it is checked outside the model
19. 03. How to choose
Start with the allowed data path, then the cost of action and operational ownership
20. Data first, products second
Three questions quickly narrow eight configurations to an admissible set
21. The baseline choice depends on deployment
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
22. Two choke points anchor the platform
Multiple clients and models can operate around owned model and tool gateways
23. Sources establish properties, not rankings
Official repositories, vendor documentation, MCP, NIST, and OWASP
OpenCode · Codex · Claude Code
GLM-5 · GigaChat API
MCP authorization and transports
NIST agent hijacking · OWASP
24. Sovereignty is a chain property
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