AI agent policy engine

The control gap

Model instructions can influence behavior but cannot provide a stable authorization contract, idempotent decisions, review workflow, or independently verifiable reason for an external side effect.

Define canonical input before authoring rules. Tool names should be stable action identifiers rather than model-written descriptions. Resource strings should include type and namespace, such as `repo:acme/platform`. Identity state, delegator, task, purpose, environment, risk class, structured arguments, and amount should be separate fields. Reject a request when a rule depends on context the caller cannot resolve reliably.

Policy lifecycle is part of the engine. Drafts can be edited and validated; publication creates an immutable version; enforcement cannot be enabled without a published policy. Shadow mode evaluates the same request path without interrupting execution. Every receipt keeps the evaluated version and reason, so a later policy change cannot retroactively alter why an earlier call proceeded.

What good looks like

A versioned YAML policy returns allow, deny, or request-bound approval before execution and signs the exact decision context.

• Typed identity and action inputs
• Glob, threshold, and context conditions
• Immutable published versions
• Shadow and enforcement modes

A production workflow

1. Normalize the tool request
2. Evaluate the current published policy
3. Pause sensitive requests for approval
4. Bind execution to the original decision

Evidence to require

• Input and idempotency key
• Matched rule and policy version
• Reviewer and expiry
• Signed result and execution outcome

Buyer checklist

• Can the product enforce a decision before the external tool executes?
• Can policy distinguish the agent, delegated user, tool, resource, and environment?
• Can reviewers see the exact requested action and approve it without broadening future access?
• Does every allow, deny, and approval retain the policy version and reason?