DEV Community: Kimchi

12 Security Questions Every AI Coding Agent Needs to Be Able to Answer

Kimchi — Tue, 20 Oct 2026 17:29:51 +0000

Originally published on the Kimchi blog by JJ Lim.

Your security team has a questionnaire.

Every vendor gets it, and most AI coding vendors answer it with a trust portal link and a meeting request, not with answers. That's how a two-week review often becomes a two-month email thread.

It's worth noting why this review is harder than a normal SaaS review, because an AI coding agent is not simply a chat window. It has access to read your repository, hold a model of your codebase in context, execute shell commands, and loops: plan, edit, run tests, read the failure, edit again. A single task generates hundreds of model calls, and agentic workloads consume up to 1,000x more tokens than chat queries. So the data path is continuous rather than transactional, there's an execution surface somewhere running commands under some identity, and state accumulates: sessions, compacted context, and work history are data too, the data most questionnaires forget to ask about.

That leaves security with three questions to answer: where does the code go, what controls each request along the way, and where do the agent's commands run.

This post is going to unpack these questions from the perspective of Kimchi.dev - our coding agent that was built with these inherent problems in mind.

Kimchi.dev was built intentionally to separate the system into three components, and your deployment mode determines where each runs:

The inference endpoint controls where the model runs, and therefore where your code and prompts physically go.
The enforcement proxy controls what happens on every request: authentication, policy, budget caps that enforce when configured, and the audit trail. Every request from every agent passes through it. There is no bypass path.
The execution environment controls where the agent reads files, writes code, and runs commands.

This means that because the components are separate, you choose who runs them, and that choice shapes the answers to security's questions. In serverless mode, Kimchi.dev manages inference. In self-hosted mode, all three components run inside your infrastructure, in your Kubernetes cluster, with support for 50+ models including open-weight models you host yourself.

Almost every answer below reduces to "which component is involved, and who runs it."

Here are the twelve questions security actually sends, each answered for Kimchi.dev in plain language you can paste into the questionnaire response unedited. Where the honest answer is "not yet," we say not yet.

This post on the Dynamic Inference Boundary takes a deeper dive on how this works under the hood with Kimchi and other ecosystem tooling.

1. Where does our data reside?

The data resides wherever you put the inference endpoint.

In self-hosted mode, models run in your VPC or on-prem cluster, and session state and traces live there too, so code stays in your infrastructure and jurisdiction, with no second location to audit. In serverless mode, requests go to Kimchi-managed endpoints in documented regions.

2. What egresses our network?

In self-hosted mode, the inference endpoint, enforcement proxy, and execution environment all run inside your network, so the coding path, the one carrying source code, requires no outbound calls to Kimchi.dev. Control-plane traffic such as licensing is a separate, documented, inspectable stream, so your team verifies what it carries rather than trusting us.

3. How long is our data retained?

In self-hosted mode, prompts, completions, and traces are stored in your infrastructure under your retention policy; Kimchi.dev never holds them. In serverless mode, request data is retained for operations and billing for a documented window, and deletion covers derived artifacts such as session summaries, propagating to backups on a documented schedule.

4. Is our data used to train models?

No. Kimchi.dev does not train on customer data, ever. Not prompts, completions, source code, or derived telemetry, and the commitment includes fine-tuning, evaluation sets, and "service improvement," where exceptions usually hide. It holds across every deployment mode and every model behind the platform, contractually. There is no opt-out checkbox because there is nothing to opt out of.

5. How does the agent handle secrets?

The execution environment runs where you choose, so the agent reads only what its runtime identity can read. Scope its credentials like a CI runner's: least privilege, short-lived tokens, no shared service accounts. Because agents can be steered by content they read, containment comes from the environment boundary and controlled egress, not from model behavior.

6. Do we get audit logs?

Yes, and they come from the architecture, not a reporting feature. Every request from every agent traverses the enforcement proxy, producing a per-request trace: who called, which model served it, token counts, per-user cost. An agent cannot reach a model around the proxy, so the log is the activity itself, not a sample of it.

7. Is there RBAC?

Yes. Roles separate platform administration, policy and budget configuration, and day-to-day agent use, so the person setting spend caps isn't the person being capped, and model allowlists are set by policy owners rather than negotiated per engineer. An engineer-role user cannot exceed the budget or reach a disallowed model; the proxy enforces, it doesn't alert.

8. Is there SSO?

Yes. SSO is supported for enterprise deployments, so access follows your identity provider and every request authenticates against it, not just login. Offboarding severs model access, audit attribution, and budget allocation in one motion, which closes the classic CLI-tool failure mode: a long-lived personal API key that keeps working after the engineer leaves.

9. What's the provenance of the models?

You always know which model served a request, because the proxy records it per request, and no model is silently swapped behind an alias, the way closed-model vendors routinely update checkpoints. In self-hosted mode you can run 50+ models, including open-weight models whose weights you download, verify, pin, and host yourself, so provenance is auditable rather than asserted.

10. What's your incident response process?

Security incidents follow a documented response process with defined customer notification commitments, published in our trust documentation. Architecturally, because every request is proxied and traced in a log you own, scoping an incident is a query rather than an archaeology project: you establish exactly which users, models, and repositories were in the blast radius, on your timeline.

11. What compliance certifications do you hold?

SOC 2 Type II. GDPR and DORA by design. HIPAA-ready architecture, with a BAA available on request. FedRAMP Moderate is in progress, not complete; if you need an authorized deployment today, the honest answer is not yet. We don't currently claim ISO 27001 or PCI-DSS, and won't until we can evidence them.

12. Who are your subprocessors?

A current subprocessor list is published and maintained, and it changes with your deployment choice, which is the part worth noticing. For AI coding tools, the heaviest subprocessors are the model providers, the parties that actually receive source code. In self-hosted mode they leave your data path entirely; in serverless mode, the documented list applies.

Three follow-up questions worth sending every vendor

If you're forwarding this page into a parallel evaluation, these are the follow-ups that separate real answers from trust-portal answers, ours included:

Where does the accumulated state live? Residency claims usually cover the inference request and quietly exclude session history, compacted context, and traces, which amount to a detailed map of your codebase. Ask where that state resides, how long it's retained, and whether deletion covers derived artifacts and backups.
Can an engineer-role user exceed the budget or reach a disallowed model if they try? If the answer involves the word "alert," the controls are advisory. Reporting features observe; enforcement points gate. Shadow usage through personal API keys exists precisely where there's no enforcement point.
When the alias updates, does my change-management process see it? Closed-model vendors routinely swap checkpoints behind a stable model name. For anyone who must answer "what logic produced this decision" in an audit, an unversioned alias is an unanswerable question. Pinned, checksum-verified open weights are a different evidence class.

Why these answers differ from the tools you're already evaluating

If you're running this questionnaire against GitHub Copilot, Claude Code, or Cursor in parallel, the answers to questions 1, 2, 9, and 12 come out structurally different, because the architectures are different:

GitHub Copilot can't self-host and isn't available on GitHub Enterprise Server, so residency and egress answers are Microsoft's cloud, full stop. FedRAMP and data-resident deployments carry a 10% model multiplier penalty, so meeting the compliance requirement raises the price of every request.
Claude Code offers no fully self-hosted inference. Even the self-hosted gateway still routes to Anthropic's cloud-hosted models, so the data residency answer ends at Anthropic's infrastructure regardless of where the gateway sits, and Anthropic's documentation states there's no offline or local model support.
Cursor is cloud-only SaaS. All traffic routes through Cursor's backend, which means the security answer to most of these twelve questions is someone else's architecture. And that architecture can change mid-contract without your approval: Cursor's OpenAI model access is being cut off on November 12, 2026 following its acquisition, changing the upstream half of its customers' data path under them.

None of this makes those tools bad agents. It means that for most of the twelve questions above, their answer is fixed by their architecture, and yours has to be "we accepted that." With Kimchi Coding, the deployment mode is your call, so the answers are too.

The part your security team already suspects

The market spent the first half of 2026 proving that ungoverned AI coding is a liability. One enterprise hit a $500M single-month Claude bill (Axios, May 28, 2026). Microsoft revoked Claude Code licenses running $500 to $2,000 per engineer per month (Axios, May 2026). Uber burned its entire 2026 AI budget by April (Fortune, May 26, 2026). Those read as finance stories, but look at the mechanism: requests nobody could see, attribute, or stop. That is a security issue, and is compounded by the business liability. The same missing control point that let spend run unbounded is the one that would let data move unobserved.

That's why the enforcement proxy alone answers half this questionnaire. Audit completeness, cost attribution, identity-bound access, provenance, incident scoping, budget caps that enforce when configured: they all originate from one architectural decision, that no request reaches a model without passing through a control point you can inspect. Everything downstream of that decision is a query, while everything upstream of it is trust.

Forward this page to your security team, and if they have a thirteenth question, we'll answer that one straight too.

Kimchi.dev is made by the creators of CAST AI. Kimchi Coding runs serverless or self-hosted in your Kubernetes cluster: docs.kimchi.dev · github.com/getkimchi/kimchi

Sources: Axios (May 28, 2026; May 2026), Fortune (May 26, 2026), Anthropic documentation (Claude Code offline/local support), Bloomberg/CNBC/TechCrunch (Cursor acquisition and OpenAI model access cutoff, Nov 12, 2026), GitHub Copilot enterprise documentation (GHES availability, FedRAMP/data-resident model multiplier).

The Dynamic Inference Boundary: AI Coding Is Moving Into the Enterprise

Kimchi — Tue, 20 Oct 2026 17:29:14 +0000

Originally published on the Kimchi blog by Lachezar Tsonov.

AI developer tools are simple to deploy when the architecture looks like this:

developer → SaaS API → model

At enterprise scale, the story is different. The question is no longer which model produces the best results. Data flows and data residency become increasingly important, especially as models become more interchangeable. The deployment of those models needs to follow suit.

Security and infrastructure teams need to know where source code is processed, which network boundaries it crosses, who operates the infrastructure, and whether the system can function without public network access. Regulatory and compliance requirements become non-negotiable in certain environments. The challenge is that workloads evolve over time - while managed infrastructure is a good start, moving to a private network or disconnected environment might be required later and this might not be obvious from the get-go.

The agility of deployment therefore becomes a first-class property of an AI development platform.

"Self-hosted" hides several different boundaries

Self-hosted is a familiar, but misleading term. Similar to a decade ago, where on-premise vs cloud was too broad a comparison, we cannot just say "just self-host it!" and call it a day. There are at least three relevant boundaries to define:

Execution boundary. Where do repository checkouts, shell commands, builds, tests, MCP servers, and other tools execute?
Agent boundary. Where does the agent loop select context, orchestrate model calls, and process tool outputs?
Inference boundary. Where does the model itself execute?

These are not equivalent.

Moving execution into a customer's Kubernetes cluster keeps builds and tools inside the customer's network while source code and context still leave the perimeter for agent processing or inference.

Cursor's self-hosted workers illustrate the distinction. Repository checkout and tool execution can run on customer-operated infrastructure, while the agent loop and inference remain in Cursor's cloud.

The execution is local and can operate within a safe area, inference and agent loops are outsourced to the vendor. A good compromise but very little is actually won in terms of data control.

Data residency moves another boundary

Keeping execution inside the customer environment is one level of control. Another is constraining where external processing can happen.

GitHub Copilot provides a useful example. GitHub Enterprise Cloud customers with data residency can enforce regional processing for Copilot. With the policy enabled, GitHub routes inference to model endpoints within the enterprise's designated region, and code, prompts, responses, logs, and telemetry associated with Copilot remain in-region. Requests processed under this policy consume 10% more AI credits.

This addresses an important class of regulatory and data-sovereignty requirements without requiring the customer to become an expert in inference infrastructure. It adds control over where processing occurs. It also keeps the operational simplicity of a SaaS while ensuring data does not randomly change country jurisdictions. But it still keeps the inference boundary intact - data still crosses into the vendor's perimeter.

So what if geography is not enough? What if inference itself must happen inside customer-controlled infrastructure?

That moves us from:

application → regional endpoint → model

to:

application → internal endpoint → customer-hosted model

And that changes the game entirely.

The disconnect-my-internet test

Let's reduce the question for customer-hosted models to another problem: the whole system must operate without connectivity to a vendor or the public internet.

There is a simple question to test this:

Remove any access to outside networks. Can the application, agent, and model still perform the required workflow?

If not, the system may provide strong privacy or residency guarantees, but it still depends on external infrastructure. Even a seemingly harmless external dependency, such as license verification or telemetry, breaks the isolation guarantee.

A fully isolated deployment requires the components needed to process requests, including inference, to exist inside the customer's network boundary. This is the real self-hosted solution and it removes a whole category of problems and regulatory checklist headaches.

Sounds too good to be true? That's because it is. Running inference effectively is hard. Fine-tuning model serving, deployments and caches requires specialized skillset and knowledge, which often requires additional hiring and training. The smart architect postpones this decision until it actually matters and provides some benefit, choosing the simplest possible solution until then.

Make the inference boundary movable

The deployment requirement an application has today may not be the one it has two years from now.

A team might start with managed inference because it requires no GPU infrastructure. Later, the same workload may need to run inside a regulated environment. Another deployment may need to operate without external connectivity because it is now trying to be compliant with health or federal laws.

The difficult part is not supporting each environment independently. It is moving between them without turning deployment policy into an application rewrite every 6 months.

This is the architectural constraint Kimchi is designed around.

Kimchi keeps the inference interface consistent while allowing the infrastructure behind it to change:

Serverless runs inference on Kimchi-operated GPU infrastructure, with the added benefit of choosing regional endpoints interchangeably, while agents can use local harnesses for private execution or keeping the loop local.
Self-hosted moves inference into the customer's Kubernetes environment, for a self-contained deployment.

The important property is what remains intact between those two. The application continues to use the same API and SDK contract. The Kimchi harness operates the same way. Moving from managed to self-hosted inference primarily changes where that API endpoint resolves, rather than how the application integrates with inference.

Choose the best infrastructure fit, but don't tailor the whole application architecture around it. That is the real enterprise AI solution.

Keep Claude Code, Cursor and the rest of your stack. Put Kimchi's proxy in front.

Kimchi — Tue, 20 Oct 2026 17:28:41 +0000

Originally published on the Kimchi blog by Gaurang Singh.

Our own engineers never gave up Claude Code. What changed is the path underneath it. Their Claude Code traffic runs through Kimchi, and the Kimchi console caps each person's Anthropic spend while open models are effectively unlimited. The cap started at $400 a month. One engineer called it "like being on a diet while having a fridge stacked with ice cream." In August we cut it to $200. Last month's usage said it would touch about one in five of us.

Customers tell us the same thing from the other side. A platform lead at a 300-engineer Cursor shop put it plainly: "I don't think 300 engineers are going to put in that much effort if it's difficult."

That's the point of this post. Platform teams rarely win the argument about which agent engineers use, and they don't need to. Point Claude Code, Cursor and most other agents at Kimchi's endpoint, and every request gets per-user cost attribution and a budget that holds. Nobody switches tools.

What sits in the middle

Kimchi becomes the endpoint behind the tools your team already uses. Every request that comes through is processed in four stages:

Authentication, via control plane identity
Rate limiting, via control plane governance services
Budget evaluation, via the same governance services
Model routing, which chooses the right model and returns the response to the agent

On one side: Kimchi's own agent and Studio, headless agents like Ops, Code Reviewer and SRE, and every non-Kimchi client: Claude Code, Cursor, Cline, Windsurf, OpenCode, Zed, your own apps. On the other: GLM 5.3, Kimi K3, MiniMax M3, DeepSeek, Anthropic, OpenAI, Google.

One key routes any model. All tool usage lands in one dashboard. Spend caps apply per team and per key. Analytics, limits and alerts come with it.

Set up Claude Code with Kimchi's proxy

You'll need Claude Code v2.1.242 or later. Claude Code reads its endpoint from ~/.claude/settings.json. Create an API key at app.kimchi.dev and add two lines. If the file already has an env block, add these keys to it rather than replacing it.

{
  "env": {
    "ANTHROPIC_BASE_URL": "https://llm.kimchi.dev/anthropic",
    "ANTHROPIC_AUTH_TOKEN": "YOUR_KIMCHI_API_KEY"
  }
}

Start a session. The request shows up in the Kimchi console under your key straight away.

Claude Code now signs in with your Kimchi key, so it runs on API access rather than a Claude Max or Team seat. Claude chat and the desktop app stay on your existing plan.

To choose Kimchi's models from /model, add a picker to the same file:

"model": "glm-5.3[1m]",
"modelPicker": {
  "options": [
    { "model": "glm-5.3[1m]", "label": "GLM 5.3 (Kimchi)" },
    { "model": "glm-5.3-flash[1m]", "label": "GLM 5.3 Flash (Kimchi)" },
    { "model": "minimax-m3[1m]", "label": "MiniMax M3 (Kimchi)" },
    { "model": "kimi-k3", "label": "Kimi K3 (Kimchi)" }
  ],
  "replaceBuiltInOptions": false
}

[1m] tells Claude Code the model has a 1M-token context window. Claude Code strips it before the request goes out. replaceBuiltInOptions: false keeps Anthropic's models in the list next to Kimchi's.

Having both in one picker is how our own engineers work: plan with Claude, build with GLM, verify with Kimi.

Your CLAUDE.md files, hooks, skills, MCP servers and the VS Code and JetBrains extensions keep working. They all read the same settings file.

Set up Cursor with Kimchi

You'll need Cursor Pro or above. The free tier can't use a custom API key. Go to Settings → Models → API Keys:

Turn on OpenAI API Key and paste your Kimchi key.
Turn on Override OpenAI Base URL and set it to https://llm.kimchi.dev/openai/v1.
Add the models as kimchi/kimi-k3 and kimchi/minimax-m3. The prefix is required, because Cursor ships built-in models with the same names.

Chat and Agent now run through Kimchi, and that's where long agentic sessions spend most of their tokens. Tab autocomplete, inline edit (Cmd+K) and Composer stay on Cursor's backend and your Cursor plan. So does Cursor's own Auto mode: to route through Kimchi, pick a kimchi/model.

Two things to know. Cursor caps third-party models at 200K context, whatever the model supports. And if a model that worked yesterday suddenly returns "model not found", check the API key toggle. Cursor sometimes switches it back off.

Cost attribution, and caps that enforce

Kimchi prices every request at the proxy from the model and the actual token counts. You get spend per user, per team and per API key in real time, in one console, across every tool you've pointed at it. Developers hold a Kimchi key, never a raw Anthropic or OpenAI key, so there's one place to issue and revoke access.

Neither tool gives you that on its own. Claude Code has no native real-time per-user attribution, so you'd build an OpenTelemetry pipeline to get it. Cursor reports requests and lines changed, not dollars, and bills in arrears.

To slice spend by project or team, tag the requests. For Claude Code:

CLAUDE_CODE_EXTRA_BODY='{"tags": ["team:payments", "project:checkout"]}' claude

Attribution tells you where the money went. Caps decide where it can go. One team we work with found an engineer had left an agent loop running overnight. It burned about $150 before anyone looked.

Budgets go on the organization, a team, a user or an API key, and on each provider separately. When one runs out, the next request doesn't execute. This is what a developer sees in Claude Code:

Error: 429 "API key has reached its spend limit.
Increase the budget in the console or contact your organization admin to continue."

Running out of Claude budget doesn't have to stop work. Set a fallback, and requests drop to an open model instead.

Want staging on a tighter budget than production? Give each environment its own key and its own cap. For more on why caps that enforce beat alerts that notify, see Assaf's post on the $500M bill.

The governance suite is the best we've seen in the market. Data sovereignty, cost observability, and budget control in one place.

Dekel Shavit, Senior Director of Engineering, Akamai

What it costs

Moving Claude Code traffic onto open models is where the savings show up. Across more than 150 Cast AI developers, Claude Code costs fell about 60% in the first two weeks.

Our two-day internal hackathon ran on Kimchi's open-source models for about $4.4K. The same workload on a frontier mix (80% Claude Sonnet 5, 20% Claude Fable 5) models out at about $58K, roughly 1/13th the cost.

Traffic you keep on Anthropic, OpenAI or another provider passes through for $0.20 per million input tokens and $0.30 per million output tokens on top of the provider's price. Cached input is free. Full details on Pricing.

The rest of your stack

No migration: Kimchi becomes the endpoint behind the tools your team already uses.

Tool	How it connects
Claude Code	Anthropic-compatible endpoint: llm.kimchi.dev/anthropic
Cursor	OpenAI-compatible endpoint: Chat and Agent, Pro and above
Codex CLI	OpenAI-compatible endpoint, or `kimchi setup-tools`
Cline	OpenAI-compatible endpoint
OpenCode	OpenAI-compatible endpoint
Continue	OpenAI-compatible endpoint
Windsurf	Through the Roo Code extension (Windsurf's own BYOK only takes Anthropic models)
Zed	Kimchi runs as a native ACP agent

Kimchi also plugs in here:

One-pass setup. kimchi setup-tools configures Claude Code, Cursor, OpenCode, Codex CLI, Windsurf, Zed, Cline and OpenClaw in a single run. If Cursor is open, quit it fully first and reopen it after. Docs
Kimchi VS Code extension. On the Visual Studio Marketplace, with tabbed sessions across models.
JetBrains IDEs. IntelliJ, PyCharm, GoLand and the rest of the family run Kimchi as an ACP agent.
Any ACP agent. kimchi --mode acp works in any editor that speaks the Agent Client Protocol. Docs
Your MCP servers. Jira, GitHub, GCP and the rest keep working through Kimchi.
Code reviewer. Mention @getkimchi review on a GitHub pull request or GitLab merge request. Review spend counts against the same budgets. More
Kimchi Studio. A desktop app, in early access, for people who'd rather not open a terminal. Docs

Start with Kimchi on Claude Code

Two lines, one key, one session, and the first request is in the console. Guides for every tool above are at docs.kimchi.dev/docs/setup-recipes. When you're ready to put budgets on the whole team, book a call.

Gaurang Singh is Field CTO APAC at Cast AI.

We ran DeepSeek Harness against Kimchi on the same model. It lost by 22 points

Kimchi — Tue, 20 Oct 2026 17:27:47 +0000

Originally published on the Kimchi blog by Matas Kaminskas.

DeepSeek Harness (dsh) came out on August 13, 2026. Seven weeks later it has 239,003 GitHub stars and 28.7k forks.

So naturally we had to run it against Kimchi.

What we ran

dsh is DeepSeek's open-source agent runtime. The model adapter, tool registry, session log, and the agent loop itself are all plugins. It ships four presets - named compositions of tools, prompt, and persona, picked per session. We tested three: minimal (two tools and a one-sentence system prompt), standard (the full agent with all tools, planning, delegation, and web access), and creator (standard plus tools that can modify the runtime it runs on).

The setup:

Same model in both harnesses: GLM 5.3 flash
Terminal-Bench, official methodology: five trials per preset, average pass rate
All runs at maximum reasoning

Why GLM 5.3 Flash and not a DeepSeek model? That's a great question, and there are two reasons. First, this is a harness comparison. The model has to be identical on both sides, or you're measuring two things at once.

Second, there are public claims that DeepSeek models post inflated Terminal-Bench scores, and we didn't want the model choice settling the fight before it started.

The numbers

Run	Score	Cost	Cost per point
Kimchi	69.4%	$36.03	$0.52
dsh creator preset	47.1%	$27.50	$0.58
dsh minimal preset	46.9%	$26.60	$0.57
dsh standard preset	44.0%	$25.80	$0.59

Kimchi passed 69.4% of tasks at $36.03. The best dsh preset passed 47.1%. That's a 22.3-point gap on the same model.

Then there's the spread inside dsh itself. Same model, same benchmark, three presets: 44.0% to 47.1%. The composition alone moved the score by three points. A benchmark number without the harness named is half a number.

The interesting one is minimal. Two tools, no compaction, and a system prompt that is one sentence: "You are a helpful software engineer assistant." It scored 46.9% - three points higher than standard, the full agent with every tool enabled.

We ran a similar comparison in August - Cursor, Claude Code, Opencode, and Kimchi on the same model - and the spread between harnesses was 13 points. The pattern holds: the harness is part of what's being measured.

Methodology

Terminal-Bench, official methodology, five trials per dsh preset (minimal, standard, creator), average pass rate, all runs with GLM 5.3 flash at maximum reasoning, in October 2026. Same conditions for the Kimchi run. Model choice based on inference resilience in our prior testing.

Try Kimchi free at app.kimchi.dev, or read our previous harness comparison: Same Model, Different Results: What Actually Separates AI Coding Agents.

Why Agentic AI Governance Can't Be Bolted On

Kimchi — Wed, 30 Sep 2026 21:03:44 +0000

Originally published on the Kimchi blog by Roman Leliukh and Patrick Pichler.

People often compare the AI revolution to the Industrial Revolution. We share this point of view.

Steam engines spread because they worked, not because they were safe. After repeated boiler explosions, the U.S. created a federal inspection system in 1852; Britain followed with its Boiler Explosions Act in 1882.

The thing is:

Safety systems do not arrive before a technology, they arrive when a technology is already in use.

People used to smoke on airplanes. Cars came before seatbelts. Motorcycle helmets were not widely required until the late 1960s. Cloud infrastructure came before most companies understood identity sprawl, shared responsibility, or how many production credentials were hiding in config files.

Images: Explosion of the steamer Sultana, 1865 (Library of Congress, public domain); vintage car interior (MyStarCollectorCar); motorcycle, Rotterdam, 1930s (M.A.J. Hanse / Stadsarchief Rotterdam, CC BY 4.0).

Technology spreads first. Safety catches up later.

Humanity is not doing great at learning from its mistakes, so the AI Revolution, so far, follows the same pattern.

Kimchi exists to break the pattern. Agentic AI governance can't be bolted on once agents are already in production; it has to be built in from day one.

Agents need a workplace

You've heard those marketing takes like "hire an AI agent" many times before.

Not chatbots. Not autocomplete with terminal access. Coworkers (no coincidence was intended; or was it?)

The "AI coworker" analogy is more than marketing.

An agent has a task. It uses company tools. It accesses systems and data. It can act for a developer, a team, or the organization. And it can make changes with real consequences.

That raises a practical question:

If an agent is a coworker, where are its identity, manager, job description, access badge, work area, activity record, and offboarding process?

Humans do not receive a master key and a note saying, "Please only enter the rooms relevant to your job."

They get an identity. Their badge opens specific doors. Their access is logged. Their permissions can change. When their job ends, the badge stops working.

Agents need the same operating model.

Governance is not a feature added after an agent has access.

It is the workplace the agent operates in.

What a governed AI agent run looks like

A basic agent run looks like this:

Reasoning → Agent decisions → Execution → Output

While a governed agent run is:

Agent identity → Inference → Agent decisions → Authority → Secure execution → Evidence

The difference is not cosmetic. Each added step closes a gap that standalone products commonly leave open:

Step	Common building blocks	What governs it
Agent identity	Workload identity, SSO, service identity	Who is acting, for whom, and in which context
Inference	AI gateway, model router, self-hosted inference	Which models can process the task and where data goes
Agent decisions	Controlled agent harness	How the agent plans, retries, and calls tools
Authority	AI control plane and policy engine	Which actions, tools, data, and destinations are permitted
Secure execution	Isolated cloud workspaces	Where the agent runs and what it can reach
Evidence	Audit, traces, and observability	What happened, what policy applied, and why

You might have some of those components already, but an agent is either governed or not; it cannot be "governed to an extent."

For any agent run, enforcement is binary: either policy governs the full path from reasoning to execution, or there is a gap between what policy says and what the agent can actually do. And agents are exceptionally good at finding those gaps, all while trying to be helpful.

Agent identity

If agents are coworkers, they need an identity.

Humans have email addresses, directory accounts, and roles. An agent needs a unique workload identity tied to its user or service account, organization, project, runtime, and session.

Kimchi uses SPIFFE/SPIRE-based workload identity so an agent run can receive a short-lived, verifiable identity. That identity becomes the foundation for scoped access, policy enforcement, and attributable evidence.

Inference

Inference is where the agent's task data reaches a model.

For sensitive work, self-hosted inference can keep code, prompts, and context within customer-controlled infrastructure. But model sovereignty alone is not governance. A self-hosted model can still power an agent with broad credentials, unrestricted network access, and no evidence trail.

The goal is flexibility at the model layer (commercial, open, or self-hosted models) without losing control or getting LLM provider lock-in.

Kimchi Inference gives you that flexibility. It serves production-ready open-source models through OpenAI-compatible APIs, either as a hosted serverless API or self-hosted in your own cloud when compliance or cost demands it. Your agents get the right model for each task, and you decide where the data goes.

Authority

Reasoning is not authority.

Agents, including the Kimchi Coding agent, call tools, read and write to repositories, and reach APIs. Policy decides whether they can.

Authority defines approved tools, MCP servers, repositories, credentials, network destinations, budgets, and approval requirements. A control plane (in Kimchi, the governance perimeter) enforces those policies when an action happens, not through a "please don't merge" prompt.

Do you use an AI Control Plane today? How do you enforce what agents can or cannot do?

Secure execution environment

A developer laptop is a terrible agent runtime. Period.

It contains accumulated sessions, SSH keys, .env files, credentials, internal data, and access collected over time. If an agent escapes a local sandbox, it escapes into an environment full of real authority.

Agents should execute in isolated cloud workspaces with task-scoped access, restricted networking, no inherited developer state, and kernel-level isolation. Kimchi Remote Workspaces provide this execution boundary.

Workspaces should be cattle, not pets.

A persistent workspace accumulates files, credentials, and risk until it starts looking like another developer laptop. A governed platform periodically replaces it with a clean, reproducible environment rather than allowing hidden state to accumulate indefinitely.

Evidence

A governed agentic AI platform needs tamper-evident evidence of who initiated a run, which agent acted, what policy applied, which models and tools were used, and why an action was allowed, denied, or escalated.

Systems fail. When they do, Kimchi's audit trail lets teams reconstruct the run, understand what went wrong, and fix the policy, integration, or agent behavior behind it.

That is the difference between an agent that can act and an agent that can be operated.

Governance will become unavoidable

Security, convenience, and cost-effectiveness are not the only reasons to build this way.

Regulation is catching up.

OWASP's Top 10 for Agentic Applications identifies risks such as tool misuse, identity and privilege abuse, supply-chain weaknesses, memory and context poisoning, and cascading failures. These are not gateway-only or sandbox-only problems. They span the full agent run.

The EU AI Act is also applying in phases. Rules for certain high-risk AI systems are scheduled to apply from December 2027, with other obligations phased in separately. Not every coding agent is automatically high-risk, but organizations operating agents in regulated or sensitive contexts will increasingly need to demonstrate control, oversight, record-keeping, robustness, and security.

The point is not that every company should panic about compliance tomorrow.

It is that the technical foundations needed for responsible agent operations (identity, authority, secure execution, and evidence) are the same foundations that make future governance and compliance achievable.

Build them now, before agents become too embedded in critical work to retrofit safely.

Book a Kimchi demo

The $500M Bill Was Always Going to Happen

Kimchi — Thu, 24 Sep 2026 19:59:45 +0000

Last July, a unit conversion error in Cost Explorer started showing customers bills in the billions, some in the trillions. A student in Delhi watched a $1.28 monthly bill turn into $10.9 billion. Someone's normal five-dollar month became $1.7 billion. Nobody was actually charged. It was bytes read as gigabytes, a decimal point in the wrong place, and AWS fixed it within a day.

But for a few hours, a lot of engineers sat there staring at a number that made no sense, refreshing the page, waiting for it to resolve itself into something sane. Some, in a panic frenzy, started to delete infrastructure before AWS even confirmed it was a display bug.

That's what such an impossible number does to you. It doesn't just cost money, it produces a specific kind of panic, the kind where you're genuinely unsure if you still have a company.

Now imagine you log in and see that number, and it's not a bug. It's 100% real. That's where AI coding spend is headed in a tokenmaxing reality.

Not because someone fat-fingered a decimal.

Because the controls to stop a runaway bill exist, sitting in a dashboard somewhere, and almost nobody turns them on. AWS's bug got a fix and a "slight calculation error" tweet within a day, because someone was on the other end who wanted it gone. Nobody's coming to save you from your $500 million number, because nothing's broken. The number is real, and it's real because the system was built to let it get that large - it's a feature, not a bug.

Alerts don't stop anything

That's the whole story of AI coding cost governance in a nutshell, right now. The controls are available, they just don't enforce anything - so having the features "available" will not help your next invoice.

Most budget tools don't actually stop anything when you hit a limit. What happens instead is a Slack ping, a red badge on a dashboard, an email telling you that you've crossed 80 percent of your monthly allowance.

But the outcome stays the same - the tokens keep flowing exactly as before. That's not a control, it's a smoke detector that watches the house burn and files a report after the fact. An alert tells you spend crossed a line.

A very important distinction, though, is that a cap stops the spend at the line. Those aren't two versions of the same feature, they're different categories of tool. Security teams learned this distinction the hard way long before cost governance had to. Knowing you have a thousand open CVEs doesn't stop a breach in real time. Information isn't the same as enforcement, and a budget tool that only tells you what happened is making the same mistake a vulnerability scanner makes when it's treated as a defense instead of an inventory.

Vendors like to ship alerts because alerts demo well and it rolls the responsibility onto the receiver. Set a threshold, trigger a notification, and everyone in the room nods like something was just solved. But an alert has no authority to stop a request from executing. Put 150 engineers on frontier models through an agent all day and the gap between "you're at 80 percent of budget" and "you blew past it hours ago" closes faster than any human is going to react to a notification. The alert still fired right on schedule, but the spend it's describing already happened hours ago.

That's the shape of the $500M bill, without fail. Every. Single. Time.

So let's actually look at how the big tools handle this Because the devil is always in the details - and often where the whole thing falls apart.

Copilot. There's a governance dashboard, and it looks the part. But "stop usage" is off by default. Budgets act as alerts unless someone explicitly hardens them. Metered usage is on by default. Credits get forfeited monthly, used or not. In a demo you see a ceiling. In production you get a speedometer that watches the overage happen.

Claude Code. Seat allowance isn't metered in dollars until you opt in to usage credits. And there's no native, real-time, per-user attribution. Want to know which engineer or which key is torching the budget right now? You're building your own OpenTelemetry stack to find out. The controls to prevent a runaway bill were available. They weren't enforced. That's the $500M incident in one sentence.

Cursor. You get usage analytics. Requests, diffs, lines of code. What you don't get is dollar attribution. Billing runs in arrears, so there's no hard ceiling by design, just an invoice that shows up after the damage. And real cost governance is locked behind the Enterprise tier, so the teams most likely to overspend early are the ones least likely to have guardrails.

See the pattern?

Every one of these vendors can say, with a straight face, that governance is "available," yet every single one of them enjoys the outcomes when enforcement is left as something you opt into, harden yourself, or upgrade to reach.

OK, so what does "governance that enforces" actually mean? Here's the bar I'd hold any tool to before I put my company's card behind it, and it consists of two pretty simple things:

1. A hard budget caps at every level. User, team, API key, org. Not thresholds that ping. Caps that enforce when configured.

And I want to be specific about what "enforce" means, because this is exactly where the devil we mentioned earlier lives. In Kimchi Coding, every inference request runs through the proxy, and the proxy checks it against the budget before it runs. If you're at or over your limit, you get an HTTP 429 back and the request never executes. The tokens never leave the building, spend is stopped in its tracks. That's a cap.

If it doesn't stop the request, it's an alert wearing a cap's clothes.

The caps cascade, with the org setting the ceiling and team, user, and API key limits nesting underneath it. Whichever scope is tightest wins, and a per-model limit still binds even when it's stricter than everything above it. That's what stops a service account on a CI runner from quietly outspending the whole org just because nobody remembered to set a limit on it specifically.

2. Per-user cost attribution, in real time. You should be able to see, right now, what every user, team, key, and org is spending. Not reconstruct it next week from logs.

And it should be real because of how it's built, not because of a dashboard someone bolted on. The cost gets computed at the proxy from the model plus the actual token counts as requests flow through. For per-team visibility, tag requests with a team header and the teams show up on their own. No unnecessary admin setup, or config screens, no pre-registering every squad. First tagged request arrives, the team exists, and it works across the agents your engineers already use.

Put those two together, per-user cost attribution and hard budget caps, and you've got a governed AI coding platform instead of a dashboard.

Let me bust one myth here, because I'd rather you hear it from me than find out the hard way. "Governed" means the governance is built and ready to enforce, not that it's already running before anyone's touched it. The caps aren't on the moment you sign up. They're available from day one, and turning them on is part of the setup, the same way you'd configure any other control before trusting it. That distinction matters, because the tools that oversell "default" governance are the same ones whose customers end up with the surprise invoices.

Our own bill is the proof

The proof of the pudding is in the eating - so preaching enforcement as a vague idea is easy. Here's the pudding instead. And we ate our own pudding.

CAST AI runs 150 engineers on this setup, generating roughly 36 billion tokens a month of real agent work, not a benchmark. Measured over a 30-day window against a 100 percent Anthropic Sonnet and Opus baseline, the result was 12x cheaper than going frontier-only, with the same engineers doing the same work, held to the same bar for output quality.

That 12x didn't come from switching to a cheaper model, and it didn't come from silently degrading what people get back either. It came from smart routing combined with governance that actually works. Enforce the caps and keep attribution real-time, and you stop paying for the runaway tail, the part that turns a normal month into a board-level problem.

Kimchi Coding is built by the same team behind CAST AI, and the bill we cut for ourselves was our north star, before we ever shipped a product to anyone else. We also don't train on other people's data, ever. Sovereignty to us isn't a slideware feature, it's the fundamentals of how the product is built.

The part everyone gets backwards

The pushback I hear constantly is that governance is always synonymous with friction and it sounds like it's built to slow developers down. It isn't, and framing it that way is how you end up building the wrong control and losing your engineers in the process.

Developers don't care about your budget dashboard. What they do care about is whether the agent is good enough to trust with real work, and that's a non-negotiable gate on its own. If the agent isn't genuinely good, nothing else matters.

Governance sits on a different axis entirely.

It's the buyer's problem, not the developer's, and the split is clean: your engineers get the best agent available, and you keep control of the bill. Those two things were never actually in contention. The tools that made them feel that way did it by making enforcement expensive or optional, which left degrading the developer experience as the only lever they had for controlling cost. Caps that enforce at the org, team, key, and user level let you protect the invoice without your developers ever noticing.

AWS had a bug. Your exorbitant bill is largely a feature for your AI coding agent, sitting there by design, unconfigured, waiting for enough volume to make it a business emergency.

So if you're picking an AI coding tool this quarter, ask the vendor one question and make them answer it straight: when a team hits its budget, does spend actually stop, or does someone just get told, after the fact, that it didn't? Everything else is detail.

Caps that enforce, not alerts that only notify. Real-time attribution you don't have to build yourself. The best agent your engineers will actually use, and a bill you actually control.

See how Kimchi Coding does it at Kimchi.dev.