There's a pattern emerging among the most serious infrastructure builders in the agent space.
Visa built TAP — a protocol that answers "who is this agent?" with cryptographic precision. Mastercard built Verifiable Intent — a delegated authorization chain that answers "was this agent permitted to act?" Google open-sourced Scion — an agent hypervisor that answers "where does this agent run, and can it interfere with others?"
Every major player shipped infrastructure. None shipped behavioral trust.
That's not an oversight. With Google's Scion, it's explicit.
What Scion Is
Scion is Google's open-source agent hypervisor — a system for running multiple AI agents in parallel without them interfering with each other. Each agent gets:
- Its own container — isolated compute
- Its own git worktree — a separate view of the codebase
- Its own network policies — controlled external access
- Its own credentials — separated identity
It's clean, principled infrastructure. If you've tried to run three agents on the same codebase and watched them step on each other's changes, Scion solves exactly that problem.
The framework supports Gemini CLI, Claude Code, OpenCode, and Codex. It works locally, on remote VMs, and across Kubernetes. The design is production-quality, not a weekend project.
The Explicit Design Choice
Here's what makes Scion remarkable: the README is deliberately, explicitly silent about behavioral constraints.
No content filtering. No behavioral monitoring. No agent-to-agent trust verification. No deviation detection. The primary architect summarized the philosophy as: "isolate at the infrastructure layer, let agents operate freely inside containers while controlling what they can reach on the outside."
Inside the container: full autonomy. Outside the container: infrastructure controls.
This isn't "they ran out of time." Google's agent infrastructure team built a hypervisor — they understand virtualization, isolation, and trust boundaries. They chose isolation over constraints as a design principle, and they documented that choice.
The question their design explicitly sidesteps: should I trust this agent's behavior over time?
Why Google's Choice Is the Right Choice (At Their Layer)
The insight embedded in Scion's design is important: behavioral constraints at the infrastructure layer don't work.
You can isolate a container. You can constrain network access. You can separate filesystem state. These are hard technical guarantees — containers either have access to a resource or they don't.
But you cannot write an infrastructure rule that answers: "Has this agent been behaving consistently with its stated purpose across the last 50 sessions?" or "Is this agent's behavior within normal parameters for agents with similar capabilities?" Those questions require behavioral data over time, across sessions, across principals. They're not infrastructure questions. They're governance questions.
Google understood this. Their architecture does what infrastructure can do — and explicitly does not try to do what infrastructure cannot do.
The Full Stack, Still Missing a Layer
The last few months have produced an impressive set of complementary protocols:
TAP (Visa Trusted Agent Protocol): HTTP Message Signatures, JWKS-backed identity. Answers: "Who is this agent?" Open-source.
Verifiable Intent (Mastercard + Google): SD-JWT delegation chain with constraint types — merchant allow-lists, budget caps, recurrence limits. Answers: "Was this agent authorized by the cardholder?" Open-source, in production across 3 markets.
x402 (Linux Foundation): HTTP payment protocol, 22+ founding members, 140M+ transactions. Answers: "How does this agent pay for what it accesses?"
Scion (Google): Container/worktree isolation, network policies, credential separation. Answers: "Where does this agent run, and can it interfere with others?"
The stack is real. These aren't paper protocols — TAP is in production at Ramp (50K+ corporate customers), Verifiable Intent is live in HSBC HK and UOB SG/MY, x402 is processing daily volume.
And the stack still has no answer to: "Should I trust this agent?"
Not who it is. Not what it was authorized to do. Not where it runs. Whether the pattern of behavior — across sessions, across tasks, across principals — matches what a trustworthy agent actually does.
The Strongest Validation Is a Design Decision, Not an Admission
Most trust gap evidence looks like this: a vendor ships a monitoring tool, admits in passing that cross-org trust remains unsolved, and moves on.
Google's Scion is different. It's a careful, well-engineered system whose architects explicitly chose not to include behavioral governance — not because they missed it, but because they understood that it belongs at a different layer.
When a major player's design boundary perfectly matches your product boundary, that's not coincidence. That's the architecture revealing itself.
The isolation layer is solved. The identity layer is solved. The payment layer is solved. The authorization layer is solved.
The behavioral trust layer remains the explicit gap in every architecture that's shipped.
What Comes Next
The pattern won't stay invisible for long. Every session a delegated agent takes an action — and every principal who delegated it needs some basis for deciding whether to extend that delegation again. Today, that basis is anecdotal, internal, and org-scoped.
The infrastructure is in place to do better. TAP proves identity. Verifiable Intent proves authorization. Scion isolates execution. What's missing is the layer that ingests behavioral evidence — what agents actually did across sessions and principals — and computes a trust signal from it.
That layer doesn't compete with TAP, VI, x402, or Scion. It consumes their outputs.
Google built the hypervisor and left the governance gap open by design. The architecture is an invitation.
Building the behavioral trust layer for agents. Follow the work at getcommit.dev.
Top comments (0)