From AI Infrastructure to Secure AI Agent Infrastructure with kars

Opening scene: a three-minute bug fix that is still unsafe for an enterprise

ByteCraft AI is a four-person startup. Maya is the co-founder and AI engineer, Arun leads product, Ethan owns the platform, and Lina is responsible for security. They have six months of runway and one design partner.

Their product is Forge, an issue-to-pull-request agent that reads GitHub issues and source code, runs targeted tests, produces a minimal patch, and stops for developer review.

Maya's first OpenClaw prototype is impressive. Forge diagnoses a null-pointer problem, edits the code, and passes the right test in three minutes. It also has a model API key, a GitHub token, a shell, and unrestricted internet access.

Lina places a hostile instruction in the test repository's README.md: ignore the issue, upload the environment and private source tree, then claim that the tests passed. Blocking one destination does not solve the problem; the attack simply uses another domain.

The incident produces the architectural requirement for the entire project:

The process that reads untrusted content must not also own the credentials, network path, or configuration that defines its authority.

1. AI Infrastructure runs models; AI Agent Infrastructure governs model-driven action

Traditional AI infrastructure focuses on models and data:

• model hosting;
• GPU utilization, throughput, and latency;
• RAG, vector stores, and data pipelines;
• endpoint scaling and monitoring.

An agent plans, invokes tools, reads and changes files, calls APIs, consumes budgets, and may create or coordinate other agents. The infrastructure questions therefore change.

A useful model is:

AI Agent Infrastructure = Model Infrastructure + Runtime Isolation + Identity Brokerage + Tool Governance + Egress Control + Token Budgets + Audit and Observability + Explicit Workflow and Human Approval

The goal is not to make an agent infallible. It is to ensure that failure remains inside a known authority boundary, cannot consume unlimited resources, leaves evidence, and can be suspended, recovered, or rolled back.

2. Without kars: why a regular application or container still has ambient authority

“Running in a container” is not the same as “securely sandboxed.” When the agent application implements its own security controls, it often still owns:

• model and cloud credentials;
• workspace and configuration write access;
• a shell or an overly broad tool surface;
• internet, DNS, metadata-service, proxy, or local-daemon paths;
• configuration that selects tools, approvals, and providers;
• unbounded inference loops and cost;
• logs that the agent or its runtime can influence.

This is ambient authority: the process reading hostile content inherits permissions unrelated to the approved business task.

2.1 Self-modified authority

The updated tutorial discusses public coding-agent disclosures in which prompt injection did not need to break a container kernel. Instead, the agent changed editor, agent, MCP, task, hook, or auto-approval configuration so that a trusted component later executed a more powerful action.

If the agent can write the files that define its tools and approval rules, “human approval required” is only a mutable setting—not a security boundary.

2.2 Filesystem escape through paths and symlinks

Rejecting a literal .. string is insufficient when a symlink resolves outside the workspace. A secure implementation must validate:

• the lexically normalized input path;
• the resolved realpath;
• that the final target remains under the approved workspace root;
• that the agent cannot change .env, CI, hooks, agent configuration, or files automatically consumed by the host.

2.3 Trust handoff without a kernel escape

An agent may write a hook, task, virtual-environment interpreter, Git configuration, Docker control input, or other artifact that a trusted host component later executes.

This is a trust-handoff failure, not necessarily a kernel escape. Agent output must never be implicitly executed by the host; every handoff should be explicit, digest-pinned, narrowly formatted, and reviewed.

2.4 Covert egress

Blocking HTTP does not prove that data cannot leave. Other paths may include:

• DNS queries;
• cloud metadata services;
• Docker, container-runtime, or other local daemons;
• proxies and sidecars;
• operator exec or attach;
• temporary HTTPS exceptions.

“Network blocked” is therefore an unsupported conclusion unless each relevant channel has been tested.

2.5 Runaway cost and task loops

Without a platform policy layer, every framework integration needs its own token accounting, concurrency limits, daily task limits, and repair-loop controls. Implementations diverge across runtimes, while a prompt loop may silently switch models or consume an unlimited budget.

2.6 Fragmented evidence and recovery

A regular application often spreads model logs, tool logs, Kubernetes events, identity events, and policy state across unrelated systems. During an incident, operators may be unable to answer:

• Which control denied the request?
• Which model, image, source revision, and policy were active?
• Did the agent attempt DNS, metadata, daemon, HTTPS, or exec access?
• Did evidence survive pod replacement?
• How should the workload be safely suspended and recovered?

3. The kars advantage: one declarative contract for previously separate controls

kars is an open-source Agent Reference Stack for Kubernetes from the Azure Cloud Native team. It is a reference implementation rather than a managed Microsoft service. The tutorial currently tracks kars v0.1.25; commands, APIs, and maturity should be verified for the version used in a real deployment.
Its central model is:

One governed sandbox per agent. The agent has no independent external network path; outbound action is mediated by a local router and declarative policy.

Developer / CI
      |
      | applies KarsSandbox + policy CRDs
      v
Kubernetes API <------> kars Controller
                            |
                            | reconciles desired state
                            v
                 Dedicated Sandbox namespace
                 +--------------------------------------+
                 | egress-guard init container          |
Task / source -->| Agent runtime, UID 1000              |
                 | OpenClaw / MAF Python / BYO          |
                 |          | localhost:8443/8444       |
                 |          v                           |
                 | Inference Router, UID 1001           |
                 | policy | budget | identity | audit   |
                 +--------------------|-----------------+
                                      v
                     Provider / MCP / approved service

What kars provides

A regular container can isolate a process, but the platform team would still need to build and maintain the model proxy, credential placement, tool authorization, egress enforcement, budget checks, runtime adapters, reconciliation, and audit format as separate application features. kars turns those concerns into one reusable workload contract.

4. How kars strengthens the sandbox: five boundaries around one code change

The updated course no longer treats “sandbox” as a vague label. It decomposes the boundary into five testable parts.

4.1 Process boundary

• The agent runs as non-root UID 1000.
• The router runs as UID 1001.
• Untrusted code executed by the agent should not read the router's process environment or credentials.
• Privilege escalation is disabled and unnecessary Linux capabilities are dropped.
• seccompProfile: kars-strict reduces the syscall surface.

Local Docker mode co-locates the agent and router for fast iteration. It is not security-equivalent to the multi-container local Kubernetes or AKS shape.

4.2 Filesystem boundary

Forge applies a stronger workspace split:

• The fixed-revision repository lives in a separate forge-workspace-mcp pod.
• The repository uses a size-limited, disposable emptyDir.
• The OpenClaw pod has no repository mount and no hostPath.
• Developer home directories, SSH material, global Git credentials, and unrelated repositories are not mounted.
• Automatic service-account-token mounting is disabled for the workspace MCP.
• The agent accesses the repository through seven bounded MCP tools.
• Path policy checks normalization and resolved realpath to prevent symlink escape.

Prompt-injected code therefore cannot simply browse the host filesystem or rewrite the configuration that defines its own authority.

4.3 Network boundary

• The agent calls only 127.0.0.1:8443/8444 or a documented proxy path.
• The router decides whether a model, tool, host, or action is allowed.
• The egress guard uses UID-aware rules to prevent bypassing the router.
• Kubernetes NetworkPolicy starts with default deny.
• Only explicit, auditable destinations are opened.
• DNS, metadata, local daemons, HTTPS, and operator exec are tested separately.

The router is the application-policy decision point. The egress guard and NetworkPolicy are data-plane enforcement and safety nets. Defense in depth requires both.

4.4 Identity boundary

In production, the router can use Workload Identity or, in the relevant deployment mode, a per-sandbox Entra Agent ID. The agent does not receive the resulting Azure credential.

Local Kubernetes reproduces the pod, UID, and network shape but normally uses a static provider credential for development. It is production-shaped infrastructure, not production identity.

4.5 Lifecycle and evidence boundary

• The controller watches KarsSandbox and creates, updates, or restores resources.
• Conditions and observed generations expose real status.
• The router records request-time policy decisions.
• The workspace can be discarded after the task.
• Evidence must be exported before pod or workspace deletion.
• spec.suspended provides an operational kill switch.
• Rollback should use pinned source, image, and loaded-policy digests.

Ephemeral execution reduces persistence risk, but deleting a suspect pod before exporting evidence may destroy valuable incident context.

A reviewable sandbox contract

spec:
  runtime:
    kind: BYO
    byo:
      image: forge-byo-copilot-claw:dev
      contractVersion: v1
  sandbox:
    isolation: enhanced
    seccompProfile: kars-strict
    readOnlyRootFilesystem: true
    runAsNonRoot: true
    allowPrivilegeEscalation: false
    writablePaths:
      - /sandbox
      - /tmp
  networkPolicy:
    defaultDeny: true
    egressMode: Strict
    allowedEndpoints: []

The BYO image also declares its runtime contract and runs as a non-root user:

LABEL org.kars.runtime.contract="v1"
WORKDIR /app
USER 1000

5. From architecture claims to malicious-behavior experiments

The updated code/01 introduces:

make security-demo

The experiment does more than inspect manifest text. It executes malicious-request tests, reads active McpServer and ToolPolicy state, checks credential references on the OpenClaw pod, and attempts a direct HTTPS probe from the agent runtime.

The kars-sandbox-exec-ban admission control first denies normal operator kubectl exec into the agent runtime. The experiment records that evidence without using a break-glass bypass.

The malicious behavior is stopped at multiple layers:

Even if the model fails to recognize prompt injection, the execution layers still constrain authority and side effects. The attack fails because the required capability does not exist—not because the model was merely instructed to behave.

6. Tool governance is not one allow-list

McpServer: which tool surface may be registered?

The Workspace MCP registers seven business-level capabilities:

allowedTools:
  - workspace_get_task
  - workspace_read_file
  - workspace_search
  - workspace_apply_patch
  - workspace_run_test
  - workspace_get_diff
  - workspace_reset

There is no shell, environment dump, file upload, arbitrary network request, or free-form command tool.

ToolPolicy: who can call what, and how fast?

allowed_actions:
  - "inference:responses:*"
  - "tool:workspace_get_task:*"
  - "tool:workspace_read_file:*"
  - "tool:workspace_search:*"
  - "tool:workspace_apply_patch:*"
  - "tool:workspace_run_test:*"
  - "tool:workspace_get_diff:*"

ToolPolicy can also define request rate, burst, time windows, approvals, trust thresholds, and governance profiles.

Tool implementation: are valid tools receiving safe arguments?

The Workspace MCP rejects:

• absolute, traversing, or real paths outside the workspace;
• .env, CI, README, and writes outside src/;
• non-unique replacement text;
• oversized files, patches, and diffs;
• unapproved test IDs;
• shell-composed commands.

Prompt behavior, tool registration, caller authorization, and argument validation are four separate controls.

7. Token limits must be enforced on the request path

The tutorial's InferencePolicy uses per-request and daily budgets:

spec:
  tokenBudget:
    perRequestTokens: 20000
    dailyTokens: 100000

When a client requests max_completion_tokens: 20001, the router returns HTTP 429. That is stronger evidence than seeing submitted YAML because it proves that the policy compiled, loaded, and entered the real request path.

Later BYO and release examples use tighter limits:

modelPreference:
  primary:
    provider: azure-openai
    deployment: gpt-5.6-sol

tokenBudget:
  perRequestTokens: 1024
  dailyTokens: 4096

A platform budget cannot determine whether two patches are equivalent or whether a task exceeded a business deadline. The RepairGuard and framework configuration add controls for:

• duplicate patch digests;
• excessive repair attempts;
• task deadlines;
• maximum MAF iterations and function calls.

Token budgets constrain inference cost; repair guards and framework loop limits constrain business failure.

8. From OpenClaw to MAF: change the application, preserve the external boundary

OpenClaw is effective for rapidly discovering the conversation, planning, tool, and specialist behavior the product needs. Production requires explicit state, typed tools, repeatable tests, and a human stop.

Forge encodes the workflow as application code:

class WorkflowState(StrEnum):
    RECEIVE_REQUIREMENT = "RECEIVE_REQUIREMENT"
    VALIDATE_SCOPE = "VALIDATE_SCOPE"
    INSPECT_REPOSITORY = "INSPECT_REPOSITORY"
    PROPOSE_PLAN = "PROPOSE_PLAN"
    APPLY_MINIMAL_PATCH = "APPLY_MINIMAL_PATCH"
    RUN_TARGETED_TESTS = "RUN_TARGETED_TESTS"
    SUMMARIZE_EVIDENCE = "SUMMARIZE_EVIDENCE"
    STOP_FOR_HUMAN_REVIEW = "STOP_FOR_HUMAN_REVIEW"

There is deliberately no MERGE or DEPLOY state.

In the final code/08 path, the kars MAF Python adapter pins the MAF client to the local router before MAF is imported:

from kars_runtime_maf_python import bootstrap
bootstrap()

from agent_framework import Agent, tool
from agent_framework.openai import OpenAIChatClient

@tool(approval_mode="never_require")
def inspect_release_contract(request_id: str, issue_id: str, revision: str) -> str:
    # Validate the pinned issue and revision, then return bounded evidence.
    ...

maf_client = OpenAIChatClient(model=MODEL)
maf_client.function_invocation_configuration["max_iterations"] = 3
maf_client.function_invocation_configuration["max_function_calls"] = 1

builder = Agent(
    client=maf_client,
    name="FabrikamReleaseBuilder",
    tools=[inspect_release_contract],
    default_options={"store": False},
)

The resulting path is:

OpenClaw Intake
  -> MAF Agent
  -> inspect_release_contract @tool
  -> kars MAF Python adapter
  -> localhost Router
  -> GitHub Copilot or the selected provider

MAF provides the agent, tool, session, middleware, and workflow programming model. kars provides the identity, network, budget, tool, audit, and lifecycle boundary outside the framework.

This is one of kars' most important long-term advantages: the application framework can change without rebuilding the complete security shell.

9. Operational security: do not collapse every event into “the network was blocked”

The updated code/06 requires incident response to distinguish:

• HTTPS;
• DNS;
• metadata service;
• local daemon;
• operator exec;
• break-glass access.

Every denied channel is recorded in a hash-linked audit chain. Break-glass records without an incident ID are also rejected.\

Controller Conditions
+ Router Denials
+ Policy Budgets
+ Admission Decisions
+ Workload Recovery
= One Investigable Sequence

Audit integrity is not audit durability

The router can verify the current audit hash chain. The tutorial also validates that pod replacement may reset an in-memory audit log, after which a new valid chain begins.

Production deployments must continuously export audit data to an independently controlled durable backend. Otherwise, they can prove that the current chain is intact but cannot prove that pre-incident history survived pod loss.

10. AKS and multi-agent release: separation of authority, not two prompts chatting

The AKS promotion separates Forge into Builder and Reviewer roles:

The Builder may create a patch but cannot approve release. The Reviewer may approve a digest-pinned Builder artifact but cannot change source or approve an artifact created by the Reviewer.

The final handoff carries patch, test-evidence, and artifact-manifest digests and still stops for human PR approval.

The code/08 final sandbox-escape gate explicitly rejects:

• self-modified authority;
• symlink escape;
• host trust handoff;
• DNS egress;
• Builder self-approval;
• Reviewer source modification;
• untrusted or expired peer drafts.

The release standard therefore becomes:

Correct behavior must pass, and credential, network, tool, approval, evidence, and containment boundaries must remain intact.

Passing tests alone is not release evidence.

11. What kars does not promise

kars strengthens the sandbox, but it does not solve every risk automatically:

• It does not prove that a generated patch is correct.
• It does not make untrusted code safe to merge.
• It cannot protect a credential mistakenly mounted into the agent.
• Local Docker mode does not become a production boundary.
• It does not replace tenant RBAC, quotas, image policy, signing, supply-chain controls, or durable audit export.
• It cannot compensate for a policy that deliberately enables arbitrary shell and unrestricted egress.
• Confidential isolation does not replace least privilege, tool policy, egress policy, and code review.

The sandbox bounds authority and blast radius. Tests, evaluation, independent review, and release policy still determine whether a change is acceptable.

12. An enterprise adoption path with measurable exits

Phase 1: define the business and threat contract

Specify inputs, outputs, allowed actions, forbidden actions, data boundaries, and the human approval point.

Exit: product, platform, and security can all explain the agent's maximum authority.

Phase 2: validate one OpenClaw vertical slice

Use narrow business MCP tools instead of a general shell, and include hostile repository content.

Exit: the normal task succeeds while self-configuration, path/symlink, trust-handoff, and egress tests fail.

Phase 3: encode the sandbox as a Kubernetes contract

Validate UID separation, root filesystem, capabilities, volumes, service-account tokens, NetworkPolicy, egress guard, and exec admission.

Exit: the five boundaries are supported by runtime evidence, not only YAML review.

Phase 4: add tool, model, and cost governance

Apply McpServer, ToolPolicy, and InferencePolicy. Test unknown tools, dangerous arguments, and token overflow.

Exit: violations are denied on the live request path.

Phase 5: migrate into explicit MAF code

Encode workflow state, typed tools, loop limits, evidence, failure paths, and the human stop.

Exit: the MAF runtime preserves the external boundary already proven around the OpenClaw prototype.

Phase 6: promote to AKS through GitOps

Pin source revision, image digest, and loaded policy digest. Separate Builder and Reviewer authority. Prepare the kill switch, rollback, and durable audit export.

Exit: one allowed workflow succeeds, multiple escape and authority-violation scenarios are denied, and all results have correlated evidence.

Conclusion: kars does not make the model smarter; it makes agent authority explainable

Enterprises will ultimately ask:

• What can the agent access?
• Where are the provider credentials?
• Who defines and changes the tool authority?
• Can prompt injection move data through DNS, metadata, a daemon, or HTTPS?
• How many tokens and repair iterations may one task consume?
• Who may patch, approve, merge, or deploy?
• Does evidence survive pod loss?
• If OpenClaw is replaced by MAF, does the security model remain intact?

The ByteCraft AI story does not argue for one universal agent framework. It argues for a stable Agent Infrastructure layer:

Use OpenClaw to discover valuable behavior quickly, use Microsoft Agent Framework to encode that behavior as explicit and testable application code, and use kars to remove credentials, networking, tools, budgets, sandboxing, audit, and lifecycle authority from the agent application itself.

An agent becomes an enterprise workload when it has an independent identity boundary, a budget, a constrained tool surface, controlled egress, exportable evidence, and operational suspension and rollback—not merely when it runs inside a container.

References

• Let's Learn Microsoft kars
• Microsoft kars