Policy Reference
The field-by-field policy reference is maintained in Core, generated from the
same schema aa-gateway validates against:
Core policy reference.
This page is a summary and a router to it — it does not restate field types,
defaults, or validation rules, so it cannot drift out of sync with the schema
the way a second hand-written copy can.
What a policy document is
A policy is a YAML document that scopes what an agent may do — which domains it can reach, which tools it can call, how much it can spend, and more. The gateway evaluates it and returns an allow, deny, or rate-limit decision; whether that decision is enforced before the action runs depends on which path the request took — see Security model for the per-path posture.
Where each block is documented
| Block | What it controls | Core section |
|---|---|---|
| Document formats | Envelope vs. flat YAML | Document formats |
Top-level fields, scope | Which agents a policy applies to, cascade order | Top-level fields |
network | Outbound domain allowlisting | network |
schedule | Active-hours time windows | schedule |
budget | Spend caps, currency, reset behaviour | budget |
data | Sensitive-data detection and redaction | data |
tools | Per-tool allow/deny/approval and rate limits | tools |
capabilities | Coarse-grained capability grants | capabilities |
approval | Escalation overrides | approval |
Core also documents filesystem and syscalls blocks (Linux host-level
scope) that this hub does not summarise separately — see
filesystem
and syscalls
in the Core reference.
What this page does not cover
Field types, defaults, validation rules, and enumerated valid values live only in the Core reference above — restating them here is exactly the duplication that let this page fall out of sync with ADR 0033 §2/§4 on when a policy decision actually binds before execution. If you need a field’s type or default, follow the link.
Going deeper
For worked example policies (minimal budget-only, network allowlist, capability control, rate-limiting with approval, business-hours schedule, PII detection, and a full policy exercising every section), see Core’s example policies.
Related documentation
- Security model — IronClaw layers and policy engine position in the stack
- Managed control plane — design preview — planned, not available
- Managed SaaS onboarding — design preview — planned, not available
Last updated: 2026-09-07 by AI Agent Assembly Team