Suman Bisht

product marketing

<p><a href="https://www.coder.com">Coder</a> is a self-hosted platform for running AI coding agents and cloud development environments on infrastructure you control. It works with any agent, cloud, IDE, OS, Git provider, and identity provider.</p>

<p>For security teams and platform engineers, the question is no longer whether to adopt AI agents, but how to do it without losing visibility, control, and auditability.</p>

<p>The thing with coding agents is that they work. One popular streaming service has roughly 10% of its production codebase written by agents, reviewed and approved by humans. Coder runs at around 30%. Anthropic recently shared that over 80% of the code merged into their production codebase was authored by Claude Code. The technology is only getting better. That is the very reason admins and CISOs are paying close attention to how agents are deployed and governed.</p>

<p>Coder offers a secure and standardized way to govern and scale AI agents across your development environments. This blog covers what goes inside our AI stack and how each layer helps teams reduce the risks of agents going rogue. Going bottom up in the stack:</p>

<p><img src="https://www.datocms-assets.com/19109/1783544567-coder-ai-stack.png" alt=""></p>


<h4><strong><em>Infrastructure layer: deployment flexibility</em></strong></h4>

<p>This is the foundation where the hardware lives, representing any public cloud (AWS, GCP, Azure) or private infrastructure (VMware, OpenShift, bare metal). Coder is self-hosted, so you can even deploy it in <a href="https://coder.com/docs/@v2.34.3/install/airgap">air-gapped</a> data centers to meet regulatory requirements. Since Coder runs inside your own infrastructure, it inherits all the access and security policies you define.</p>

<p>On top of the infrastructure, you can run Kubernetes, VMs on EC2, OpenStack, VMware, and so on. This abstracts the compute layer so teams don&#39;t need to handle raw infrastructure and can standardize how environments are provisioned. Most commonly, teams deploy Kubernetes clusters for cloud-native workloads and AWS EC2 for monorepo-heavy environments.</p>

<p>The next three layers are Coder software: an AI control plane, a development environment, and an AI Gateway.</p>

<h4><strong><em>Control plane: the orchestration layer</em></strong></h4>

<p>Coder&#39;s AI control plane manages workspace lifecycles, user authentication, workspace configuration, and external integrations. Both UI and API are supported for template creation, provisioning, RBAC, and lifecycle management.</p>

<p>Coder separates who defines environments from who uses them. Admins create and manage Templates; developers use those Terraform-based templates to launch Workspaces. This keeps environments consistent and repeatable across teams.</p>

<p>With <a href="https://coder.com/solutions/agents">Coder Agents</a>, the control plane also runs the agent loop itself, more on that below.</p>

<h3>Development environment: where standardization meets execution</h3>

<p>This is the most critical part of the stack. The development environment is where code gets written, tested, and executed. It spans three workspace configurations, each designed for a different way of working with AI. Workspaces are configured via Templates, giving admins pre-configured tools, policies, and governance applied at runtime, keeping environments consistent across your fleet. With Coder Agents, workspaces are spun up on demand and torn down when the task is done.</p>

<p>Three common paths we see teams take when adopting AI in their development environments:</p>

<ol>
<li><strong>Coding Assistants</strong> are the most widely adopted form of AI in development today and often serve as a gateway to running agents. They run inside Coder Workspaces rather than on local machines, providing faster onboarding, standardized environments, and security through isolated compute. Coder integrates with agentic IDEs such as <a href="https://registry.coder.com/modules/coder/cursor">Cursor</a>, <a href="https://registry.coder.com/modules/coder/windsurf">Windsurf</a>, and <a href="https://registry.coder.com/modules/coder/zed">Zed</a>, and template admins can pre-install extensions like GitHub Copilot and Roo Code. The developer is always in control, with AI acting as an assistant rather than an autonomous actor.<br></li>
</ol>

<p>As teams move from developer-assisted AI to autonomous workflows, they typically choose between running third-party agents inside a workspace or using Coder Agents.</p>

<ol>
<li><strong>Bring your own agent</strong>, such as Claude Code, Codex, Goose, or a custom agent, runs inside a Coder workspace alongside a developer. The developer and agent share access to source code and dev tools. Admins control what tools and integrations are available via templates. By design, agents operate with lower access levels than developers. </li>
<li><strong>Coder Agents</strong> is Coder&#39;s native self-hosted AI coding agent. Unlike third-party agents that run inside a workspace, Coder Agents runs the agent loop in the control plane. LLM API keys never enter workspaces, the agent operates with the same permissions as the user who invoked it, and every action is tied to that user&#39;s identity. Workspaces are provisioned on demand for specific tasks such as writing or editing code, pull requests that require code changes and torn down when the task is done. Supports multi-turn conversations, sub-agent delegation, and can be triggered from chat, API, CI, GitHub Actions, Slack, and Jira. </li>
</ol>

<p>Teams can run agents both ways from the same Coder deployment, using the same templates, identity, and access controls.</p>

<p><strong>Coder Agents vs bring your own agent: which one to use</strong></p>

<p>The two are not mutually exclusive but they serve different needs.</p>

<p><strong>Bring your own agent</strong> when your team already has a preferred agent (Claude Code, Codex, Goose) and wants to keep using it inside a governed environment. The agent runs inside the workspace alongside the developer. Admins define the access levels for both developers and the agents. This is the lower-friction path for teams already running third-party agents who want to add governance without changing how developers work.</p>

<p>Use <strong>Coder Agents</strong> for fully autonomous workflows without a developer actively supervising each run. The agent loop runs in the control plane, credentials never enter the workspace, and workspaces are spun up and torn down per task. This is the better fit for background tasks, ticket-driven workflows, and any scenario where you want the agent operating independently at scale.</p>

<p>The practical difference is where the agent loop runs and who holds the credentials. With Bring your own Agent, the agent runs in the workspace and the developer manages the session. With Coder Agents, the control plane manages the session and the workspace is just compute.</p>

<h3><strong>Agent Firewall: contain and monitor agent network access</strong></h3>

<p>A key component of the <a href="https://coder.com/solutions/ai-governance">AI Governance Add-On</a>, Agent Firewall enforces a default-deny network policy for third-party agents running inside each Workspace. Any request outside the allow list is blocked and logged. Narrowly scoped network policies also make anomaly detection practical because unexpected spikes in API calls become easier to identify.</p>

<p>Here is an example Agent Firewall rules file for a DoD / public-sector deployment:</p>

<pre><code class="jsx">rules:
  - domain: github.example.mil
    methods: [GET, POST, PUT, PATCH]
  - domain: registry.example.mil
    methods: [GET]
  - domain: llm.ocp-ai.example.mil
    methods: [POST]
  # Everything else: DENIED by default
</code></pre>

<h3>AI Gateway: observe and control LLM access</h3>

<p>AI Gateway is part of the <a href="https://coder.com/solutions/ai-governance">AI Governance Add-On</a>. It sits between AI tools such as Claude Code, Codex, or custom agents and upstream model providers like Anthropic, OpenAI, AWS Bedrock, or self-hosted models. It replaces scattered API keys with a single access point. We have seen teams managing over 500 individual keys to the same provider, making it straightforward to grant, revoke, and track usage by user and agent. It centralizes authentication, full prompt audit trails with session-level provenance, per-user token attribution and spend visibility, and centralized MCP server administration. </p>

<p><img src="https://www.datocms-assets.com/19109/1783537914-image-1.png" alt=""></p>

<p>Structured logs are exported to any SIEM such as Splunk or Grafana Loki. Both third-party agents running inside workspaces and Coder Agents running in the control plane route through AI Gateway, giving platform teams consistent visibility and governance across all agent activity.</p>

<h3><strong><em>Model provider</em></strong></h3>

<p>A model provider standardizes access to AI models. AI Gateway connects to model providers for centralized authentication, observability, and cost management. Common providers include AWS Bedrock, Anthropic, and OpenAI, and you can also self-host your own.</p>

<h3><strong><em>LLM models</em></strong></h3>

<p>Coder is model-agnostic. Teams configure which models their AI agents and assistants use through AI Gateway, maintaining consistent governance, compliance, and security controls regardless of vendor. With Coder Agents, teams can switch between models or providers without changing platforms or re-architecting workflows. Common examples: Claude Opus 4.8, GPT-5.5, self-hosted Llama variants.</p>

<h2>From architecture to action</h2>

<p>The stack you&#39;ve just seen is how enterprises in financial services, defense, and high tech are running AI agents in production today. According to Gartner&#39;s 2026 CIO and Technology Executive Survey, only 17% of organizations have deployed AI agents to date, yet more than 60% expect to do so within the next two years (<a href="https://www.gartner.com/en/articles/hype-cycle-for-agentic-ai">source</a>). The difference between the deployments that succeed and the over 40% of agentic AI projects <a href="https://www.gartner.com/en/newsroom/press-releases/2025-06-25-gartner-predicts-over-40-percent-of-agentic-ai-projects-will-be-canceled-by-end-of-2027">Gartner predicts</a> will be canceled by 2027 is governance infrastructure in place before agents go to production.</p>

<ul>
<li><strong>Security teams</strong> get deterministic controls rather than policy documents hoping developers comply</li>
<li><strong>Platform engineers</strong> get consistent environments rather than snowflake setups that break in production</li>
<li><strong>Developers</strong> get AI acceleration rather than friction and endless security exceptions</li>
<li><strong>Leadership</strong> gets production deployment and measurable ROI rather than stalled pilots and wasted investment</li>
</ul>

<p>Ready to see how this stack works in your environment? <a href="https://coder.com/trial">Try Coder</a> or <a href="https://coder.com/contact/sales">talk to us</a>.</p>

<h2>Resources</h2>

<ul>
<li><a href="https://coder.com/docs">Coder Documentation</a></li>
<li><a href="https://coder.com/docs/ai-coder/agents">Coder Agents</a></li>
<li><a href="https://coder.com/docs/ai-coder/ai-gateway">AI Gateway</a></li>
<li><a href="https://coder.com/docs/ai-coder/agent-firewall">Agent Firewall</a></li>
<li><a href="https://coder.com/docs/ai-coder/ai-governance">AI Governance Add-On</a></li>
<li><a href="https://registry.coder.com/modules">Coder Registry</a></li>
<li><a href="https://coder.com/pricing">Coder Pricing</a></li>
</ul>


AI coding agents are writing production code fast. Coder's stack shows how to govern them, from self-hosted infrastructure to the LLM layer, at scale.

Coder's AI stack: Bring your own agent or run Coder Agents in governed environments

Coder's AI Stack: Bring Your Own Agent or Run Coder Agents in Governed Environments

Ben Potter

Product Manager

<p><a href="https://developers.openai.com/codex">OpenAI Codex</a> has evolved into a suite of agentic software development and business tools, but it has one problem: users are confined to either running workloads directly on their laptops or on OpenAI’s cloud environments.</p>

<p>For regulated enterprises (or those with complex development environments), this effectively becomes a non-starter for widespread adoption. While some power-users can be trusted to run these workloads on laptops, the security risks (prompt injection, code exfiltration, data loss) of running locally are too high. On the other hand, OpenAI’s cloud environments are limited to running a single container per repository and lack connectivity to internal enterprise networks. </p>

<p>The Codex agent itself is extremely capable and powerful, but there is not a proper environment to run them on with all of the proper context, security, and tooling. </p>

<h1>Enter Coder</h1>

<p>Coder runs governed developer environments on remote infrastructure, off laptops, centralized and hardened by your platform team. Unlike OpenAI&#39;s cloud environments, Coder workspaces run entirely on your infrastructure and aren&#39;t limited to a single container per repository. Defined in Terraform, Coder workspaces can run containers, full VMs, or anything else your stack requires, on your infrastructure, inside your network, with access to your internal services, your secrets management, your CI systems, and whatever else your developers actually need to do their jobs.</p>

<p>Workspaces come with your repositories checked out, dependencies installed, and the context Codex needs to do useful work from the moment it starts. Developers connect via browser or IDE.  Codex is already there, authenticated, and configured the way your platform team decided. No local installs, no manual configuration, no API keys in dotfiles.</p>

<p>For Codex, the workspace is the sandbox. Firewall rules, network configuration, identity, and auditing are all handled centrally. You can run full-auto mode without the risks of doing it locally, because the workspace is isolated infrastructure your platform team controls. Not a laptop with a home directory full of credentials.</p>


Set Up OpenAI Codex in Coder: Self-Hosted AI Coding Agent Tutorial

<h2>Reference architecture</h2>

<p>Coder can be deployed in a number of different ways, but the most common pattern we see from customers is AWS with EKS and Coder running on their VPC. For Codex specifically, the timing is good: Codex is now available directly on Amazon Bedrock, meaning customers running Coder on AWS can hit Codex through the same Bedrock APIs and controls they already use. No OpenAI API proxy, no separate key management story, and no new vendor relationship to manage.</p>

<p>Codex workspaces sit behind the same network controls as everything else in that environment: egress is filtered, ingress is controlled, and the API key the agent uses is injected by the template, not typed in by the developer.</p>

<p><img src="https://www.datocms-assets.com/19109/1783028637-open-ai-codex-coder.png" alt=""></p>

<p>For organizations not on AWS, Coder runs on Azure, GCP, VMware, OpenShift, and on-prem. Around 40% of our customers run something other than AWS with EKS. The architecture is the same regardless: Coder&#39;s control plane manages provisioning, the workspace is where Codex runs, and the client machine stays clean.</p>

<p>See our <a href="https://coder.com/docs/install/kubernetes">guides for installing Coder on Kubernetes</a>.</p>

<h2>Coder templates: the golden path in practice</h2>

<p>Templates are written by platform administrators and define the underlying infrastructure, dependencies, and tools for developer environments. Users pick a template from a curated list to get into a workspace.</p>

<p>For most organizations, a single &quot;golden template&quot; covers the main population of users: a developer making a quick change, a product manager prototyping something, a QA engineer writing tests. That template has the languages, utilities, and tooling the team needs pre-installed and pre-configured. Codex included.</p>

<p>Organizations with different needs can run multiple templates. A stricter template for contractors might scope Codex to a single repository. A broader one for senior engineers might have wider network access and full-auto enabled by default. Same platform, same governance, different postures. These decisions live in the template, managed by the platform team, not scattered across individual developer machines in dotfiles and shell configs nobody has audited.</p>

<p>Because Coder is language and tooling agnostic, the same platform that runs your Codex environments also runs environments for teams that don&#39;t use Codex at all. Python, Java, Go, whatever the stack. The golden path isn&#39;t opinionated about what you build or what tools you use. It&#39;s opinionated about how environments are provisioned, secured, and managed.</p>

<p>See our <a href="https://coder.com/docs/admin/templates">guides for template management</a>.</p>

<h2>AI governance</h2>

<p>Coder handles sandboxing and network controls. But that only stops agents from doing dangerous things in the moment. It doesn&#39;t tell you what the agent did, who ran it, which model it talked to, which MCP servers it called, what files it wrote to, or whether the configuration it ran under matched what your security team actually approved.</p>

<p>Different teams running different versions, different API keys pointed at different endpoints, none of it logged anywhere. When something goes wrong, or when legal asks what the agent did last Tuesday, there&#39;s no answer.</p>

<p>Coder&#39;s AI Governance Add-On handles this at the platform level. Every Codex session is fully audited and visible in the Sessions UI. Those logs can be ingested into your SIEM for storage and analysis. The configuration governing what the agent can do, which model endpoint it hits, how environment variables are handled, lives in the template. Not in a config file on someone&#39;s laptop that may or may not match what everyone else is running.</p>

<p>Learn about <a href="https://coder.com/docs/ai-coder/ai-governance">AI Governance with Coder</a>.</p>

<h2>Looking forward</h2>

<p>Codex started as a terminal agent. It has since expanded well beyond software developers, with knowledge workers now making up roughly one in five users and growing at more than triple the rate of the core developer group. Today, <a href="https://openai.com/index/openai-to-acquire-ona/">OpenAI announced the acquisition of Ona</a>, bringing its secure cloud execution and orchestration technology into the Codex ecosystem to handle longer-running work across hours or days. Codex is becoming a platform. </p>

<p>We&#39;d like to see OpenAI take the same path <a href="https://cursor.com/blog/self-hosted-cloud-agents">Cursor did with self-hosted cloud agents</a>: let enterprises run Codex&#39;s agentic workflows on their own infrastructure. Regulated organizations can&#39;t send code, secrets, or build artifacts to a third-party cloud. A single container per repository doesn&#39;t reflect how real development environments work. </p>

<p>Self-hosting support would let the full Codex experience, the IDE extensions, the background agents run on Coder or any trusted enterprise infrastructure. Until then, the Codex CLI works great in Coder today. </p>

<hr>

<p><strong>Get started</strong></p>

<p>You can learn how to install <a href="https://coder.com/docs/install">Coder Community Edition</a> (or start a <a href="https://coder.com/trial">premium trial</a>) and have Codex running in a governed workspace in minutes. For a deeper look at how Coder fits your infrastructure, reach out to our technical sales team at <a href="mailto:sales@coder.com">sales@coder.com</a>.</p>


Run OpenAI Codex in self-hosted cloud development environments built for regulated enterprises. See how Coder secures AI coding agents at scale.

How To Set Up Enterprise Development Environments with OpenAI Codex and Coder

Dave Ahr

Staff Sales Engineer

<p>Kiro CLI is a strong terminal coding agent, but like any agent, it is risky to run on a local laptop. From a security standpoint, the agent can read your local files, run commands as you, and reach the internet. That gives it room to take actions on your behalf, delete files, read credentials, or send data somewhere it shouldn&#39;t go.</p>

<p>The risk is higher for the people who often get the most out of an agent: product managers, QA engineers, and data scientists who aren&#39;t steeped in sandboxing and least-privilege practices and tend to hand riskier work to the agent.</p>

<p>Kiro CLI raises the stakes because it is built for autonomy. It descends from the Amazon Q Developer CLI, runs subagents in parallel, fires hooks on events, and can run non-interactively inside a pipeline with an API key. Approving each tool call by hand defeats the point, but turning approvals off on a laptop full of sensitive code and open network access is exactly the setup you want to avoid.</p>

<p>Because of this, many IT and security teams block terminal agents on the desktop, or limit them to a small group of engineers who can manage the risk. There is a better place to run them.</p>


How to Run Kiro CLI Securely in Coder Workspaces (Setup & Demo)

<h2>Enter Coder</h2>

<p>Coder runs developer environments on remote infrastructure managed by your platform team. Instead of working on a laptop, developers connect to workspaces running in your cloud or datacenter. Nobody installs Kiro CLI locally or manages their own keys and MCP config. The workspace comes pre-built with the agent, the right tooling, and the network and identity controls your organization requires.</p>

<p>This changes how you think about autonomy. Inside a Coder workspace you can let the agent run its tools without hand-approval, because the blast radius is a disposable, network-isolated environment rather than a personal machine. If something goes wrong, you delete the workspace and start a new one.</p>

<h2>Reference architecture</h2>

<p>Coder can be deployed in many ways. Here is a common pattern for running Kiro CLI.</p>

<p><img src="https://www.datocms-assets.com/19109/1782424016-blog_coder-kiro-graphic1.png" alt=""></p>

<h3>Infrastructure</h3>

<p>Coder is self-hosted and runs on any cloud or on-premise datacenter. The most common setup is AWS with EKS, which lets you scale to thousands of workspaces for people and agents. Running on your own VPC keeps ingress and egress under your control and lets workspaces reach internal services like source control and CI.</p>

<p>There is a useful detail for Kiro here. Kiro routes its model inference through its own managed backend, which runs in AWS regions (currently us-east-1 and eu-central-1). If your Coder deployment is already in AWS, both the workspace and the model traffic stay inside AWS&#39;s network. That matters for AWS-aligned and public sector teams, and Kiro supports IAM Identity Center and AWS GovCloud (US) for authentication.</p>

<h3>Templates</h3>

<p>Templates are written by platform admins and define the infrastructure and tools behind each workspace. A common approach is a golden template with the languages and utilities most people need (Java, Python, git, jq) plus the agent itself. Kiro CLI installs with a single Terraform module, which can be found in the <a href="https://registry.coder.com/modules/harleylrn/kiro-cli">Coder Registry</a>:</p>

<pre><code>module &quot;kiro-cli&quot; {
  count    = data.coder_workspace.me.start_count
  source   = &quot;registry.coder.com/harleylrn/kiro-cli/coder&quot;
  version  = &quot;1.0.1&quot;
  agent_id = coder_agent.main.id
  workdir  = local.work_folder

  install_agentapi = false
  report_tasks     = false
}
</code></pre>

<p>You bake the agent&#39;s steering files and approved MCP servers into the template too, so every workspace starts with the same context and the same tools. For non-developers, you can ship a locked-down template variant with a hardened VPC and limited network access, aimed at people who just need the agent for prototyping</p>

<p>By default, the Kiro CLI Terminal UI prompts for shell approval every session, even when using a Coder module to install it. On a laptop, approving each command is a reasonable safeguard, since the agent is running next to your real files and credentials. In a Coder workspace that reasoning no longer applies. The agent runs in an isolated environment with the network limits you set, and if something goes wrong you delete the workspace and rebuild it. At that point the prompt only gets in the way.</p>

<p>The root cause is subtle: Kiro&#39;s active agent config (<code>~/.kiro/agents/agent.json</code>) separates tool <em>availability</em> from tool <em>trust</em>. The <code>tools</code> array defines what the agent can access, while <code>allowedTools</code> controls what runs without prompting. The h<code>arleylrn/kiro-cli</code> Coder module writes this file at workspace startup with <code>shell</code> in <code>tools</code> but not in <code>allowedTools</code>, so every shell command still requires manual approval. The fix is a companion <code>coder_script</code> resource that waits for the module to finish writing <code>agent.json</code>, then uses <code>jq</code> to add &quot;<code>shell</code>&quot; to <code>allowedTools</code> without overwriting the rest of the module-managed config. The idempotency check ensures the patch applies cleanly on workspace restarts and prebuild runs without duplicating the entry.</p>

<pre><code>resource &quot;coder_script&quot; &quot;kiro_agent_config&quot; {
  agent_id     = coder_agent.main.id
  display_name = &quot;Kiro CLI Agent Config&quot;
  icon         = &quot;/icon/kiro.svg&quot;
  run_on_start = true
  script       = &lt;&lt;-EOT
    # Wait for the module to write agent.json first
    until [ -f ~/.kiro/agents/agent.json ]; do sleep 2; done

   # Add shell to allowedTools if not already present
    if ! jq -e &#39;.allowedTools | contains([&quot;shell&quot;])&#39; ~/.kiro/agents/agent.json &gt; /dev/null 2&gt;&amp;1; then
      jq &#39;.allowedTools += [&quot;shell&quot;]&#39; ~/.kiro/agents/agent.json &gt; /tmp/agent.tmp \
        &amp;&amp; mv /tmp/agent.tmp ~/.kiro/agents/agent.json
    fi
  EOT
}
</code></pre>

<p>Additionally, The kiro-cli does not support headless authentication.  So, there must be a human in the loop.  This can be done in a few ways:  First, you can pre-generate an authentication tarball on a machine where you&#39;ve already authenticated, second, you can authenticate using the Kiro CLI from the workspace dashboard or you can authenticate from inside the workspace itself through the VSCode terminal.  The authentication tarball can be an optional parameter baked into the template.</p>

<p>Add a coder_parameter for the tarball and wire it into the module. Parameters with default = &quot;&quot; and mutable = true let the user optionally paste their tarball at workspace creation (or edit later).</p>

<pre><code>data &quot;coder_parameter&quot; &quot;kiro_cli_auth_tarball&quot; {
  name         = &quot;kiro_cli_auth_tarball&quot;
  display_name = &quot;Kiro CLI auth tarball (optional)&quot;
  description  = &lt;&lt;-EOT
    Paste a base64+zstd encoded Kiro CLI auth tarball to         pre-authenticate the CLI.

    To generate one, on a machine where you&#39;ve already run `kiro-cli login`:

        cd ~/.local/share/kiro-cli &amp;&amp; tar -c . | zstd | base64 -w 0

    Leave blank to skip; you can authenticate inside the workspace by running `kiro-cli login`.
  EOT

  type         = &quot;string&quot;
  form_type    = &quot;textarea&quot;
  mutable      = true
  default      = &quot;&quot;
  order        = 50
}
</code></pre>

<p>Wire it into the module:</p>

<pre><code>module &quot;kiro-cli&quot; {
  count    = data.coder_workspace.me.start_count
  source   = &quot;registry.coder.com/harleylrn/kiro-cli/coder&quot;
  version  = &quot;1.0.1&quot;
  agent_id = coder_agent.main.id
  workdir  = local.work_folder

  install_agentapi = false
  report_tasks     = false

  auth_tarball = data.coder_parameter.kiro_cli_auth_tarball.value
}
</code></pre>

<p>The module&#39;s install script extracts the tarball with <code>tar -I zstd</code>. Your Coder image may or may not have <code>zstd</code> installed. If extraction fails with &quot;<code>zstd: command not found</code>&quot;, add a <code>pre_install_script</code> to install it, but since this image runs as a non-root user with <code>no_new_privs</code>, you can&#39;t apt-get install. Two options:</p>

<ol>
<li>Bake <code>zstd</code> into the image (preferred for production).<br></li>
<li>Use a statically-compiled <code>zstd</code> binary in <code>~/.local/bin</code>:</li>
</ol>

<pre><code class="shell">pre_install_script = &lt;&lt;-EOT
  if ! command -v zstd &gt;/dev/null 2&gt;&amp;1; then
    mkdir -p $HOME/.local/bin
    curl -fsSL -o $HOME/.local/bin/zstd \
      https://github.com/facebook/zstd/releases/download/v1.5.6/zstd-1.5.6-linux-x86_64
    chmod +x $HOME/.local/bin/zstd
    export PATH=&quot;$HOME/.local/bin:$PATH&quot;
  fi
EOT

(That URL is illustrative — check the latest zstd release for a static Linux binary. Many distros include zstd already, so try without this first.)
</code></pre>

<h3>The agent</h3>

<p>Kiro CLI gives you custom agents with scoped tool permissions, steering files for team conventions, native MCP support over stdio and HTTP, hooks, a planning mode that explores changes without touching code, and a headless mode for automation. In a Coder workspace, all of that runs inside the isolation and network boundary you set.</p>

<p>One thing to know up front: Kiro&#39;s model calls go to Kiro&#39;s managed inference and are billed in credits against your subscription, rather than through an API key you hold. You don&#39;t hand the workspace an Anthropic or Bedrock key to manage. That shapes how you govern the AI layer, which we&#39;ll cover below.</p>

<h2>How it works</h2>

<h3>Creating a workspace</h3>

<p>A developer logs into your Coder instance and picks the Kiro template along with any parameters the admin exposes. The workspace comes up with the agent, dependencies, repositories, and controls already in place.</p>

<p><img src="https://www.datocms-assets.com/19109/1782424122-blog_coder-kiro-graphic2.png" alt=""></p>

<h3>Connecting from the VSCode terminal</h3>

<p>Once the workspace is provisioned, launch your local VSCode Desktop from the workspace dashboard:</p>

<p><img src="https://www.datocms-assets.com/19109/1782424154-blog_coder-kiro-graphic3.png" alt=""></p>

<p>Open the workspace terminal in VSCode and run:</p>

<pre><code class="shell">kiro-cli
</code></pre>

<p>Because a workspace is a remote, headless machine, signing in uses Kiro&#39;s device flow. The CLI prints a URL and a one-time code. You open the URL in any browser and enter or approve the code, and the CLI picks up the session. No port forwarding or tunnel setup. For automation, you can authenticate with a KIRO_API_KEY and run the CLI non-interactively instead. API keys are available on paid tiers and can be governed by your Kiro admin.</p>

<p><img src="https://www.datocms-assets.com/19109/1782424185-blog_coder-kiro-graphic4.png" alt=""></p>

<h2>Governing Kiro</h2>

<p>Governance for Kiro on Coder splits across two layers, and it helps to be clear about which system owns what.</p>

<p>Coder governs the environment. Workspaces are isolated from each other, egress is filtered at the VPC and workspace level, identity flows into the workspace through your provider, and workspace activity is audited. This is where you contain what the agent can reach and do.</p>

<p>Kiro&#39;s enterprise console governs the AI layer. From the console, admins can control which models users may select and set a default, govern which MCP servers and web tools are allowed, manage whether users can create API keys, and monitor usage. Authentication supports SSO through IAM Identity Center.</p>

<p>Together these cover the environment and the model-and-tools layer. The one gap to set expectations on is per-prompt and per-token capture, which leads to the question we get asked most often.</p>

<h2>Can you route Kiro through an AI Gateway?</h2>

<p>Short answer: not today.</p>

<p>Coder&#39;s AI Gateway, part of the AI Governance Add-On, works as a proxy between an agent and providers like Anthropic and OpenAI. The agent sends its API calls to a Coder endpoint, authenticates with a Coder token, and Coder forwards the request to the provider. Because it sits in the middle of that traffic, the gateway can record prompts, token usage, and tool calls, and it can inject an approved set of MCP tools.</p>

<p>For that to work, the agent has to let you point its inference at a custom endpoint and authenticate with a custom token. Kiro CLI does not expose either. Its model calls go to Kiro&#39;s managed backend using Kiro&#39;s own authentication, so there is no endpoint to redirect and no provider key to route. The same applies to LiteLLM, which also needs the client to target its proxy with an OpenAI or Anthropic-compatible endpoint. Also tool injection happens on traffic that passes through the gateway, you can&#39;t inject MCP tools into Kiro through it either.</p>

<p>So you govern Kiro&#39;s AI layer in Kiro&#39;s console (models, MCP servers, web tools, and usage), and you use Coder for the environment and network controls around it. If Kiro adds support for a configurable inference endpoint and credentials in the future, the AI Gateway is ready to sit in front of it. The pattern holds either way: the environment is the constant, and the agent is the variable.</p>

<h2>Looking forward</h2>

<p>The bigger shift is running many agents at once. Because Coder workspaces are quick to create and pre-hardened, the same template that gives one developer a Kiro environment can back a fleet of headless agents, each in its own isolated workspace, working through pull request reviews, documentation updates, or a modernization backlog. The governance and network boundary you defined apply to every one of them. Running a group of autonomous agents stops being a power-user trick and becomes a normal way to work.</p>

<h2>How to get started</h2>

<p>You can install Coder Community Edition or start a premium trial and have Kiro CLI running in a governed workspace quickly. Add the install script along with your MCP and steering config to a template, and your team picks it from the list. For a closer look at how Coder fits your infrastructure, reach out to our technical sales team.</p>


Run Kiro CLI safely on enterprise infrastructure with Coder workspaces. Get full agent autonomy without the security risk of running terminal agents on laptops.

Using Kiro CLI with Coder Workspaces

Discover the latest at the official Coder blog: updates, company insights & AI development infrastructure tips for enhanced developer productivity.

Official Coder Blog: AI Development Infrastructure Articles & News

By migrating dev workloads to AWS via Coder, our joint customers centralize and govern the dev experience for both humans and agents.

Coder's AI Stack: Bring Your Own Agent or Run Coder Agents in Governed Environments

How To Set Up Enterprise Development Environments with OpenAI Codex and Coder

Using Kiro CLI with Coder Workspaces

Partners posts

In The Age Of AI, Dev Workloads Are Cloud Workloads