AI agent governance is becoming the real control plane
AI agent governance is the enterprise practice of controlling how long‑running, stateful AI agents identify users, access data, execute untrusted code, and coordinate with other agents across systems, blending identity, security, observability, and runtime orchestration into a single operational layer that can be audited, scaled, and upgraded without losing trust. Enterprises are finally learning that the core AI risk is not the model but the agents wrapped around it. Token flows, sandbox policies, and multi‑agent workflows are where mistakes become outages or breaches. Platforms like AWS Loom, Perplexity SPACE, and Google’s Agent Substrate are emerging because the old stack—Kubernetes plus a sprinkling of model APIs—is misaligned with what agents are: millions of mostly idle, high‑impact sessions that behave more like operating‑system processes than web services.
The key takeaway: runtime and governance are now the strategic battleground. Whoever owns the agent orchestration platform will own how AI is safely embedded into everyday work. Enterprises that keep treating agents as “just another microservice” will spend the next few years chasing brittle integrations, unexplained permissions, and runaway costs. The ones that rethink their runtime layer around agent behaviour—identity propagation, long‑lived sessions, and human‑in‑the‑loop control—will turn AI from a risky experiment into dependable infrastructure.
AWS Loom: identity‑first governance, not another managed service
AWS Loom is opinionated in all the right ways: it treats AI agents as first‑class governed actors rather than clever scripts glued to Bedrock. Loom builds agents with the Strands Agents SDK, runs them on Amazon Bedrock AgentCore Runtime, and ships as an open‑source reference platform with a unified management UI, backend API, identity provider integration, scope‑based authorization, and lifecycle management for agents, memory resources, MCP servers, and agent‑to‑agent integrations. This is not a managed service; it is a blueprint for how platform teams should run their own agent stacks inside existing cloud accounts.
The most important design choice is identity propagation. Loom implements the full authorization code flow and RFC 8693 token exchange via AgentCore Identity so that both end‑user and agent identities travel together in downstream access tokens, keeping the delegation chain intact across hops from agent to MCP server to API Gateway. That is the difference between “AI doing things” and “AI accountable for who asked it to do what”. Loom couples this with governance primitives: mandatory resource tags, role‑ and attribute‑based access controls, deployment blueprints, code validation, sprawl control, and human‑in‑the‑loop review so sensitive tool calls pause for explicit approval. In effect, Loom argues that secure AI starts with identity, not prompts.
Perplexity SPACE: persistent, sandboxed agents as an enterprise AI runtime
Perplexity’s SPACE runtime makes a clear statement: if your agents write and run code over hours or days, the sandbox is the real AI security framework. SPACE—short for Sandboxed Platform for Agentic Code Execution—is designed for long‑running agents that execute code, edit files, and complete multi‑step tasks over hours, days, or even months. Each task gets a disposable Firecracker microVM destroyed when work ends, with rolling snapshots preserving live memory and files so sessions can pause, resume, or branch across sandboxes. This separation of session from sandbox directly addresses the central challenge for autonomous agents: keep their working state and files while isolating compromised code, credentials, and network activity.
SPACE is opinionated about persistence. It supports pausing, resuming, suspension, restoration, rollback, forking, and crash recovery, uploading suspended sessions to object storage so another node can restore the agent with its prior filesystem and running state. Each sandbox runs inside its own guest kernel, enforced by an in‑guest daemon and network gateway; credentials remain outside and can be injected through the network or a browser agent, with enterprise customers able to use their own encryption keys for externally stored data. According to Perplexity, median sandbox creation time fell from 185 milliseconds to 60 milliseconds and 90th‑percentile latency dropped from 447 milliseconds to 89 milliseconds, making SPACE between 3.1 and 5 times faster than its previous system. Those numbers matter because every millisecond on the wake path is user‑visible for a coding agent left idle for twenty minutes between prompts.
Google Agent Substrate: orchestrating millions of sleeping agents
Google’s move to make GKE Agent Sandbox generally available and introduce Agent Substrate is an admission that Kubernetes is the wrong control plane for AI agents. Agent Sandbox gives each agent a hardened place to run model‑generated code, treating workloads as hostile and wrapping them in a “jail” rather than a shared‑kernel container. Agent Substrate is the scheduler that decides which agent runs where, reimagining container orchestration for millions of mostly idle sessions instead of a few long‑running services. It layers its own scheduler on top of Kubernetes Pods and autoscaling, avoiding the API server bottlenecks that appear when every agent wake becomes a fine‑grained scheduling event.
Substrate’s architecture embraces the reality that agents are like operating‑system processes: long‑lived, stateful, and asleep most of the time. Emerging session‑aware runtimes have effectively become a fourth compute offering beside virtual machines, containers, and serverless. The project reports 30x or more oversubscription with sub‑second activation because worker Pods are already running when an event arrives and never wait on the Kubernetes scheduler. In practice, teams running coding agents at scale are likely to combine these layers: sandbox the code, schedule it through Substrate, and let Kubernetes provision nodes underneath. GKE Agent Sandbox hit general availability after roughly 16x growth in sandboxes in under five months, with APIs allocating 300 sandboxes per second per cluster and 90% of allocations finishing in 200 milliseconds. That growth is a signal: agent‑specific orchestration is no longer an experiment.
The new enterprise AI runtime: governance, coordination and avoiding lock‑in
Taken together, Loom, SPACE, and Agent Substrate show where enterprise AI runtimes are headed: toward audited, persistent, multi‑agent fabrics that sit above traditional compute. Governance frameworks are expanding beyond access control to cover resource tagging, deployment blueprints, software validation, delegated identity chains, agent sprawl, and human‑in‑the‑loop checkpoints. Persistence is now a design requirement, not a nice‑to‑have; runtimes must snapshot volatile RAM and filesystem state and restore agents with full memory after a nap. Multi‑agent coordination is being built in from the start, with platforms managing agent‑to‑agent integrations and sandboxed environments that assume the worst‑case workload.
The encouraging trend is how much of this is open and vendor‑neutral. Agent Sandbox is an open‑source execution environment built on Kubernetes, Agent Substrate is described as an early, competitive runtime in a field where rivals are expected as idle‑agent costs become impossible to ignore, and Loom itself is free and open source, with costs limited to the managed services underneath. Perplexity plans to expand SPACE across more products and environments, including Linux microVMs, Windows guests, and users’ local machines. For enterprises, the lesson is clear: treat the agent runtime and AI security framework as a strategic layer, demand open interfaces, and design for portability. The platform that owns your agents will own your AI future; make sure you can move it when the market shifts.
