How Companies Govern Agentic AI: From Policy To Runtime Enforcement

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:

Who is acting?
  -> authenticated identity and provenance

On whose authority?
  -> roles, grants, claims, consent, and delegation

What may happen?
  -> tool, operation, resource, and parameter policy

Where may it happen?
  -> process, network, filesystem, and storage boundaries

How much may it consume?
  -> admission, reservation, accounting, and settlement

What state may it change?
  -> ordered events, ownership, idempotency, and commit rules

What evidence remains?
  -> structured records with deployment-owned retention and review

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.

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.

INTERACTION             ACTION + AUTHORITY          RUNTIME + RESOURCES
input / retrieval       identity / grants           process / network
output validation       tools / operations          storage / secrets
quality evaluation      approval / parameters       economics / events
        |                       |                           |
        +-----------------------+---------------------------+
                                |
                                v
                    EVIDENCE + ORGANIZATIONAL REVIEW

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.

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
   -> current user and connected account are resolved server-side
   -> required provider claims are checked
   -> 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.

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.

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.

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.

KDCube ReAct          LangGraph reference          your agent adapter
logical refs          LangChain run_python         model-callable exec tool
      \                     |                     /
       +-------- untrusted locator request --------+
                             |
                             v
                  TRUSTED USER-BOUND RESOLVER
                 in scope -> bytes | else none
                             |
                             v
                  SPARSE PER-TURN WORKSPACE
                 authorized inputs + output roots
                             |
                             v
                       ISO EXECUTOR
                  generated code runs here
                             |
              +--------------+---------------+
              |                              |
              v                              v
       hosted file refs          authenticated tool socket
                                 trusted tools run in supervisor

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.

GENERATED-CODE EXECUTOR                    TRUSTED TOOL RUNTIME
materialized turn files                    carried request identity
no network in split mode                   grants + provider claims
no provider credentials                    server-side credential resolution
approved tool stubs           ---------->  trusted implementation
                               typed call
                              <----------  bounded result

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. A trusted integration tool resolves the current user's connected account and required claim through the SDK, then uses the token server-side. The model and generated-code executor receive the tool contract and bounded result.

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.

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.

optional shared backing services
  PostgreSQL schemas | Redis namespaces | bucket/path prefixes
                           |
                           v
one KDCube deployment: tenant + project
  apps | proc workers | processor | shared filesystem infrastructure
                           |
             +-------------+-------------+
             |                           |
             v                           v
  request for user A             request for user B
  bound actor + authority        bound actor + authority
             |                           |
             +-------------+-------------+
                           v
            guarded app/tool/storage boundaries
                           |
                           v
            agent locator + runtime-bound user/authority
                           |
                           v
            trusted code materializes one authorized workspace
            for each generated-code execution

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.

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;
• 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.

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. Handler ownership, active-consumer heartbeats, owner leases, processed cursors, and a close gate determine which turn may consume and commit work. 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.

Adopt governance one boundary at a time

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

• Put one REST or MCP operation behind a managed resource-and-operation guard.
• Put one paid API or model flow under verify-reserve-run-settle economics.
• Move one generated-code path into split executor isolation.
• Register one tool inventory and let users narrow it per conversation.
• Resolve one external account through claim-scoped, server-side credentials.
• Route one webhook or channel identity through explicit authority projection.
• 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.

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.

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:

framework declares
  -> runtime enforces
  -> platform services preserve the same identity, policy, and evidence
     across apps and execution boundaries

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:

• ReAct Realm Refs And Workspace Paths
• ReAct Workspace Model
• Cross-Runtime Context
• Tenant, User, Authority, And Execution Boundaries
• LangGraph Isolated Code Tool Reference
• Port Your Solution To A KDCube App
• Ported LangGraph Agents Reference App
• Isolated Runtime
• Runtime Modes For Built-In Tools
• Online Strategic Governance
• Tool Subsystem
• Protect REST With Managed Delegated Credentials
• Authority Projection
• Conversation-Scoped Agent Capabilities
• Economics Enforcement Engine
• Accounting And Usage Tracking
• Conversation Event Lane State

Related KDCube articles:

• AI Agent Infrastructure: The Runtime Around Your Framework
• Your LangGraph Agent In KDCube
• Isolated Code Execution: Computation Inside, Authority Through Tools
• Connection Hub: One Broker For Delegated Trust
• Economics on Every Paid Surface

External reference points:

• NIST AI Risk Management Framework
• Microsoft Agent Governance Toolkit
• NVIDIA NeMo Guardrails
• LangGraph Human-In-The-Loop
• LangSmith Observability Concepts
• Amazon Bedrock AgentCore Runtime

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