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.
Top comments (1)
The "either governed or not, no partial credit" framing is the sharpest point here, and it's also where most bolted-on governance quietly fails: a policy engine sitting beside the agent, reviewing logs after the fact, can tell you a gap existed — it can't close it before the tool call runs. The two steps I'd want to see split apart even further are "Agent decisions" and "Authority," because in practice they collapse into the same moment: the harness decides to call a tool, and unless the authority check is synchronous and blocking at that exact call site (not a sidecar watching traffic), there's a window where the agent can act on its own decision before policy catches up. That's the difference between "we have an audit trail showing what the agent did" and "we have a mechanism that made the disallowed thing physically not happen." The evidence column matters a lot for the postmortem, but it's authority-at-the-call-site that prevents the incident in the first place. Curious how Kimchi's policy engine enforces at that boundary — is it intercepting the tool call itself (in-process, like a hook), or sitting at the network/API layer between the agent and the systems it reaches?