Is Zero Trust Enough for Agentic Systems?

I’ve always had a soft spot for authentication systems.

About seven years ago, I started working on auth, and something just clicked. What began as login flows slowly turned into a deeper curiosity about identity, permissions, and how systems decide who gets to do what.

Over time, I’ve worked with tools like Keycloak, Auth0, Okta, and Ping Identity. Different platforms, same core idea kept showing up:

Never trust. Always verify.

For a long time, that felt like the finish line.

Lately, though, it’s starting to feel more like the starting point.

The moment systems stop responding… and start acting

During a recent hackathon, I built something called PlanetLedger. The idea was simple: upload your bank statement to see your environmental impact.

But under the hood, it didn’t behave like a typical app.

An upload didn’t just return a response. It kicked off a series of actions. First, it parsed transactions. Then, it categorised vendors. Next, it calculated a score. It also generated insights and triggered notifications. Finally, it updated a memory timeline for future runs.

All of that started from a single call:

await openClawChainedTrigger(session.user, previousScore);

Which quietly unfolded into:

transactions_uploaded → score_calculated → insights_generated → score_improved

At some point while building this, I realised something had changed.

This wasn’t a request-response system anymore.

It was a system that kept acting.

Where Zero Trust fits perfectly… and where it doesn’t

From a security perspective, I did everything by the book.

Every API route checks whether the agent is allowed to perform an action:

export function canPerform(scopes, resource, action) {
 const required = FGA_RULES[resource]?.[action];
 return required ? scopes.includes(required) : false;
 }

Scopes are tightly defined. Every action is verified. Nothing runs without permission.

If you look at this through a Zero Trust lens, it’s solid.

And yet, the most interesting problems I ran into had nothing to do with access.

They showed up after access was granted.

The real question isn’t “can it act?” — it’s “should it keep acting?”

Take something as simple as a high-impact alert:

export async function highImpactAlert(event) {
 const score = getScore(pseudonymize(event.userId));
 if (!score) return;
if (score.impactScore < 40) {
 pushNotification(event.userId, {
 type: "high_impact",
 title: "High-Impact Alert",
 body: ${score.highImpactCount} high-impact transactions detected,
 });
 }
 }

Everything here is valid.

The user is authenticated. The system has permission. The action is allowed.

But there’s a more subtle question hiding underneath:

Should this alert be triggered right now?

Because that depends on things Zero Trust doesn’t see.

Maybe the score calculation was slightly off. The categorisation step earlier in the pipeline may have misfired. Maybe the context wasn’t complete yet.

Each step is correct individually.

But the outcome might still be… wrong.

When valid steps create questionable behaviour

One of the most interesting things about the OpenClaw pipeline was how easy it was to compose behaviour.

You can attach multiple workflows to the same event:

registerOpenClawTrigger("transactions_uploaded", autoInsightOnUpload);
 registerOpenClawTrigger("transactions_uploaded", highImpactAlert);

On their own, these are harmless.

One generates insights. The other sends alerts.

But together, they begin to shape how a user interprets their financial behaviour. Add weekly reports, detect patterns, and make recommendations. Then, the system starts to influence decisions.

And that’s where things get tricky.

Because even if every individual step is valid, the overall direction can drift.

Zero Trust doesn’t track that. It validates moments, not trajectories.

Intent is where things start to slip

PlanetLedger uses a RAG layer to generate insights grounded in user data:

const ragContext = buildRagContext(transactions, score); const insights = buildAgentInsights( transactions, event.payload?.userContext, score, ragContext );

This works surprisingly well most of the time.

But occasionally, you’ll see something slightly off. A recommendation that technically makes sense but doesn’t quite match what you’d expect. A pattern that’s overemphasised. A suggestion that feels a bit… disconnected.

Nothing is broken.

But something feels misaligned.

That’s the gap.

Zero Trust ensures the system is allowed to act. It doesn’t ensure the system is acting with the right intent.

The part that surprised me: drift

The more I worked with chained workflows, the more I noticed this subtle effect.

If something is slightly off early in the pipeline — say, a categorisation edge case — that error doesn’t stay isolated. It propagates.

It affects scoring. Which affects insights. Which affects alerts. Which affects what the user sees.

By the time it surfaces, it’s no longer obvious where it started.

Everything along the way was technically valid.

But the outcome feels wrong.

That’s drift.

And it’s not something traditional access control is designed to catch.

So what actually helps?

I didn’t sit down with a framework for this. Most of these ideas came from trying to make PlanetLedger behave more predictably.

One thing that helped was thinking beyond request-level authorisation.

Because the pipeline continues after the initial API response, decisions are being made in a flow, not a single moment. That means authorisation needs to become aware of state, timing, and sequence — not just whether a token is valid.

Another thing that made a difference was leaning into deterministic rules where it mattered. The scoring system, for example, is intentionally simple and explainable. Not because an LLM couldn’t do it, but because predictability is a form of control.

The structure of OpenClaw itself also acts as a constraint. It’s deliberately minimal — no retries, no replay, no distributed guarantees. At first, that feels like a limitation, but it actually forces the system to operate within clear, bounded behaviour. It can only do what the registered workflows define.

Logging was another area that evolved quickly. Moving from plain logs to structured outputs made it easier to trace what happened. But even that surfaced a deeper need: understanding why a decision was made, not just what happened.

And then there’s step-up.

In traditional systems, step-up authentication is about verifying identity at critical moments. But in systems like this, identity isn’t usually the weak point. The question isn’t “is this really the user?”

It’s “Should this decision go through?”

That shift—from checking identities to validating decisions—looks small. But it changes how you make safeguards.

What this starts to look like in practice

After building something like PlanetLedger, the architecture stops being just about access control.

Zero Trust still sits at the base, making sure only the right actors can do the right things.

But on top of that, you start layering systems that understand behaviour over time. Systems guide actions. They spot patterns and notice when things feel off. Sometimes, they bring a human back in when the stakes are high.

None of these replaces Zero Trust.

They fill in the gaps that it was never designed to cover.

Final thought

Zero Trust is still essential.

Without it, systems like PlanetLedger wouldn’t hold up for a second.

But once systems move from simply responding to requests to continuously making decisions…

Trust stops being something you verify once.

It becomes something you evaluate, quietly and continuously, across everything the system does.

Comments

[Echo]

The "validates moments, not trajectories" framing is the right one, and the trajectory concept is what is missing from most agent governance writeups. Every step in the example you gave is individually allowed, individually audited, individually within scope. The system as a whole is drifting in a direction that nobody approved.

The cheap-and-honest version of trajectory tracking is a session-level "what is the user trying to do?" check that runs at the end of every step, not at the start. Most agent designs gate on entry: "is this tool call allowed?" They do not gate on exit: "after this tool call, is the agent's overall trajectory still the one the user asked for?".

The practical implementation is a small post-action hook that diffs the agent's stated intent (from the user prompt at session start) against the actual actions in the last N tool calls. If the diff gets large, the hook pauses the agent and asks the user to re-confirm. The "diff" can be a simple embedding similarity, or a regex of file paths touched, or just a count of distinct modules touched. The point is the drift signal, not the exact metric.

The thing this is not: it is not "the model is hallucinating" or "the tool is broken". The drift is a normal property of an agent doing useful work over time. The fix is to make drift visible and pauseable, not to prevent it.

The hardest part of implementing this in practice is that the user is rarely available to re-confirm mid-task. The two patterns that have worked for us: (a) a hard cap on "drift score" per session, after which the agent stops and posts a summary, and (b) a periodic "where are we?" check-in that the user can ignore. Both are imperfect, and both are better than the alternative of a session that quietly does more than the user asked for.