I read Anthropic's Zero Trust framework for AI agents. Here's where Solo already answers it.

When Anthropic published its Zero Trust framework for AI agents last week, I read it the way I'd read a control catalogue before a readiness assessment. And the thing that struck me, now that I'm at Solo, is how much of it we already answer out of the box.

I have spent a long time working with auditors whilst at VMware. FedRAMP High. DoD IL5 and IL6. PCI DSS, HIPAA, IRAP, GDPR. More than eight years of deep compliance, audits, evidence collection and demonstrating controls, least privilege principles and processes. Auditors want the log line, the policy, the rotation schedule, the bit of config that shows the control was on at 03:14 on a Tuesday in March.

That work changes how you read and digest a security framework. Yes, we need to think about how we can implement and prove it, but put yourself in the attacker's mind as well. If a breach occurs, how will it be contained, and what are the business ramifications and fallout?

When Anthropic published its Zero Trust framework for AI agents last week, I read it the way I'd read a control catalogue before a readiness assessment. And the thing that struck me, now that I'm at Solo and closer to the agentic stack than I've ever been, is how much of it we already answer out of the box.

I will cover the framework first, then where the Solo products line up against it.

What the framework actually says

It's vendor-neutral, which is exactly why it's worth your time. Three maturity tiers, Foundation, Enterprise, and Advanced, across seven control domains: identity, access and privilege, tool governance, observability, input and output, integrity and recovery, and governance. You climb the tiers as the stakes rise. Foundation for getting started, Enterprise for most serious deployments, Advanced for regulated and high-consequence work, which is the world I've mostly lived in.

The first is a design test: does a control make the attack impossible, or just tedious? That distinction does a lot of work. Friction controls, rate limits, an extra hop, a non-standard port, all assume the attacker eventually gets bored and goes home. An agentic attacker doesn't get bored. It has unlimited patience and a per-attempt cost rounding to nothing. A speed bump only works on someone with somewhere else to be. So you stop counting on friction and start preferring controls that remove a capability outright. Cryptographic identity. Tokens that expire in minutes. Actions the system simply cannot perform, rather than ones it only makes awkward.

The second is OWASP's framing of least agency. Least privilege asks what an identity is allowed to reach: a set of resources and scopes. Least agency asks a different question, what a tool is actually allowed to do, how often, and where. The two come apart in practice. An identity can hold a perfectly valid token for a database and still be the wrong thing to let run an unbounded delete. Least privilege passes it, because the scope is granted; least agency stops it, because the action isn't. A database tool gets read-only queries. An email tool gets no send or delete. That's the right unit of control for agents, and it's the one most current setups miss, because they're still authorising at the scope level when the risk lives at the individual tool call.

The third is just a sense of pace. The framework is explicit that the baseline keeps moving. Today's Advanced becomes tomorrow's Enterprise, and Enterprise becomes Foundation. The Foundation baseline has already moved: static API keys, friction-based MFA, and identity-by-label no longer count as a starting posture. Anyone who's watched a compliance baseline tighten between assessment cycles will recognise the pattern.

The threats it catalogues are the agentic ones you'd expect, and a couple that should worry you more than they do:

• Prompt injection, direct and indirect. The indirect form is the harder one, because models can't reliably separate information they're reading from instructions they should follow. Microsoft's spotlighting technique, which clearly delimits the untrusted content, cuts that success rate from over half to under two percent, which tells you the problem is largely about marking what's trusted.
• Tool poisoning and rug pulls. A tool you trusted is quietly swapped for one that isn't.
• Tool chaining. This is the one I'd put on the risk register first. Combine a legitimate internal tool with a legitimate external one to move data out, and there's no malware to find. Every call runs through trusted binaries under valid credentials, so host-based monitoring sees nothing. You only catch it at the protocol boundary, which matters a great deal for where you put your controls.

What this looks like from the audit side

The framework is organised around evidence, not aspiration. Each tier is a set of things you can demonstrate. Unique cryptographic identity per agent. Short-lived tokens. Immutable audit trails. Per-action authorisation. Provenance chains from input to output.

If you've been through FedRAMP or DORA, you'll recognise that shape immediately. It's a control matrix waiting for a responsibility split and an evidence column. And the cost of any control framework isn't the architecture, it's the integration and the proving. Every separate product you bolt together is another data flow to diagram, another credential boundary to defend, another logging format to normalise, another vendor questionnaire, another thing the assessor pulls on. I've felt that cost directly. Every time we bolted another point tool onto the stack, the next audit got harder: another data flow to diagram, another log format to reconcile, another boundary to justify.

That's the lens that makes the Solo overlay interesting. Not feature by feature, but as a way to collapse the number of moving parts an auditor has to reason about.

Where the Solo stack lines up

The stack is three planes plus a mesh, and they map onto the framework's domains more cleanly than I expected when I started checking them against the docs rather than the marketing.

Identity, the foundation of all of it. Solo Enterprise for Istio, running ambient mesh, gives every workload its own SPIFFE identity and mutual TLS, and accepts connections only from the specific callers a policy names. This is the right primitive for agentic workloads precisely because they run as ordinary Kubernetes workloads: every agent, MCP server and tool pod is issued a cryptographic identity by the mesh, not a shared service account or a network rule, so the same agent moving to a different node or namespace keeps the identity it is authorised under. The scope is wherever the mesh reaches, the cluster by default, and workloads on VMs where ztunnel extends the mesh to them, which for an agentic platform is everywhere the agents actually run. That's the framework's strongest single line stated by a project that doesn't sell the framework: identity-based isolation is the primary control, and network segmentation is only a backstop. For anyone who's argued with an assessor about east-west traffic, having identity as the primary control rather than a firewall rule is the difference between a clean finding and a long conversation. I walk the handshake end to end, from RootTrustPolicy to the mTLS exchange, in the trust and identity lab.

The data plane, where most of the control lives. agentgateway parses the MCP wire protocol and exposes the tool name as a policy variable, so authorisation runs as CEL expressions against specific method invocations like list_tools and call_tools. Tools a caller isn't allowed to use get filtered out of the list response entirely, so the agent never even sees them. That's least agency, enforced at the individual call, not approximated with OAuth scopes. It's also where the framework's ladders live: RBAC to attribute-based access to continuous authorisation, and static least privilege to just-in-time grants that expire on their own. Add short-lived tokens, on-behalf-of token exchange (RFC 8693) so a worker agent acts as the original user rather than inheriting blanket rights, and built-in OpenTelemetry, and you've covered access, tool governance, and the observability you need to actually catch tool chaining, all on one surface. Worth noting: agentgateway became the fourth hosted project at the Agentic AI Foundation under the Linux Foundation this week. For a regulated buyer, an Apache-licensed control point governed in a neutral foundation is a much easier supply-chain story than a single-vendor proxy.

Sandboxing, so a tool call can't reach further than the call itself. agentgateway can collapse a wall of MCP tools into a single code-execution tool and run that code in an isolated sandbox: the model writes code against the tools rather than firing them one by one, and the code runs with no ambient access to the host, the cluster, or any credential it wasn't explicitly handed. In the framework's terms this is the isolation control, sandboxed execution, which it places at the Enterprise tier. It closes the tool-chaining gap from the other side. Even a call that passes authorisation executes inside a boundary it cannot step outside, so the blast radius of a poisoned tool or an injected instruction stops at the sandbox wall. I built that out, with the execution boundary drawn explicitly, in the code mode and sandboxing lab.

The catalogue plane, which is the supply-chain answer. agentregistry is a signed, scored catalogue of the MCP servers, agents, skills, and models in play, with cryptographic signatures and attestations, and the gateway enforces against it at runtime. That's the registration-plus-runtime-enforcement pattern that defeats poisoning and rug pulls, and it's also the honest answer to shadow AI: import from wherever your teams are already pulling things, score and verify, and hand them a pre-approved set. It reaches past the cluster too. The same catalogue can manage cloud-hosted runtimes like AWS AgentCore as first-class entries, so an agent running in Bedrock lives in the same audited catalogue as the ones in your cluster rather than off to one side. Its discovery side gives you visibility into shadow AI running outside the catalogue, and drift detection, flagging a service that turns up outside the approved set rather than letting it go unnoticed, is the next thing on the roadmap. If you've ever had to produce a software bill of materials under pressure, you'll appreciate having the agentic equivalent as a living catalogue rather than a spreadsheet you reconstruct the week before the assessment.

The control plane, for lifecycle and the human in the loop. kagent runs agents as first-class Kubernetes workloads, versioned through CRDs and the same GitOps flow as everything else, with human-in-the-loop approval gates on the calls that warrant them. Versioned, declarative, reviewable. That's configuration integrity and recovery in the framework's terms, and it's the same discipline any regulated platform already applies to its other workloads, extended to agents instead of carved out as a special case.

Put those together and a good chunk of the highest-leverage controls in the matrix, per-tool authorisation, signed catalogue, short-lived identity-bound tokens, RBAC moving to ABAC, identity-based isolation, human-in-the-loop, sit on one config surface rather than across several products you wire together and then have to explain.

The compliance payoff

This is where it gets concrete for an EMEA audience. DORA Article 28 wants you to manage and evidence ICT third-party risk, including the tools and services your agents reach. NIS2 Article 21 wants detection, response, and governance you can show. PCI DSS wants strict scoping and access control around anything near cardholder data, and it does not care how clever your agent is. The pattern across all three is the same: named identity, least privilege, enforced boundaries, and an audit trail that survives scrutiny.

Those are the exact controls the Anthropic framework puts at Foundation and Enterprise, and they're the ones the Solo stack provides natively. The value isn't any single feature. It's that the evidence comes from fewer places. One identity model, one policy surface for tool calls, one catalogue for what's allowed to run, one tracing pipeline. Fewer integrations means fewer data flows to diagram, fewer trust boundaries to justify, and a smaller pile of artefacts to assemble when the assessment lands. I've assembled that pile the hard way more times than I'd like. Anything that shrinks it is worth real money, and more importantly, worth real time during the weeks when time is the thing you don't have.

Here is the overlay in one view, each control area against the part of the stack that answers it:

The baseline keeps moving

The framework's closing point is the one I'd leave you with too. The tiers are not a finish line. The baseline moves, the way every compliance baseline I've worked to has moved, and the architectures that stay ahead are the ones where identity, tool governance, and lifecycle were designed to compose rather than bolted on after the first incident or the first failed audit.

That's the part of moving to Solo that's kept my attention. I spent years proving controls were in place across platforms that were never built with proving in mind. This stack was built with it in mind, and it lines up against an independent zero trust framework closely enough that the mapping nearly writes itself.

I'll publish the capability matrix with the full overlay separately, so you can hold it up against your own controls. If you're doing this work in a regulated EMEA shop, I'd like to hear where your mapping comes out differently from mine.