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 Keycloak, Auth0, Okta, and Ping Identity. Different platforms, but the same idea kept coming back: Never trust. Always verify.
For a long time, that felt like the end goal. Lately, though, it’s starting to feel more like the baseline.
The moment systems stop responding… and start acting
I created something called PlanetLedger during a recent hackathon for the Weekend Challenge: Earth Day Edition. The idea was simple: upload your bank statement to see your environmental impact.
It did not behave like a typical request-response app. An upload didn’t just return a response. It started a series of actions. Transactions were parsed. Vendors were categorised. Scores were calculated. Insights were generated. Notifications were sent out. The memory timeline was updated for the next run to ensure smooth operation.
A single call looked like this:
await openClawChainedTrigger(session.user, previousScore);
At some point, I realised this wasn’t a request-and-response anymore. The system just… kept going.
Where Zero Trust fits perfectly… and where it doesn’t
From a security point of view, everything was by the book. Every action checks permissions:
export function canPerform(scopes, resource, action) {
const required = FGA_RULES[resource]?.[action];
return required ? scopes.includes(required) : false;
}
Scopes are tight. Actions are verified. Nothing runs without approval. If you look at it through a Zero Trust lens, it’s solid. But the interesting problems didn’t show up at the point of access. They showed up after, when the question quietly shifted from “Can this happen?” to “Should this keep happening?”
When everything is valid… but something feels off
Take a simple 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,
});
}
}
There’s nothing wrong here. The user is authenticated. The system has permission. The logic is sound. And still, there’s a deeper question sitting underneath: Should this fire right now? Not “is it allowed”, but “is it appropriate at this moment?”
When behaviour starts to add up
One thing I liked about OpenClaw was how easy it was to attach behaviour to events:
registerOpenClawTrigger("transactions_uploaded", autoInsightOnUpload);
registerOpenClawTrigger("transactions_uploaded", highImpactAlert);
Individually, they’re harmless. But when combined, they can influence how a user views their financial behaviour. Nothing is technically wrong, yet the overall direction may shift. Not in a dramatic way, more like a slow accumulation of “reasonable” choices that begin to feel questionable when you zoom out.`
Intent is where things start to slip
The insights layer uses RAG to ground responses in user data:
const ragContext = buildRagContext(transactions, score);
const insights = buildAgentInsights(
transactions,
event.payload?.userContext,
score,
ragContext
);
Most of the time, it works well. But now and then, something feels slightly off. Nothing is broken. But something feels… misaligned. Like it latched onto something plausible and still missed what the user actually needed.
What surprised me was this drift. Small errors don’t stay small; they build up over time. A tiny issue early on can ripple through everything, and by the time it shows up, it’s hard to trace back.
Everything along the way can still look valid, which makes it tricky. It’s not always the outcome that’s concerning; it’s how it got there. And that’s not really something traditional access control is designed to catch.
So what actually helps?
I didn’t start with a framework. These were just things that made the system behave more predictably over time. Thinking beyond single requests helped. The system keeps making decisions, so you start paying attention to how those decisions unfold, not just whether they’re allowed. Keeping some parts simple made a difference, too. The scoring logic is intentionally straightforward, which makes it easier to trust.
Constraints helped more than expected. OpenClaw stays within clearly defined behaviour, and that keeps things from spiralling. Logging has to evolve as well. Not just what happened, but why it happened. When a chain goes sideways, “this event fired” rarely helps on its own. You want the reason, the inputs, and what the system thought it was doing.
And the traditional step-up authentication took on a slightly different meaning. It’s less about verifying identity at critical moments and more about asking whether a decision should go through at all.
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 that guide actions, spot patterns, notice when things seem off, and sometimes involve a human 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 key. Once systems shift from just responding to making ongoing decisions, trust isn’t a one-time check anymore. Instead, it’s something you evaluate continuously as the system operates.
