Guard

A guard is a rule that decides whether a specific agent action should run, right now, given its context and arguments. Where scope decides whether a capability is grantable at all, a guard decides whether this call — to this recipient, for this amount, at this moment — is allowed.

Guards run before the side effect. The check is code in the path, not an instruction in a prompt, so there’s no “we’ll catch it in the nightly report.” Common guards include:

• Spend caps — deny payments over a per-action or daily limit.
• Domain allowlists — outbound mail only to approved domains.
• Approval thresholds — route high-impact actions to a human for sign-off.
• Change-freeze blocks — stop destructive actions during a freeze.
• Argument-level rules — db_query allows SELECT but blocks DELETE; deploy allows staging but gates production.

Guards are where your business judgment becomes enforcement. They turn “an agent can move money” from frightening into operational, because the worst case becomes a denied action and a log line rather than an irreversible mistake. Every guard decision — allowed, denied, or pending approval — is written to the audit trail.