The model proposes. The system decides.
AEGIS Guard is designed to govern agents outside the model: authority that only narrows as work is delegated, policy written as code, and human approval bound to the exact action.
Mandates
Delegation can never add authority.
Delegate from the Execution agent
Parent scope
ap.schedule_payment / $5,000 unattended / 24 h / approved vendors only
Delegation valid
The child's scope is a subset of its parent's, so the plan may proceed.
Simulated with a small evaluator that runs in your browser.
Decisions
Checks in a fixed order. First failure settles it.
Proposed action
Conditions
- Mandate valid and unexpiredmdt_root is active
- Tool within Mandateap.schedule_payment is granted
- Amount within MandateWithin the hard limit
- Vendor in approved masterVendor record found
- No policy denies itNo deny rule matched
- Approval requirementWithin the unattended limit
Allow rule_permits
Human approvals
Approve an action, not a description.
Approvals in a chat thread cover a summary of what might happen. An AEGIS approval is designed to bind to a digest of the exact canonical action.
- ExactChange one parameter and the approval no longer applies.
- ExpiringIt lapses at a set time, and the record shows that it did.
- Single useIt is consumed by the action it approved.
- Re-checkedPolicy runs again at execution, because things change during a three-day wait.
- SeparatedThe person who requested the work cannot approve it.
Threat model
What Guard is for, and what remains.
| Threat | Designed response | Residual risk |
|---|---|---|
| Prompt injection through tool output | A model's output is never authority. The gateway enforces limits regardless, and tool outputs are labeled untrusted. | It can still mislead within the allowed scope, so scope must be narrow. |
| Over-broad permissions | Deny by default. Mandates narrow on delegation. | A poorly written policy. |
| Approval fatigue or deception | Approvers see exact parameters and evidence from records, not just a model's summary. | People can still approve badly. |
| Tool poisoning through MCP | Schema pinning and review. A changed digest forces another review. | A compromised upstream may misbehave within its schema. |
| Credential exposure | Brokered on the server side. Never in prompts or traces. | Compromise of AEGIS itself. |
| Ledger tampering | Hash chain, with periodic anchors in write-once storage. | This makes tampering evident. It does not make it impossible. |
Example workflow
Roll out a policy safely.
Start from deny
A new project denies everything until a rule permits it.
Write policy as code
Rules are versioned and reviewed, then stored as drafts.
Simulate
Replay past actions to see what would change. Planned for Phase 2.
Activate
A new version takes effect, and decisions cite it.
Watch
Hit counts and denial reasons show whether it is too tight or too loose.
Technical explanation
Two authorization layers.
People: role-based access to resources, covering who can edit a policy or view a trace.
Agents: Mandate plus policy on actions, covering what this step may do now. An agent's identity is tied to its version and project, never to a person's login.
Policy engine: we are evaluating purpose-built authorization languages rather than inventing one.
Guardrails complement this. Content checks can run as one step in a decision. They screen text, while Mandates limit authority. A system needs both.
Related capabilities
Is security blocking your agents?
Show us the questions you cannot answer yet.