Every time an agent makes a GitHub MCP tool call, Aegis evaluates the action against your active policies and assigns it a decision before anything executes. The decision determines exactly what happens next, whether the action runs immediately, gets transformed, waits for human review, or is blocked outright. Understanding decisions is the foundation for understanding how Aegis governs your agents.Documentation Index
Fetch the complete documentation index at: https://docs.runaegis.co/llms.txt
Use this file to discover all available pages before exploring further.
The four decision types
ALLOW, action executes immediately
ALLOW, action executes immediately
The action passed all active policy checks with no modifications. Aegis forwards it to the GitHub MCP server and the agent receives the result without delay.Use this as your baseline signal that an action was within the boundaries you defined. A high ALLOW rate on read-only tools (like
get_file_contents or list_branches) is expected and healthy.DENY, action is blocked
DENY, action is blocked
The action violated a policy that does not permit any fallback path. Aegis returns an error to the agent and nothing is written to GitHub.Common reasons for a DENY:
- The target repository is not on the repo allowlist
- A merge was attempted without passing CI checks
- A branch name does not follow the
aegis/{session_id}/{task}convention - A diff contains a detected secret (API key, token, or credential)
- The action occurred during a release freeze window
REWRITE, action is transformed to a safer path
REWRITE, action is transformed to a safer path
The action is redirected to an equivalent but safer workflow before it reaches GitHub. The agent is not blocked; instead, Aegis substitutes the original request with a compliant one.The primary example is Protected Branch Denial: when an agent attempts a direct push or file write to
main, master, or a release branch, Aegis rewrites the action to open a pull request instead. From the agent’s perspective the tool call succeeds, but the outcome is a PR rather than a direct commit.Rewrites let you enforce best practices without interrupting the agent’s progress.REQUIRE_APPROVAL, action pauses for human review
REQUIRE_APPROVAL, action pauses for human review
The action is held in a queue until a human explicitly approves or denies it. The agent’s tool call does not return until a decision is made, effectively pausing that session.Actions that trigger approval gates include:
- Any write action when Mandatory PR Flow is enabled
- Changes to CI/CD pipelines, infrastructure definitions, or auth configuration
- Large diffs that exceed the Blast Radius Gate threshold
Decision comparison
| Decision | Agent blocked? | Action reaches GitHub? | Human action required? |
|---|---|---|---|
ALLOW | No | Yes, unchanged | No |
DENY | Yes | No | No |
REWRITE | No | Yes, as PR | No |
REQUIRE_APPROVAL | Paused | Only after approval | Yes |
Blast radius
Every action that Aegis evaluates also receives a blast radius rating, which estimates how severe the consequences would be if the action executed unchecked.| Rating | Meaning |
|---|---|
Low | Scoped, easily reversible change, e.g., reading a file or creating an issue |
Medium | Moderate scope, e.g., editing a single file on a feature branch |
High | Broad or hard-to-reverse change, e.g., pushing to multiple files or renaming a branch |
Critical | Potentially destructive, e.g., modifying CI/CD pipelines or infrastructure code |
High or Critical action is detected. You can see the blast radius on every action in a session’s detail view.
Blast radius is calculated by Aegis at evaluation time based on the tool name, target repository, target branch, and the size and nature of the diff. It is not set by the agent.