Back to blog

    Why Agentic AI Governance Can't be Bolted On

    Posted inPerspective@ September 28, 2026by Roman Leliukh & Patrick Pichler- 7 min read

    Safety systems never arrive before a technology - they arrive when it's already in use. Agentic AI is following the same pattern, and governance can't be bolted on once agents are in production. It has to be built in from day one.

    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.

    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

    What a governed AI agent run looks like - governance covers every step of the run

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

    • Agent identity - common building blocks: workload identity, SSO, service identity. What governs it: who is acting, for whom, and in which context.
    • Inference - common building blocks: AI gateway, model router, self-hosted inference. What governs it: which models can process the task and where data goes.
    • Agent decisions - common building blocks: controlled agent harness. What governs it: how the agent plans, retries, and calls tools.
    • Authority - common building blocks: AI control plane and policy engine. What governs it: which actions, tools, data, and destinations are permitted.
    • Secure execution - common building blocks: isolated cloud workspaces. What governs it: where the agent runs and what it can reach.
    • Evidence - common building blocks: audit, traces, and observability. What governs it: 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.

    Kimchi across the run - SPIFFE/SPIRE identity, Kimchi Inference, Kimchi Coding agent, governance perimeter, Remote Workspaces, audit trail

    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

    Build with governed AI coding.

    Install Kimchi, connect your coding tools, and keep control from the first request.