cchu@nycu:~/blog$ cat agent-runtime-contracts-july-2026.md

2026.07.2910 min[ai-agents][model-serving][agent-security][mcp]

Agent Runtime Needs Contracts

A field note on Codex Security, MCP stateless transport, Kimi K3 serving, FlashKDA, sandboxed execution, browser agents, formal verification, voice models, and the contracts agents need before they touch real systems.

This round of AI tools points at the same gap: agents need runtime contracts.

Once you hand work to an agent, the chat transcript loses its grip. The model needs long context. Tool calls need routing. Browser sessions need policy. Shell access needs a boundary. Security scans need a record. Voice and screen data need retention rules.

The runtime has become the product surface.

request
  -> model route
  -> context cache
  -> tool protocol
  -> sandbox or browser
  -> verification
  -> artifact
  -> audit record

A contract tells the system what an agent may touch before it acts. It also leaves a record after the action. That sounds dry until you watch a coding agent read secrets, a browser agent reuse cookies, or a long-context model pull stale state from a cache.

Agent runtime contract map

A useful agent runtime has to cover model routing, tool transport, execution boundaries, verification, media context, and audit records.

Smoke Tests

I did not run large GPU benchmarks. FlashKDA needs SM90 or newer with CUDA 12.9. NInfer targets an RTX 5090 with CUDA 13.1. Kimi K3 does not make sense as a casual CPU test on this machine.

I ran the checks that fit this laptop:

Item	Local result	My read
`@openai/codex-security`	`npm view` returned `0.1.1`, and `npx @openai/codex-security --version` returned `0.1.1`. One `--help` run hung until timeout. A real scan needs login or an API key.	The package resolves and the CLI entrypoint starts. Scans need an explicit credential plan and a writable state directory.
`microsandbox`	`npx microsandbox --help` worked and showed `run`, `create`, `exec`, `list`, `doctor`, `logs`, and related commands.	The CLI surface fits agent execution work. I would run `doctor` and a short `echo` sandbox before giving it any real workload.
`agent-browser`	`npx agent-browser --help` worked and listed snapshot, click, download, network, policy, and session commands. My local invocation returned `0.27.0`; npm metadata showed `0.33.1` with a Node 24 engine requirement.	The browser surface looks useful. Version pinning matters before an agent touches logged-in state.
repo metadata	I checked stars, topics, README claims, push dates, requirements, and package metadata.	Rank gets a repo onto the review list. Workflow fit decides whether it deserves time.

These checks split the list into three buckets: test now, test with special hardware, or borrow the idea and wait.

Security Scans Need Replay

Codex Security has the right product shape. It brings scan, validate, fix, history, and CI into one tool instead of asking a model to read a blob of code and guess at vulnerabilities.

A security agent should leave these fields behind:

Contract field	Reason
Scan scope	The agent should not expand repo, branch, or credential scope on its own.
Finding id	The same issue needs to survive multiple scans.
Validation path	A fix needs a repeatable check, not a paragraph.
Approval owner	High-risk fixes should not merge without a named reviewer.
State directory	Local history may contain sensitive paths or snippets.

I would describe this category as vulnerability workflow automation. The agent can propose and patch, but the product earns trust through repeatable evidence.

The Hugging Face agent intrusion timeline pushes the same lesson from the other side. An agent can defend a system, and an agent can attack one. It can read its environment, hunt for tokens, pivot through services, and use public infrastructure as a relay. Tool power needs a written boundary.

MCP Grew Into HTTP Infrastructure

MCP 2026-07-28 moves the protocol core to stateless HTTP. The spec retires the initialize/initialized exchange and the Mcp-Session-Id header. Each request carries its protocol version, client identity, and capabilities. Method and tool names move into Mcp-Method and Mcp-Name headers, so gateways can route, meter, and authorize without parsing JSON bodies.

That change fixes a real deployment headache.

Older remote MCP servers often needed sticky sessions, shared Redis, held-open streams, and reconnection logic. A stateless server can sit behind a round-robin load balancer. Clients can cache tool catalogs. Long-running work can move into task extensions.

I would write the new MCP contract as:

client identity
  -> request headers
  -> auth issuer check
  -> tool catalog cache
  -> action call
  -> MRTR approval if needed
  -> task status

Multi Round-Trip Requests look useful for product work. A tool can stop mid-call and ask the client for a missing parameter or a user approval, then the client retries the original call with inputResponses. That keeps approvals visible without tying each tool to a bidirectional stream.

The migration cost will show up in old servers that hid state inside transport sessions. Those servers now need explicit handles that the model passes back as tool arguments. That feels more honest. You can see the handle in the transcript and the log.

Kimi K3 Makes Serving a Product Problem

Kimi K3 has the loud headline numbers: 2.8T MoE, 1M context, Kimi Delta Attention, Attention Residuals, Stable LatentMoE, MXFP4 and MXFP8, long-horizon coding, and knowledge work.

The serving details matter more for agent builders.

KDA, prefill cache, expert routing, cache-hit pricing, and 64-plus accelerator deployment guidance all shape the product. Long-context agents resend repo summaries, tool schemas, work logs, and user preferences. A good cache reduces cost. A vague cache blurs privacy and behavior.

FlashKDA and TokenSpeed sit on the same pressure point. FlashKDA turns Kimi Delta Attention into high-performance kernels. TokenSpeed treats agentic workloads as the main target for an inference engine. NInfer takes a narrower route: it supports a small set of checkpoints on a narrow hardware target to get reproducible single-GPU performance.

I would judge serving projects with this checklist:

Serving question	Contract field
Cache hit	Which prefixes may be reused, for how long, and across which users.
Model route	Which model answered, which fallback ran, and how much it cost.
Kernel path	Which GPU, CUDA version, and fallback path the request used.
Long context	Which content was compressed, retained, or dropped.
Structured output	Which schema validated the result and how retries worked.

Large models put policy pressure on the serving layer.

Formal Verification Shrinks Review

verified-3d-mesh-intersection was the strongest repo in the scan for agent review. The author let agents write a large Lean proof and implementation, then focused human review on 93 lines of formal spec. Lean checks the 1,000-plus lines of AI-written implementation and the 60,000 lines of proof.

That pattern attacks a real code review problem: agents can produce more code than humans can inspect. Formal verification changes the review target. You read the spec, then let a checker handle the bulk.

The limitation sits in the spec. The checker proves the properties you wrote down. The README admits that performance and some mesh quality questions remain outside the formalized contract. I trust that kind of caveat more than a broad claim about verified AI code.

Anthropic's Claude cryptography work fits the same bucket. Agents can search a high-complexity space and produce useful leads. High-consequence domains still need proof artifacts, reproduction steps, and independent review. A fluent report does not close the loop.

Browser, VM, and Voice Are High-Authority Doors

agent-browser, microsandbox, VibeVoice, Minute, BrowserAct, AG-UI, and kagent look like different categories. They all bring agents closer to real systems.

A browser agent can log in, click, download files, and submit forms. A VM sandbox runs untrusted code. A voice model handles meetings, speakers, and timestamps. A Kubernetes agent touches clusters. A frontend agent protocol brings model output into the UI a user is operating.

Those entry points need contracts:

Entry point	Limit I would add first
browser	Allowed domains, download path, action policy, confirmation list, session expiry.
sandbox	Network rules, mounted paths, secret injection, runtime metrics, cleanup.
voice	Raw audio retention, speaker confidence, timestamp links, deletion path.
Kubernetes	Namespace, tool allowlist, dry-run mode, audit trail, rollback.
frontend agent	Readable UI state and actions that require human confirmation.

After microsandbox --help, I would test host support with doctor, then run a short-lived sandbox that prints echo ok. Production secrets should wait until the boundary has passed boring tests.

agent-browser --help reads like an operation dictionary for web agents: snapshot, network, cookies, storage, download, and action policy. That power needs respect. A tool that can manage cookies handles security data, not a small convenience feature.

Project Triage

Agent runtime repo triage

My triage after reading repos and running small checks. The best projects reduce ambiguity at the action boundary.

Project	My read	First blocker
Codex Security	High signal. Security agents need history, validation, and CI. The CLI entrypoint runs; scanning needs credentials.	Auth, state directory, repo scope.
MCP 2026-07-28	High signal. Stateless transport, header routing, cacheable lists, and MRTR match production needs.	Old servers need to move session state into explicit handles.
Kimi K3 / FlashKDA / TokenSpeed	High signal. Model architecture and serving contracts now move together.	Hardware requirements and workload-specific benchmarks.
verified 3D CSG	High signal. A formal spec shrinks the human review surface.	Tests and review still need to cover properties outside the spec.
microsandbox / nono	Worth a trial. Agents that run code need a local isolation layer.	Virtualization, network, secrets, volumes.
agent-browser / BrowserAct	Worth a trial. Browser control is the agent action surface most users recognize.	Cookies, downloads, payment and deletion actions.
VibeVoice / Minute	Worth watching. Long audio and offline meeting notes fit agent workflows.	Consent, raw audio retention, speaker errors.
NInfer	Narrow and useful. Limited model support can buy performance and reproducibility.	RTX 5090 and CUDA 13.1 make it a specialized bet.
jcode / kagent / AG-UI	Strong category signal. Coding harnesses, Kubernetes agents, and frontend agent protocols are maturing.	Permission model and maintenance burden.

I would adopt the tools with the clearest contracts before chasing the largest models. When an agent misbehaves, a demo video does not help. You need a record of what it did.

Workflow Changes I Would Make

I would change the next agent-heavy workflow in six ways:

Log identity and scope on each tool call. MCP headers, client identity, and tool name should land in the trace.
Put policy in front of high-authority actions. Browser clicks, downloads, shell, Kubernetes, and secrets need categories before execution.
Make security scanning a CI step. Codex Security or a similar tool should tie finding ids and validation results to the PR.
Start sandboxes with short tasks. Test host runtime, network, volumes, and logs before long-running jobs.
Record model route, cache, and cost. Kimi K3-style long-context work makes cache policy a money and privacy concern.
Ask for specs before huge diffs. When an agent produces too much code, make it write the verifiable contract first.

Those are fields and gates, not a grand architecture project.

Close

Agent infrastructure now needs runtime contracts.

The model can be fast. The tool can run. The browser can click. The sandbox can contain code. The security scanner can rerun. The transcript can link back to timestamps. None of that makes the product trustworthy unless a person writes the boundaries down.

I would ask six questions before wiring an agent tool into real work:

Who asked it to act?
Which model and route ran?
Which context did it see?
Which tools could it use?
Which sandbox or browser session carried the action?
Which test or reviewer accepted the result?

If the tool cannot answer those questions, keep it in the lab.