How to Build a Governed Agent Stack

The conversation begins by separating two decision levels. Company leadership is accountable for ecosystem-wide risk: leakage, personal data, secrets, and the cost of a harmful action. A developer chooses a tool for a concrete task and cares about quality, usability, and continued access. Build versus buy is therefore too coarse. An organization is really drawing a division of labor between itself and suppliers, retaining the controls that define its risk and competitive advantage.

The episode's working formula contains five parts. A harness runs the agent loop and supplies context; a model reasons and proposes tool calls; tools create the actual effect; identity determines on whose behalf an action runs; enforced boundaries constrain processes, network, filesystem, and capabilities. Open source does not guarantee local inference, a self-hosted model does not make actions safe, and an internal MCP server without narrow permissions may expose far more than intended.

The eight configurations form a trade-off map rather than a ranking. One end contains an autonomous air-gapped stack with an owned harness, model, and operations, alongside a ready-made client using a local model. Other patterns combine an owned harness with an external API, a vendor agent with internal tools, full SaaS, a multi-model router, an external planner with an internal executor, or a personal collection of a client, SaaS services, and MCP tools. Each arrangement distributes TCO, lock-in, model freshness, and operational responsibility differently.

Two controlled choke points provide a practical center of gravity for an enterprise platform. A model gateway classifies context, selects an approved provider, region, and model, filters secrets, applies budgets, and enforces safe fallback. A tool gateway validates identity, policy, scopes, dry-run output, and the actual effect while retaining an audit trail. A frontier model can therefore plan without receiving credentials: sanitized context or a typed plan leaves the perimeter, while an on-behalf-of executor stays inside and checks business invariants.

A threat model starts from attack surface and data value, not from a fashionable demand for maximum isolation. An untrusted README, issue, email, or tool result can turn a legitimate task into prompt injection. Risk crosses every boundary in the workspace, harness, model, tool-gateway, and target-system chain. A distinct problem appears when an agent inherits a person's complete identity and can not only read a table for a dashboard but also modify or delete it.

Policy must therefore be enforced outside the model through an OS sandbox, deny-by-default egress, least privilege, short-lived credentials, a tool allowlist, separation of read, propose, write, and commit, independent effect verification, and a kill switch. Selection begins with three questions: may data leave the trust zone, must the agent act inside corporate systems, and are sufficient scale and mature evaluations present? The answers narrow the configurations before any client logo enters the decision.