How Companies Govern Agentic AI: From Policy To Runtime Enforcement

---

In a hurry? The executive brief of this article — “Before Your AI Agent Acts” — is a four-minute read.

AI agent governance connects a declared policy to the exact place where identity, authority, money, code, data, and side effects become real. Output controls, action policy, observability, and runtime boundaries are complementary parts of that one system.

This is the second article in KDCube's opening industry series. The first, AI Agent Infrastructure: The Runtime Around Your Framework, explains how a production runtime can surround an existing agent and product without replacing them. This article follows the harder question: how does that runtime turn governance intent into enforceable behavior?

An agent can generate an acceptable answer and still use the wrong account. It can propose an allowed tool and still exceed the user's budget. It can pass an output validator while generated code inherits more network or filesystem access than the task requires.

These are different governance questions. Companies govern agentic AI well when they connect each question to an enforceable boundary:

This is why AI agent governance is broader than a prompt filter or a monitoring dashboard. Policy expresses intent. Runtime enforcement gives that intent operational force under concurrency, failure, retries, and adversarial input.

The NIST AI Risk Management Framework describes governance as a cross-cutting function across mapping, measurement, and management. The same principle applies at the software boundary: one control does not carry the whole system. A useful governance architecture joins several controls and makes their handoffs explicit.

01 Three control layers work together

A practical agentic AI governance framework has three technical control layers. Evidence and organizational review run across all three.

1. Interaction controls

Interaction controls govern what enters and leaves the model interaction:

• input safety and prompt-injection detection
• retrieval filtering and sensitive-data handling
• structured output validation
• topic, content, and response policy
• model evaluation and quality checks

These controls reduce unsafe or malformed model behavior. They are especially valuable because they can stop a bad request before generation or prevent a bad response from reaching a user.

2. Action and authority controls

Action controls govern what the agent may ask the system to do:

• tool and operation allowlists
• argument-schema and protocol validation
• human approval for selected actions
• user, app, role, grant, and resource policy
• connected-account consent and provider claims
• ordering rules for multi-action decisions
• retry and idempotency requirements for side effects

This layer turns a model proposal into a governed request. The model may propose an action; an identity-aware runtime decides whether the current actor may use that operation on that resource.

3. Runtime and resource controls

Runtime controls govern the environment in which accepted work executes:

• process, container, network, and filesystem boundaries
• secret and credential placement
• cost admission, reservation, and settlement
• storage ownership and user scoping
• queue, event, turn, and concurrency ownership
• cancellation, timeout, file-size, and workspace limits
• failure reporting and recovery behavior

This layer remains relevant even when the model behaved exactly as expected. Software can race, retry, crash, exceed a resource limit, or receive stale state. Runtime governance handles those conditions where they occur.

02 How to evaluate agentic AI governance frameworks

The products in this market increasingly overlap. Product labels are therefore less useful than asking which boundary a control actually enforces.

This comparison is intentionally non-exclusive. NeMo includes execution rails. Microsoft's toolkit describes policy, identity, sandboxing, and reliability. AgentCore provides a managed isolated runtime. LangGraph provides application control points. LangSmith provides observability and evaluation. Each can be a valid part of a governance design.

KDCube's position is the continuity between an open application framework and a self-hosted production runtime. Existing agents and focused governance tools can remain in place. KDCube supplies shared enforcement around app surfaces, identity, delegated authority, user choices, economics, event ownership, connected accounts, and isolated generated-code execution.

03 Follow one governed action end to end

Consider a user asking an agent-enabled application to summarize a document and send the result to Slack.

1. request enters a chat, API, or webhook
   -> runtime authenticates the actor and binds tenant/project/user context

2. app selects the agent for this conversation
   -> configured inventory is the ceiling
   -> saved conversation choices may narrow tools, services, and model

3. model proposes file analysis and a Slack action
   -> streamed action is parsed
   -> tool id, protocol, parameters, and action ordering are validated

4. file analysis needs open-ended computation
   -> the agent proposes a file ref; the ref is untrusted input, not authority
   -> trusted runtime resolves it under the already-bound user and materializes only an in-scope result
   -> generated code runs against that authorized per-turn workspace
   -> artifacts return through the runtime-owned file contract

5. Slack action reaches a trusted integration tool
   -> named-services door grant and live catalog action are checked
   -> current agent, selected account, and account-scoped provider claim are rebound server-side
   -> missing consent produces an actionable connection request

6. paid work crosses economics enforcement
   -> feasibility is verified
   -> funding is reserved where applicable
   -> actual tracked usage is settled after execution

7. result returns to the conversation
   -> tool result, file delivery, event state, and accounting context are recorded

No single filter owns this journey. Governance is the agreement between all of its boundaries. The same actor and authority facts must survive the stream, tool call, subprocess, external provider call, and result path.

04 How KDCube turns declarations into enforcement

KDCube apps declare their surfaces and dependencies. The runtime applies those declarations at the corresponding execution boundary.

The table also exposes a useful engineering rule: a policy claim is only as strong as its coverage. A custom paid API call becomes economically governed when it uses the accounting and economics contracts. A custom tool becomes governed when it is registered in the agent inventory and enters the normal validation and dispatch path. A direct side channel around those paths needs its own explicit control.

05 Generated-code data isolation: materialize before execution

KDCube's agentic execution path has four participants with different boundaries:

• the agent harness reasons over context and proposes refs or tool arguments;
• the trusted resolver applies the user and authority bound before the model ran;
• generated code receives a physical filesystem only inside the executor;
• trusted app and tool code may reach platform or provider services under the authenticated request context.

KDCube ReAct provides the fullest logical-ref implementation. It operates through runtime-owned workspace tools. Another agent framework can bind the same materialization, workspace, isolated-execution, trusted-tool, and file-hosting primitives through its own model-callable tools.

Conversation-owned files use references such as conv:fi:...; memories, tasks, canvases, and other services retain their own owner references. The current turn starts with a sparse workspace. A logical reference becomes local bytes through a runtime materialization operation:

REACT MODEL
logical refs + previews + tool contracts
        |
        | proposes ref through react.pull(...) or react.checkout(...)
        | ref is an untrusted locator
        v
TRUSTED RESOLVER
tenant + project + actor + bound user + authority
        |
        | in scope -> materialize; outside scope -> no bytes
        v
CURRENT-TURN WORKSPACE
only successfully resolved files for this turn
        |
        | authorized execution workspace
        v
GENERATED-CODE EXECUTOR
/workspace/work + /workspace/out + executor logs + tool socket

The agent may propose any reference string, including one produced by compromised behavior. That string identifies a requested object; it does not choose tenant, project, user, grants, or a storage root.

For conversation history, trusted runtime code combines the requested conversation and turn with RuntimeCtx.user_id, which was established outside model output. The index lookup is keyed by that bound user plus conversation and turn. For git-backed project state, lineage is rooted by tenant/project/user/conversation. A guessed conversation belonging to another user therefore produces no artifact in the bound user's scope and places no bytes in the workspace.

The same rule applies when a named service consumes an existing conversation file. The provider bridge resolves the durable conv:fi: locator under the current actor, tenant/project, conversation, selected account, and claim before creating disposable provider-side bytes. The ref is not a local workspace path and possession of its string does not grant access. A turnless client uses a staged upload instead: request a target, send the complete bytes to it, then pass the returned staged_ref; the ref alone contains no file.

react.pull(...) routes external owner refs through a registered trusted owner resolver under the carried request identity. react.checkout(...) makes successfully resolved project state editable. react.rg, patch, render, and exec tools consume physical paths already local in the workspace. Custom owner resolvers remain trusted application code and own their authorization contract.

The git-backed workspace applies the same rule to project state. Its branch and immutable turn refs are scoped by tenant, project, user, and conversation. The executor-visible repository contains the assigned lineage, has no configured remote, and carries no other-user refs. A distributed execution snapshot copies the generated program and the referenced workspace files required for that run, rather than a platform storage tree.

The resulting guarantee is concrete. Compromising the agent can change which locators and approved tools it requests. It cannot change the runtime-bound user or broaden the executor's storage view. Within split execution, generated code receives only bytes that trusted resolution placed in the current user/conversation workspace. Other users' workspace roots, platform stores, app storage, deployment descriptors, and provider credentials remain outside the restricted executor view.

The runtime establishes this boundary before generated code runs. The executor receives neither a general database handle nor a platform object-store or filesystem root.

The ported-langgraph-agents@2026-07-13 reference app demonstrates this reuse. It binds run_python as a normal LangChain tool, creates a fresh per-turn workspace, carries the current request identity into the trusted tool subsystem, runs Python through KDCube's deployment-selected ISO runtime, and hosts produced files into conversation storage. The existing LangGraph graph and model loop remain in place.

Here, “the graph remains” means the framework, nodes, prompts, tools, and checkpoint semantics remain. The graph instance is constructed inside one bound turn and discarded when that turn ends. Checkpoint and agent-owned state live in shared storage, and only true connections are reused. This prevents concurrent users and worker-to-worker turn movement from depending on process memory. It is a scaled-serving boundary distinct from the ISO executor that runs generated code.

06 Generated code, trusted tools, and credentials

In KDCube's strongest split-Docker profile, generated Python runs in an executor container with:

• network disabled
• a read-only root filesystem
• only the current work, artifact, executor-log, and supervisor-socket mounts
• a minimal sanitized environment
• an authenticated local bridge to approved tools

Descriptor payloads, app package roots, app storage, platform storage, supervisor logs, and provider credentials stay on the trusted supervisor side. The runtime also strips the portable request spec, communicator spec, tool modules, app descriptor, and storage paths from the executor globals before starting generated code.

Trusted tool runtime is the precise term for this architecture. Tools run according to policy: in the app process, in a local subprocess, or in the networked supervisor of an isolated execution. In the split profile, the supervisor is a separate container: executor stubs send authenticated calls over its socket, and the trusted implementation runs in the supervisor. Across supported runtime boundaries, KDCube carries the original request identity and reconstructs trusted services on the far side.

Connected-account credentials follow this trusted path. Provider tokens live in the user-secret lifecycle. For generic named services, the hosted connection has one named_services:use door grant. Connection Hub's current catalog defines the attempted action and its requirements, while the selected account's live account_scope supplies the provider claim. The bridge rebinds current agent and account authority at tool-call entry, then resolves the token server-side. The model and generated-code executor receive the action schema and a direct bounded result, including structured consent or executable file-source feedback when an action cannot proceed.

The ambient-authority guarantee remains true even if generated code is adversarial: its network, mounts, environment, and credentials do not expand. A manipulated model can still request a tool that appears in its allowed catalog. Tool allowlists, grants, provider claims, parameter validation, economics, and the correctness of trusted tool implementations govern that separate route.

07 Tenant/project deployment and shared-user boundaries

One running KDCube deployment is bound to one tenant/project. It can host many apps and serve many users whose work belongs in that deployment. Its backing PostgreSQL, Redis, object storage, and filesystem services may be dedicated or shared with other deployments. Shared topologies preserve tenant/project scope through PostgreSQL schemas, Redis namespaces, and object/file prefixes.

Users inside the deployment share proc workers, processor capacity, client pools, and filesystem infrastructure. KDCube binds each request to an authenticated actor and user. Its cross-runtime context preserves tenant, project, identity, routing, authority provenance, and accounting facts across supported async, thread, subprocess, isolated-supervisor, app-call, and Data Bus transitions.

Protected storage, API, tool, named-service, and economics surfaces then enforce the rule for their resource. Connection Hub resolves explicit connection edges, delegated grants, or provider-account claims where a call crosses an authority boundary. Trusted custom application code that opens a shared backend directly owns the corresponding authorization and scoping rule.

Agent-generated code receives a further structural boundary inside this shared runtime. The agent proposes locators; trusted resolvers keep the authenticated user and authority fixed. Generated code sees the resulting materialized turn workspace. Platform storage, app storage, provider credentials, and other users' workspace roots remain on the trusted side.

08 Cost governance requires admission and accounting

A cost dashboard answers an important question: what did the system spend? Runtime economics adds another: may this work start, which source funds it, and how is actual usage settled?

KDCube's economics path is:

resolve economics subject
  -> verify quota and funding feasibility
  -> reserve estimated funding when applicable
  -> run under bound accounting context
  -> settle actual tracked usage
  -> release unused reservation

The economics subject can differ from the immediate actor. A Telegram channel actor or delegated automation can preserve its own provenance while an approved platform identity supplies the economics authority.

Coverage remains explicit. Built-in model, embedding, and web-search calls use accounting-aware wrappers. Custom paid services join the same model through a tracker and a settlement owner such as EconomicsGuard. economic_preflight performs only the feasibility check when accounting and settlement belong to another enclosing flow. Work that bypasses those contracts does not become governed merely because a dashboard exists.

This is more precise than promising one universal wallet switch. KDCube can resolve plans, project funding, personal wallet funding, quotas, reservations, and settlement according to the configured economics model. The governing boundary is the admitted and accounted flow.

09 Evidence supports review; reviewers establish compliance

Governance needs evidence that connects a decision to its execution. KDCube produces structured records across several owning systems:

• accounting events record service type, provider/model or service, usage, success/error, and request context;
• request lineage connects accountable work to the user, app, conversation, turn, flow, and funding path;
• conversation event lanes and timelines retain event identity, order, materialized blocks, tool calls/results, and turn outcomes; every text submission, context event, and hosted attachment occurrence in the accepted batch retains its identity before a terminal assistant error, and visible model-round text remains a separate timeline event rather than being concatenated into one answer;
• isolated execution preserves generated source, artifacts, executor and supervisor diagnostics, and structured harness errors;
• delegated authority context carries actor, grantor, resource, grants, selected operations, and projection provenance where applicable.

These records are inputs to audit, incident response, cost review, and control testing. Each owning service decides which runtime context becomes durable; the deployment determines storage backends, access controls, retention, integrity protection, export, and any append-only or WORM requirements. A reviewer determines whether an action and its controls satisfy the applicable policy or regulation.

Self-hosting gives an organization direct control over the deployed storage and operations. Data residency and compliance depend on the complete architecture, including model providers, external services, backups, logging, retention, and organizational process.

10 Runtime governance also governs time and state

Agent systems are concurrent systems. A second request can arrive while the first turn is using a tool. A worker can die after accepting an event. A retry can repeat a side effect. A stale turn can wake after a newer owner has taken over.

KDCube's conversation event lane is keyed by tenant + project + user + conversation + agent. Redis lane sequence defines event order. Native ReAct owns a live handler and may fold eligible arrivals before its close gate. A foreign run-to-completion runtime instead takes the whole still-pending lane once at start, preserves exact event and batch identity, and lets a read-only watcher heartbeat only that turn's scheduled reservation. The shared door finalizes the exact ids it supplied and releases ownership on success or error. Live control remains runtime-specific: a LangGraph steer cancels the graph stream and leaves the last completed checkpoint intact; hosted Claude Code receives follow-up or stop at its next tool boundary. Before another model request, the graph adapter repairs every checkpointed tool call left without a tools-node result. A superseded turn cannot fold new lane events or become the conversation head.

Tool execution policy addresses a smaller but related boundary. A detached, fully validated neutral call may start when its streamed action block closes. An execution ledger prevents normal same-round retries from running that call a second time. External side effects still benefit from provider idempotency because at-most-once-per-round is not process-global exactly-once delivery.

These controls rarely appear in a governance slogan, yet they govern the state users actually experience.

11 Adopt governance one boundary at a time

Teams can keep their agent framework and product while adopting one useful KDCube control at a time.

1. Put one REST or MCP operation behind a managed resource-and-operation guard.
2. Put one paid API or model flow under verify-reserve-run-settle economics.
3. Move one generated-code path into split executor isolation.
4. Register one tool inventory and let users narrow it per conversation.
5. Resolve one external account through claim-scoped, server-side credentials.
6. Route one webhook or channel identity through explicit authority projection.
7. Keep the existing agent loop, UI, tools, and storage around the parts that already work.

The first boundary can remain the only boundary adopted. A team can also keep adding controls until the framework declarations and runtime enforcement form a shared application platform.

12 A governance review checklist

Before calling an agent system governed, ask for concrete answers:

• Which component authenticates the actor?
• How is the actor distinguished from the grantor or economics subject?
• Which data is visible as a logical ref, and which bytes are materialized into the current execution workspace?
• Which resource and operation does each credential authorize?
• Can a user narrow an agent's configured tools and services?
• Where are tool ids, parameters, and action order validated?
• Which process receives provider credentials?
• Which process receives network access and writable mounts?
• Which paid calls are admitted before execution and tracked afterward?
• How are retries, duplicate delivery, and stale owners handled?
• Which state store owns each durable record?
• Which records support investigation, and what retention/integrity policy applies to them?
• Which controls remain the application's responsibility?

Specific answers reveal the architecture. Broad claims hide its assumptions.

13 The KDCube position

KDCube is an open-source AI application framework with an integrated, self-hosted production runtime. Builders can bring LangGraph, CrewAI, the Claude Agent SDK, another framework, or custom Python. KDCube surrounds that work with app surfaces, identity and delegated authority, conversation-scoped capabilities, connected accounts, ordered conversation events, file delivery, economics, and isolated generated-code execution.

The shipped ported-langgraph-agents@2026-07-13 app makes that compatibility concrete: two existing agents run behind one framework-neutral turn seam, each graph instance is rebuilt for one turn, and shared/checkpointed stores preserve continuity across workers.

The differentiator is continuity:

Output guardrails, human approval systems, policy engines, observability tools, and managed cloud runtimes remain useful. KDCube gives teams an open place to connect those controls to the application runtime they operate.

· Read more

KDCube implementation and architecture

Related KDCube articles

External reference points

KDCube is MIT licensed. Start with the repository and apply one boundary where it removes the most operational work from your product.