Agent Stack Configurations: A Complete Analysis of Eight Options

Open client code does not make the model local. A self-hosted model does not make tools safe. An internal MCP server does not restrict permissions by itself. Conversely, an external model API does not necessarily receive production secrets when planning is separated from execution, context is filtered, and authority remains in an internal gateway.010101I told a condensed version of this story in the Research Insights Made Simple #22 livestream — the outline and materials are in my Telegram channel.Knizhny kub · Research Insights #22 (in Russian)01I told a condensed version of this story in the Research Insights Made Simple #22 livestream — the outline and materials are in my Telegram channel.Knizhny kub · Research Insights #22 (in Russian)

This article extends the formula Agent = Model + Harness and the model/tool gateway ideas from the agent-first approach to internal developer platforms. For a practical choice, the formula needs one more step:

agent stack = harness + model + tools + identity + technically enforced execution boundaries

The article uses three kinds of statements to keep fact and opinion separate:

• —documentation links describe product properties stated and verified on the review date;
• —architecture conclusions interpret the consequences of those properties;
• —recommendations select for a specific implementation class rather than rank every solution universally.

The word “ours” is overloaded. It may refer to:

1. 1Source-code ownership: the team can inspect and modify the harness.
2. 2Operational control: the team deploys, upgrades, and observes the component.
3. 3Data control: the team sets the region, retention period, and permitted transfer destinations.
4. 4Policy control: permissions, routes, approvals, and denials are enforced by infrastructure rather than only by a system prompt.

These properties do not imply one another. Forking an open client gives control over code, not the external model. Self-hosted inference gives control over weights and compute location, not over a local shell running with a developer’s permissions. A managed service may be proprietary yet provide stronger isolation and audit than a home-grown service without a dedicated operations team.

Every axis has its own failure point. A configuration should therefore be recorded as a complete tuple rather than a product name, for example:

ready-made local client
× external model through an enterprise model gateway
× internal tools through a gateway with OBO identity
× local OS sandbox

OBO here and throughout means on-behalf-of — delegated authority: the gateway issues the agent a short-lived token on behalf of the person who initiated the task, so internal systems see who is asking and for which task rather than a faceless shared service account.

Axis 1. Agent harness

In-house development or a fork provides maximum freedom in the planning loop, context format, tool policy, and internal-platform integration. The price is permanent engineering work: model compatibility, context compaction, error recovery, approval UX, sandboxing across operating systems, tracing, and dependency updates. A fork also creates a separate supply-chain branch; upstream vulnerabilities are no longer fixed automatically.020202On how autonomous harness loops are actually designed — with execution separated from verification and explicit human control points — I ran a dedicated Loop Engineering livestream.Knizhny kub · Loop Engineering (in Russian)02On how autonomous harness loops are actually designed — with execution separated from verification and explicit human control points — I ran a dedicated Loop Engineering livestream.Knizhny kub · Loop Engineering (in Russian)

A configurable off-the-shelf client lets a team change model endpoints, MCP servers, commands, and rules without building the complete agent loop. It is a practical way to test a hypothesis quickly. A configuration file is not technical control, however: verify where commands actually run, whether egress can be denied, who stores tokens, and what happens when the sandbox is unavailable.

A managed vendor client or cloud agent receives new models and features faster, while the provider assumes part of the isolation and operations burden. In exchange, the organization accepts the provider’s contract for data retention, updates, telemetry, availability, and audit export. Even with a local client, inference and auxiliary checks may remain networked.

Axis 2. Model

“Our model” splits into at least four classes.

• —Open weights in the organization’s own environment. The organization controls inference, versions, and telemetry, but pays for GPUs, spare capacity, serving, upgrades, and quality validation. Open weights guarantee neither a small model nor good tool use.
• —A managed model in a selected cloud or region. Data and compute can remain in an agreed jurisdiction without operating inference directly. Weights, roadmap, and often the control plane still belong to the provider.
• —An external proprietary API. This offers fast access to new capabilities and elastic capacity. The cost is dependency on the API, pricing, limits, data policy, and model behavior.
• —A hybrid router or cascade. It selects a model by task type, cost, and data class. This is not free portability but a separate platform with classification, evals, and safe-fallback rules.

API compatibility means matching request formats, not matching behavior. Two models behind OpenAI-compatible endpoints may interpret system prompts differently, call tools differently, recover differently after errors, and react differently to context compaction. Real portability is proven against the organization’s own task and failure suite.

Axis 3. Tools

Every tool needs two coordinates at once: its origin and its actual execution location.

The label “internal tool” says nothing about execution location. A local MCP server from npm may run on a corporate laptop with the user’s permissions, while an external SaaS tool may accept only a narrow one-time operation through a proxy. The required artifact is a map of actual data and authority flows, not a catalog label.030303A good living example is Airbnb: by their own public account they standardized on MCP, built a dozen internal servers, and pushed agent-assisted development to roughly 60% of teams. That is the company's own figure, not an independent measurement. I covered their journey in my channel.Knizhny kub · Agentic coding at Airbnb (in Russian)03A good living example is Airbnb: by their own public account they standardized on MCP, built a dozen internal servers, and pushed agent-assisted development to roughly 60% of teams. That is the company's own figure, not an independent measurement. I covered their journey in my channel.Knizhny kub · Agentic coding at Airbnb (in Russian)

Every property below was checked against official documentation on July 16, 2026. This is not a model-quality comparison and does not declare one product a replacement for another. It separates what follows from the documentation from what does not.

OpenCode

Verified: the repository is published under MIT; the client supports many providers and a configurable baseURL, plus built-in, custom, and MCP tools. In the current tool documentation, tools are enabled by default, while permissions support allow, ask, and deny.

What does not follow: an open and portable client does not make the model local; rules do not prove the presence of an OS-enforced sandbox; without an enterprise profile, safe defaults remain the responsibility of the user or platform team.

Codex CLI

Verified: the client is open under Apache-2.0; configuration supports custom model providers, including an internal proxy, Ollama, and LM Studio; in CLI/IDE, sandbox and approvals are separate, and the sandbox relies on operating-system mechanisms.

What does not follow: an open client does not make OpenAI models open or local; connecting a different endpoint does not guarantee equal agent-loop quality or tool use.

Claude Code

Verified: official documentation covers the Claude API and Claude delivery through Amazon Bedrock, Google Vertex AI, Microsoft Foundry, and Claude Platform on AWS; the product provides centrally managed permissions and an OS-level sandbox.

What does not follow: these are several delivery paths for Claude, not stated support for an arbitrary self-hosted model. A local client does not imply local inference; data path and retention depend on account type and provider.

GLM-5

Verified: the model card publishes weights under MIT and serving recipes—the card lists 754 billion parameters—while Z.AI offers a managed API.

What does not follow: open weights do not mean “runs on any laptop” and do not remove serving cost. Self-hosted GLM and GLM through an API are different configurations in data path, operations, and failure modes.

GigaChat

Verified: this is a managed API with partial OpenAI API compatibility and custom functions. On the product page, Sber states that data is stored on servers in Russia and that prompts and responses are not used for training by default.

What does not follow: a regional API is not a model under the customer’s operational control. A marketing statement about data must be backed by contract, plan settings, and the organization’s own flow map. API compatibility is not behavioral portability.

Practical conclusion: OpenCode and Codex show that an open harness can work with different endpoints. GLM-5 shows that one model can exist both as open weights and as a service. GigaChat demonstrates the separate class of a regionally managed model. Claude Code shows how one vendor client can offer several infrastructure paths to one model family. None of these examples collapses openness, model ownership, locality, and policy control into one property.

Model and tool gateways are logical roles, not necessarily separate microservices. They may be services, client libraries, or parts of a managed platform. The important capability is independent enforcement of routing, identity, audit, and emergency shutdown. The first gateway controls which data goes where; the second controls who may change what, and on whose behalf.040404It is striking how convergently Block, Uber, and LinkedIn arrived at this same shape: a model gateway, a tool gateway, and a capability registry show up in all of them. I wrote about it in the agent-first IDP post.Knizhny kub · Agent-first IDP (in Russian)04It is striking how convergently Block, Uber, and LinkedIn arrived at this same shape: a model gateway, a tool gateway, and a capability registry show up in all of them. I wrote about it in the agent-first IDP post.Knizhny kub · Agent-first IDP (in Russian)

This architecture has a price. The gateway that carries every prompt, argument, and token is the most valuable attack target in the stack: its log becomes a sensitive-data store of its own, and compromising it yields the authority of every agent at once. It is also an organizational bottleneck: the change queue, on-call duty, and adapter compatibility land on the platform team, and without one the two control points degrade into two points of failure. Owning the gateways is an operating commitment, not a line in an architecture diagram.

These are not product rankings but eight repeatable configurations. Each is described by its data flow, ownership, strengths and constraints, economics, lock-in, suitable scenarios, characteristic failures, and mandatory controls. The mandatory baseline is the same for all eight — an OS-enforced sandbox, deny-by-default egress with no unsafe fallback, pinned versions, OBO, an end-to-end trace, and a kill switch; its operational form lives in the checklist, so “Mandatory controls” below lists only what is specific to each configuration.

Why exactly eight

Formally, the tuple “harness × model × tools” yields twenty-seven combinations, but most of them differ only in logos. The list below keeps the operational archetypes — options that fail differently and require different boundaries. Configurations 1–5 are grid points of “harness × model,” from a fully owned stack to a fully external one. Configuration 6 is not a grid point but a strategy on the model axis: routing turns model choice into policy. Configuration 7 is a different topology: the model is removed from the execution chain and kept only for planning. Configuration 8 is a governance anti-pattern, included because it already lives inside organizations whether they know it or not. If two options fail the same way and are protected the same way, this analysis treats them as one configuration.

1 · Fully autonomous or isolated stack

user → own/forked harness → self-hosted model → local or internal tool gateway → internal systems; no egress during normal operation

Ownership. The organization owns the entire stack: model artifacts, inference, harness, sandbox, tool registry, upgrades, observability, and user support.

Strengths. Maximum control over data location and versions; air-gap operation; independence from external availability and sudden API changes; reproducible behavior on a pinned artifact set.

Constraints. Quality and speed depend on available models and compute. New capabilities arrive only after internal upgrade and validation. Every difficult harness function becomes a product responsibility, while isolation slows the delivery of fixes.

Economics and lock-in. High fixed cost: GPUs, a platform team, spare capacity, and a safe upgrade process — “no API bill” does not mean “no inference cost.” External dependency is minimal, while lock-in remains in the serving stack, weight format, and the client fork.

Best fit. Restricted and defense environments, data that cannot leave the perimeter, and sites with unreliable connectivity.

Characteristic failures. An outdated model or vulnerable dependency remains inside for a long time; the local agent gets broad permissions because “the perimeter is already safe”; an external fallback appears unnoticed; insufficient GPU capacity becomes total unavailability.

Mandatory controls. A private artifact registry; offline fix delivery; regular network tests of the air gap — the absence of egress must be a verified property, not a property of the diagram. Plus the common baseline of boundaries.

2 · Own harness with an external frontier model

user → own harness → enterprise model gateway → external API → own tool gateway → systems

Ownership. The provider owns the model and contractual availability. The organization owns context, the agent loop, routing, tools, permissions, result validation, and user experience.

Strengths. Access to rapidly improving strong models without operating GPUs; full control over domain logic, task state, and the tool layer; the model can be changed behind an isolated adapter.

Constraints. A production-quality harness still has to be built, including context compaction, retries, and loop prevention. Some data leaves the perimeter. A model-behavior change can break the process without any API schema change.

Economics and lock-in. Development cost plus variable API spend; at high agent traffic, cache behavior, step limits, and retry cost become critical. Lock-in is moderate at the protocol level and high in behavior, prompts, and evals tuned to one model.

Best fit. Domain agents whose advantage lies in process and tools, where classified context may be sent outside.

Characteristic failures. A secret enters a prompt or tool result; a rate limit causes a retry storm; context is sent to the wrong region; a provider changes a model alias; the model-gateway log becomes a sensitive-data store.

Mandatory controls. Pre-call context classification and filtering; provider and region allowlists with contractual retention terms; redaction of the gateway’s own logs. Plus the common baseline of boundaries.

3 · Off-the-shelf client with a local or self-hosted model

user → OpenCode/Codex or another configurable client → Ollama / LM Studio / vLLM / internal endpoint → local and internal tools

Ownership. The client developer maintains the base agent loop. The organization owns the model endpoint, compatibility, secure client configuration, sandbox, and enterprise tools.

Strengths. Fast path to a local experiment; ready-made UX, context management, and tool loop without building a client from scratch; code and prompts can remain in a controlled environment.

Constraints. A compatible endpoint does not guarantee correct tool use. The harness may be optimized for another model family. Context compaction and error recovery are difficult to assess on a happy path. A client upgrade can change prompts and model expectations.

Economics and lock-in. The client license may be free, but GPUs, adapters, and workstation support remain — underutilized hardware is often more expensive than an API. The main lock-in is the hidden contract between client and model; a fork reduces surprise-upgrade risk at higher maintenance cost.

Best fit. Open-weight model research, sensitive local code, and temporary offline work.

Characteristic failures. The model emits a syntactically valid but semantically wrong tool call; a local endpoint listens externally without authentication; the client silently fails over outside; a command runs outside the sandbox; laptops produce inconsistent results.

Mandatory controls. A matrix of capabilities proven to work; tests for tool calling, cancellation, compaction, and error recovery; local endpoints bound to loopback or behind authentication; a centrally distributed secure configuration. Plus the common baseline of boundaries.

4 · Vendor coding agent with an internal tool gateway

developer → Claude Code / Codex or another vendor agent → provider model → internal MCP/API gateway → IDP, repositories, CI/CD, and production

Ownership. The provider develops the client and model. The organization owns the tool catalog, action policy, agent identity, audit, and system integrations.

Strengths. Rapid access to strong developer UX and model updates; internal authority can be centralized independently of the client; several clients can share one secure tool contract.

Constraints. Code and context may go to an external provider. Critical client changes arrive on the provider’s schedule. The gateway must be designed as a product, not as a mechanical MCP adapter over low-level APIs.

Economics and lock-in. Seat or API cost plus a shared tool platform; reusable IAM, policy, and audit make each subsequent agent cheaper to onboard. Lock-in is meaningful at the client and model layers and lower for enterprise actions while their contract, identity, and logs belong to the organization.

Best fit. Enterprise development: external models are approved, access to internal systems stays centralized.

Characteristic failures. Every call uses one shared service account; tool output from an issue or repository carries prompt injection; the MCP server exposes low-level commands; client approval does not match the gateway’s actual action.

Mandatory controls. High-level tools with narrow schemas; policy as code and reauthorization at the gateway itself; independent dry run and diff for dangerous actions; a kill switch across all the dimensions listed in the checklist. Plus the common baseline of boundaries.

5 · Fully managed SaaS stack

user → cloud harness → provider model → cloud sandbox/connectors → repositories and SaaS

Ownership. The provider owns most execution, upgrades, and baseline isolation. The customer owns tenant configuration, connected repositories, OAuth scopes, retention settings, review process, and acceptance of results.

Strengths. Minimum time to pilot; almost no internal model or client operations; fast upgrades; cloud jobs can be isolated from a developer workstation.

Constraints. A large trust commitment to the provider; limits around regions, network, custom policy, and telemetry export; availability and roadmap remain outside the organization; old behavior is difficult to reproduce after an upgrade.

Economics and lock-in. Low entry cost, while variable spend grows with seats, tasks, and connectors. Lock-in is high: client, model, execution environment, task state, and connectors belong to one control plane.

Best fit. A constrained pilot, noncritical repositories, and asynchronous tasks with mandatory review.

Characteristic failures. A repository or secret believed to be local reaches the cloud; an OAuth connector has permissions broader than the task; default retention violates policy; an upgrade changes effectiveness; audit cannot be exported to the internal SIEM.

Mandatory controls. Enterprise tenant and contractual data modes; allowlists for repositories and task types; minimum connector scopes; branch protection and independent review; export of available logs with regular retention and region checks; a shutdown and data-export plan. Plus the common baseline of boundaries.

6 · Multi-model platform with routing and fallback

client/agent → model gateway → policy classifier → local, regional, or external model → tool gateway; fallback depends on data and task class

Ownership. Providers own their models. The platform team owns routing, adapters, evals, budgets, tracing, and safe behavior under failure.

Strengths. Quality, cost, latency, region, and availability can be combined. The organization gains real negotiation and migration leverage. A small model can handle a simple step and a strong model a difficult one.

Constraints. This is one of the most behaviorally complex configurations. A universal API hides differences only until the first nontrivial tool call. The router adds latency, failure points, and a permanent need for evals.

Economics and lock-in. High platform cost justified by scale, resilience requirements, or route-cost differences; token savings are easily consumed by retries. Lock-in to one provider falls, replaced by dependency on the organization’s own gateway and eval suite.

Best fit. A large platform with several data classes and a need to survive provider outages.

Characteristic failures. During an outage, a sensitive request automatically goes to an external API; a cheap model misclassifies an action; a cascade multiplies cost; models leave incompatible state; an alias changes without regression testing.

Mandatory controls. Data classification before route selection and explicitly approved “data class × region × model” pairs; for restricted classes, fail closed instead of an asymmetric fallback; the routing reason recorded in the trace; evals for every route and transition. Plus the common baseline of boundaries.

7 · External planner with an internal deterministic executor

user → internal controller → sanitized context to external model → typed plan → internal policy engine/executor → systems; the external model receives no working credentials and calls no system directly

Ownership. The provider supplies reasoning. The organization defines the intent language, validates the plan, executes operations, controls transactions, and decides which results return to the model.

Strengths. A strong external model can be used while authority and sensitive data stay inside. Blast radius is limited to deterministic commands. Every action can be validated before execution.

Constraints. A useful but sufficiently narrow command language is difficult to design. Sanitization loses context. Long interactive loops are slower. A model can still propose a dangerous but formally valid plan.

Economics and lock-in. Integration cost pays off where an incorrect action is expensive. The model is relatively easy to replace while the typed contract and evals belong to the organization; most lock-in moves, intentionally, into the internal executor.

Best fit. Operations with a high cost of error: infrastructure, finance, HR, and regulated environments with planning over de-identified data.

Characteristic failures. A malicious instruction hides in a plan string; a validator checks JSON Schema but not business invariants; dry run differs from commit; an overly detailed error leaks a secret; a retry executes an operation twice.

Mandatory controls. A closed typed intent language with no arbitrary shell or SQL; semantic plan validation, idempotency, and transaction limits; filtered results and errors; credential-free model context; a log connecting intent, policy decision, and actual action. Plus the common baseline of boundaries.

8 · User agent with external MCP/SaaS tools

personal or local client → selected model → user-installed MCP/plugin → external SaaS, often with user-delegated OAuth

Ownership. The user chooses client, servers, and scopes. Client, model, MCP, and SaaS vendors divide technical ownership. The organization often discovers the stack only after data and tokens are already present.

Strengths. A personal workflow can be assembled very quickly; integrations are plentiful; users retain a familiar interface and combine services without waiting for the platform team.

Constraints. Fragmented identity, an opaque vendor chain, and weak common audit. A local MCP inherits the user environment. Approvals quickly become ritual. A package update may change tools and behavior.

Economics and lock-in. Low entry cost but a poorly visible total cost: subscriptions, duplicate integrations, incident investigation, and later centralization. Lock-in is distributed across the client, OAuth connections, SaaS data, and specific MCP servers: replacing one component is easy, reproducing the complete process is difficult.

Best fit. Personal productivity on low-risk data; experiments in a separate test tenant.

Characteristic failures. A malicious or compromised MCP package receives files and tokens; OAuth requests excessive scopes; a localhost server is vulnerable to DNS rebinding; a token is forwarded without audience validation; prompt injection from an email makes the agent send data; the user automatically approves a sequence of similar requests.

Mandatory controls. An enterprise registry of approved MCP servers and versions with provenance checks; OAuth with PKCE, audience validation, and short-lived tokens; keyring secret storage; separate personal and work tenants; no high-risk write tools; centralized access revocation. Plus the common baseline of boundaries.

A NIST CAISI technical blog describes agent hijacking as a form of indirect prompt injection: an attacker places an instruction in data—an email, website, file, or repository—that an agent reads while performing a legitimate task. In NIST experiments, repeated attempts materially changed measured risk, and scenarios included remote code execution, bulk exfiltration, and phishing. A sentence in the system prompt cannot fix this. Controls must sit at data, identity, and execution boundaries.050505Of the books on this topic I like Steve Wilson’s “The Developer’s Playbook for LLM Security” — a solid foundation, though the field has since outgrown its agent coverage. Real abuse cases are well visible in Anthropic’s threat intelligence report.Knizhny kub · Steve Wilson’s book (in Russian)Knizhny kub · Anthropic Threat Intelligence (in Russian)05Of the books on this topic I like Steve Wilson’s “The Developer’s Playbook for LLM Security” — a solid foundation, though the field has since outgrown its agent coverage. Real abuse cases are well visible in Anthropic’s threat intelligence report.Knizhny kub · Steve Wilson’s book (in Russian)Knizhny kub · Anthropic Threat Intelligence (in Russian)

Prompt injection and agent hijacking. The agent mixes developer instructions and external data in one context. A model may know that a site is untrusted and still follow a hidden instruction; more tools and repeated attempts increase the attack surface. The denial therefore belongs in policy and IAM. A model may propose an action but must not decide whether it has permission to perform it.

Code and secret leakage. Leakage is not limited to the prompt sent to a model. Tool arguments and results, traces, crash reports, telemetry, caches, shell history, and external fetches all become channels. A secret removed from the original request may return to context after a tool reads .env. The same controls must cover input, the tool loop, and logs.

Excessive permissions and confused deputy. An internal gateway using one service account is more dangerous than an external API with a narrow user scope. The agent becomes a confused deputy when it acts with gateway authority rather than the initiator’s. The MCP security guidance explicitly treats token passthrough as an antipattern: the server must accept only tokens issued for it, validate audience, and obtain a separate downstream token. The MCP authorization specification requires resource-bound tokens and recommends minimum scopes.060606For what authorization looks like at true scale, our book club read the Zanzibar whitepaper — Google’s global ReBAC system. Many OBO ideas grow from there.Knizhny kub · Zanzibar whitepaper (in Russian)06For what authorization looks like at true scale, our book club read the Zanzibar whitepaper — Google’s global ReBAC system. Many OBO ideas grow from there.Knizhny kub · Zanzibar whitepaper (in Russian)

SSRF and DNS rebinding. OAuth discovery, dynamic callback URLs, and arbitrary-URL tools expose SSRF paths to metadata endpoints and internal addresses. A local HTTP MCP without Origin validation, authentication, and correct binding can be reached through browser DNS rebinding. The MCP transport specification requires Origin validation and recommends that local servers bind only to loopback.

Supply chain of binaries and MCP servers. A signed binary proves the publisher, not safe behavior. An open repository permits audit but does not prove that the installed package was built from it. An MCP server or skill is executable code and a source of model instructions at once. Version it, review it like an application dependency, and run it with minimum permissions. A presentation to ISPAB hosted by NIST list signed manifests, pinned versions, and sandboxing for third-party MCP servers among the mitigations.070707Every supply-chain conversation I have ends with the Log4Shell story: a library critical to the whole internet was maintained by a handful of volunteers. I retold it in the channel from the Log4j maintainer’s own account.Knizhny kub · the Log4Shell story (in Russian)07Every supply-chain conversation I have ends with the Log4Shell story: a library critical to the whole internet was maintained by a handful of volunteers. I retold it in the channel from the Log4j maintainer’s own account.Knizhny kub · the Log4Shell story (in Russian)

Unsafe fallback routes. “If the local model is unavailable, send it outside” is a policy change, not an availability feature. A fallback must be at least as permissible for the current data class. In a restricted environment, the safe outage response is to stop the task rather than disclose context.

Approval fatigue. Confirming every command does not create informed consent. Users learn to press Allow, and an agent may split one dangerous action into apparently harmless steps. Approval must show the final effect: which data leaves, on whose behalf, which resource changes, and whether it is reversible. The gateway must independently revalidate a dangerous action.

A sandbox that exists only in a prompt or container. Asking a model not to use the network is not network policy, and a proxy environment variable does not block direct connections. The OS, hypervisor, or isolated environment must physically restrict filesystem, processes, and egress. OpenAI describes sandbox and approvals in Codex as complementary controls, not substitutes. A container is useful, but privileged mode, a mounted Docker socket, or broad credentials make its boundary fictitious.080808A radical take on this: “let the network be the sandbox.” Tailscale keeps placeholder keys inside the sandbox and injects real ones at the network layer. I covered that talk in the channel.Knizhny kub · network as sandbox (in Russian)08A radical take on this: “let the network be the sandbox.” Tailscale keeps placeholder keys inside the sandbox and injects real ones at the network layer. I covered that talk in the channel.Knizhny kub · network as sandbox (in Russian)

Audit without event provenance. A log entry saying “agent invoked deploy” is insufficient. An investigation needs the user and agent identity, original intent, model and version, route, configuration hash, tool name and version, policy decision, issued scopes, arguments with controlled redaction, actual effect, and approval result. The log itself must be protected as sensitive data.

The operational form of the twelve boundaries in the diagram — concrete, verifiable items — lives in the pre-launch checklist, so the list exists in exactly one place. Three boundaries skipped most often deserve their own explanation:

• —Policy as code. The gateway validates resource, action, data, subject, and execution environment; the system prompt only explains the rule to the model — it does not enforce it.
• —Evals and red teaming. Test not only answers but refusal, injection through tool output, repeated attacks, RCE, and exfiltration; the NIST CAISI technical blog emphasizes that defenses and evaluations must adapt to new attacks.
• —Independent effect validation. Schema validation is insufficient: a dangerous action is confirmed by a policy engine, dry run, business invariant, or a human not involved in generating the plan.

“Internal” does not mean safe, and “external” does not mean unsafe. What matters is actual authority, the data path, revocability, and boundaries enforced by the system. This aligns with the OWASP Top 10 for Agentic Applications and the separate OWASP MCP Top 10: the attack surface spans reasoning, memory, tools, identity, protocol, and human control.

There are no scores here. The same characteristic changes with scale, model, contract, and team maturity. No configuration is labeled “high security” because security is an outcome of implemented boundaries, not a property of a name.

The Cost structure column deliberately does not count money: budgets, contracts, FinOps, and vendor negotiations are covered in the longread on the economics of AI development, while this article keeps configuration and boundaries.

Quality, operations, and economics

Portability, data, and control

The tree intentionally does not start with a product: first define the permitted data path, the cost of action, and operational responsibility — only then select client and model. The detailed routes by implementation type are in the recommendations below.

Pilot. Start with configuration 4 or 5, but narrow the task more than feels comfortable: one repository, one data class, read-only access or a pull request instead of direct writes, and no production credentials. The pilot should measure accepted work, refusal, and review load—not prove that an agent can call many tools. Even a pilot needs one trace and a prompt-injection scenario.

Enterprise platform. Approve several clients while owning the points where data and authority pass: model gateway, tool gateway, capability registry, agent identity, policy, and audit. Configuration 4 is the baseline. Move to 6 only after an internal eval suite and sufficient scale exist; a router before measurement adds complexity, not portability.

Regulated environment. If data cannot leave the perimeter, select 1 and technically block external fallback. If a de-identified objective without credentials or system data may leave, consider 7. In either case, internal tools still require OBO, narrow scopes, and OS/network sandboxing. The word “closed” does not fix confused deputy.090909A conference version of this analysis focused on a large fintech — data paths, Bank of Russia guidance, and a target configuration portfolio — is available as the Podlodka AI Engineers Club deck.Podlodka deck · fintech edition09A conference version of this analysis focused on a large fintech — data paths, Bank of Russia guidance, and a target configuration portfolio — is available as the Podlodka AI Engineers Club deck.Podlodka deck · fintech edition

Individual development. Configuration 3 fits sensitive local code when model quality and sandboxing are explicitly validated. Configuration 8 can serve low-risk personal automation, but work and personal tenants, tokens, and MCP servers must remain separate. Once a user scenario requires production write permissions, it is no longer a personal tool and should move through configuration 4 or 7.

For most large companies, the practical center of gravity is neither a total fork nor one SaaS for every case. It is several approved clients and models around two owned choke points — model and tool gateways — with a common identity, policy, trace, and eval layer between them.

Fork the harness when the agent loop itself is a product advantage or an off-the-shelf client cannot technically enforce a required boundary. Use a self-hosted model when the data path, economics at proven utilization, or autonomy demands it—not for the symbolic word “ours.” Separate high-risk execution from probabilistic planning even when planner and executor formally belong to the same vendor.

The central conclusion: sovereignty and security are properties of the complete chain, not an individual component. Own the points where data, authority, and irreversible actions intersect.