We built Aegisora 2.0 — an execution security layer for AI agents
AI agents are moving from generating text to actually taking actions — calling APIs, using tools, accessing data, and executing workflows.
That creates a problem: model-level safety isn't enough when an agent can directly affect real systems.
We built Aegisora 2.0, an open-source runtime security layer that puts security and policy enforcement directly in the execution path of AI agents.
Every action can be evaluated and allowed, blocked, or escalated before execution, with the decision and execution lifecycle recorded for auditability.
The core idea is simple:
Don't just secure the model. Secure what the agent is allowed to do.
We're building Aegisora for developers building autonomous agents, agentic workflows, and AI infrastructure.
GitHub: https://github.com/aegisora-ai
Demo: https://github.com/aegisora-ai/aegisora/releases
We're especially interested in feedback from people building production AI agents: Where do you currently enforce permissions, policies, and execution controls?
This resonates a lot — how long did it take before you saw any real signal on it?
It took a few iterations to get meaningful signal beyond the basic allow/block path. The bigger insight came from testing what happens when authority, context, or downstream state changes after the initial decision.
This is very close to a boundary I've been testing independently.
The interesting case isn't only whether the execution layer evaluates an action as allowed, blocked or escalated.
It's what happens when authority changes after an earlier valid state but before the consequential downstream side effect.
For example:
T0: agent has permission + valid authority
T1: authority is revoked
T2: technical permission remains unchanged
T3: previously initiated action reaches the downstream resource/provider
At T3, what independently establishes whether the action still had authority to execute?
And if the request has already left the execution layer for an external provider, I've found “blocked” becomes a surprisingly strong claim unless there's downstream evidence supporting it.
That's led me to distinguish DENIED_CONFIRMED from DENIED_UNRESOLVED rather than treating every denied/stopped path as equivalent.
I'd be very interested in how Aegisora handles that boundary — particularly authority changes between policy evaluation and downstream consequence.
That’s a very important distinction, and it’s exactly the direction we’ve been pushing on.
We don’t want every stopped action to be treated as equally proven. The interesting question is what independently confirms the downstream outcome after authority or state changes.
That’s why we’ve been looking closely at confirmed vs unresolved enforcement outcomes, rather than treating “blocked” as the end of the story.
That convergence is interesting, especially the distinction between confirmed and unresolved enforcement outcomes.
I’ve now tested essentially that boundary in a live economic workflow. A real x402 payment settled on Base, while the application consequence remained unresolved. OpsWatch preserved those as separate determinations, then denied a subsequent retry before dispatch because the unresolved first action could have made another payment economically duplicative.
What I’m increasingly interested in is the handoff between our approaches: if your enforcement layer says an action was blocked, what evidence would you expose that lets an independent party determine whether the stop itself is actually established rather than merely reported?
That feels like a useful boundary to pressure-test together.
Exactly — and I think there's a second question immediately after that.
Suppose Aegisora blocks an agent action and can prove the enforcement decision occurred, but the available evidence cannot independently establish whether anything crossed the execution boundary before that block took effect.
You preserve that as unresolved rather than calling it “blocked.”
Now imagine another action is proposed on the basis of that state — retry, rollback, continuation, escalation or human override.
What evidence would Aegisora require before allowing that next action to proceed?
That's the boundary I'm now formalising with OpsWatch: not just determining what the previous evidence establishes, but whether that evidence is sufficient to support the new consequential action being proposed.
If you're already dealing with that problem in Aegisora 2.0, I'd be interested in comparing one concrete case rather than discussing it abstractly.
Curious how you handle the escalation path in practice, does escalated mean a human gets paged in real time, or does the agent fall back to a safer degraded action while it waits? That seems like the hardest part to get right without adding so much latency people just turn it off.
Escalation is an explicit decision state, not a silent fallback.
In practice, it can route the action into a human approval workflow or a defined safer path, depending on the deployment. The important part is that the agent doesn’t simply continue executing when the policy requires review.
The GitHub Release for 2.0 opens on the twelve-step platform diagram. The line a stranger would actually send is shorter: 1.x hardened the runtime; 2.0 is the same ALLOW / BLOCK / ESCALATE boundary, now as nine packages at 2.0.0. Put those three verdicts in the first paragraph. The IDENTITY → AUDIT stack belongs in the architecture doc.
On where enforcement holds: I have only seen a deny stick when it sits on the tool call. Inside the agent, the model talks itself into the action.
That’s a good catch. Intent → audit is something we’ve been making much more explicit because the decision itself is only useful if you can trace what led to it and what happened afterward.
And yes, the enforcement point matters most at the actual tool/execution boundary — not just in the model’s reasoning layer.
The execution-layer approach makes sense.
Where are production agents currently enforcing these permissions—inside the agent, in the tool layer, or externally?
The approach we’re building around is external to the model’s reasoning loop, at the execution boundary.
Aegisora sits in the runtime path around tools, providers, and actions, so authorization and policy enforcement don’t depend on the agent deciding to enforce its own permissions.
The execution boundary is the interesting part. Could be useful to dig into how that works in production over email sometime, if you’re open to it.