Policies & permissions

Baseline permissions

The first layer answers “what is this agent generally allowed to do?” A permission matches an exact or wildcard action (and optionally a resource) for one agent, and resolves toALLOW, REQUIRE_APPROVAL, BLOCK, or ALERT.

Conditional policies

The second layer is conditional rules layered on top — “under these conditions, what should Aegis do?” A policy applies org-wide or to a specific agent, matches a scope, and evaluates a set of conditions that must all be true (AND, not OR) against the action’s context. For example: “if action is refund.issue and amount is greater than 500, require approval.”

How a decision is resolved

When an agent asks Aegis about an action, both layers are checked and combined by strict precedence:

BLOCK beats REQUIRE_APPROVAL beats ALERT beats ALLOW — regardless of priority ordering between policies. If anything blocks the action, it’s blocked, full stop.

ALERT is not an enforcement point — the action still proceeds — but the match is recorded as a detected violation and raises a security alert, so a policy can flag risky behavior for review without interrupting the agent.

An action with no matching permission and no matching policy resolves to BLOCK. The engine fails closed by default — it never silently allows something nobody explicitly permitted.

Every decision is recorded

Every evaluation is persisted with a deterministic, human-readable reason and the full context that produced it, so decisions are auditable and explainable after the fact — not just in the moment. You can test any action against your real policies from the in-app Policy Tester before wiring anything up.