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?
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.
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.
The execution-layer approach makes sense.
Where are production agents currently enforcing these permissions—inside the agent, in the tool layer, or externally?