---
title: "Using Kiro CLI with Coder Workspaces - Blog - Coder"
description: "Run Kiro CLI safely on enterprise infrastructure with Coder workspaces. Get full agent autonomy without the security risk of running terminal agents on laptops."
image: "https://www.datocms-assets.com/19109/1782423105-blog_coder-kiro.png?fit=clip&fm=webp&w=800"
canonical: "https://coder.com/blog/using-kiro-cli-with-coder-workspaces"
---

Jun 25 202611 min read

# Using Kiro CLI with Coder Workspaces

[Dave Ahr](https://coder.com/blog/author/dave-ahr)

Share this article

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't go.

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't steeped in sandboxing and least-privilege practices and tend to hand riskier work to the agent.

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.

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.

## Enter Coder

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.

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.

## Reference architecture

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

![](https://www.datocms-assets.com/19109/1782424016-blog_coder-kiro-graphic1.png)

### Infrastructure

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.

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's network. That matters for AWS-aligned and public sector teams, and Kiro supports IAM Identity Center and AWS GovCloud (US) for authentication.

### Templates

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 [Coder Registry](https://registry.coder.com/modules/harleylrn/kiro-cli):

```

```

You bake the agent'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

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.

The root cause is subtle: Kiro's active agent config (`~/.kiro/agents/agent.json`) separates tool _availability_ from tool _trust_. The `tools` array defines what the agent can access, while `allowedTools` controls what runs without prompting. The h`arleylrn/kiro-cli` Coder module writes this file at workspace startup with `shell` in `tools` but not in `allowedTools`, so every shell command still requires manual approval. The fix is a companion `coder_script` resource that waits for the module to finish writing `agent.json`, then uses `jq` to add "`shell`" to `allowedTools` 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.

```

```

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'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.

Add a coder\_parameter for the tarball and wire it into the module. Parameters with default = "" and mutable = true let the user optionally paste their tarball at workspace creation (or edit later).

```

```

Wire it into the module:

```

```

The module's install script extracts the tarball with `tar -I zstd`. Your Coder image may or may not have `zstd` installed. If extraction fails with "`zstd: command not found`", add a `pre_install_script` to install it, but since this image runs as a non-root user with `no_new_privs`, you can't apt-get install. Two options:

1. Bake `zstd` into the image (preferred for production).
2. Use a statically-compiled `zstd` binary in `~/.local/bin`:

```

```

### The agent

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.

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

## How it works

### Creating a workspace

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.

![](https://www.datocms-assets.com/19109/1782424122-blog_coder-kiro-graphic2.png)

### Connecting from the VSCode terminal

Once the workspace is provisioned, launch your local VSCode Desktop from the workspace dashboard:

![](https://www.datocms-assets.com/19109/1782424154-blog_coder-kiro-graphic3.png)

Open the workspace terminal in VSCode and run:

```

```

Because a workspace is a remote, headless machine, signing in uses Kiro'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.

![](https://www.datocms-assets.com/19109/1782424185-blog_coder-kiro-graphic4.png)

## Governing Kiro

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

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.

Kiro'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.

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.

## Can you route Kiro through an AI Gateway?

Short answer: not today.

Coder'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.

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's managed backend using Kiro'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't inject MCP tools into Kiro through it either.

So you govern Kiro's AI layer in Kiro'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.

## Looking forward

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.

## How to get started

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.

[![Dave Ahr](https://coder.com/_next/image?url=https%3A%2F%2Fwww.datocms-assets.com%2F19109%2F1749232303-dave-ahr.jpeg%3Ffit%3Dcrop%26fm%3Djpg%26h%3D100%26w%3D100&w=2048&q=75)](https://coder.com/blog/author/dave-ahr)
[Dave Ahr](https://coder.com/blog/author/dave-ahr)

Staff Sales Engineer

### Subscribe to our newsletter

Want to stay up to date on all things Coder? Subscribe to our monthly newsletter for the latest articles, workshops, events, and announcements.