AgentPolicy
Allow, deny, and approval-required decisions over tenants, capabilities, models, tools, regions, and cost.
Why it exists#
An agent that can call any model, reach any tool, and spend without limit is not something a regulated organisation can deploy. Policy is where those limits are written down, evaluated before the agent runs, and recorded as evidence afterwards.
Policy runs before the agent#
The gateway evaluates policy after it has resolved a candidate agent but before it invokes anything. A denied request never reaches the agent, so a policy failure costs nothing and leaks nothing.
Evaluation order is fixed and worth knowing, because it determines which reason you get back:
- Deny rules first. An explicit deny always wins.
- Allow rules next. A value outside a non-empty allow list is a denial.
- Approval rules next, so a request that was going to be denied never waits on a human.
- The default decision last, when nothing matched.
Where policy is configured today#
The AgentPolicy CRD is v1alpha1 and currently descriptive only
— nothing reads it at request time. Applying one succeeds and it appears in
kubectl get agentpolicies, but it does not affect traffic. The operator emits a
PolicyNotEnforced warning event on every one so this is visible in
kubectl describe.
Enforced policy is configured through Helm values at policy.rules. See
Write a policy that allows traffic.
Per-agent policy composition needs precedence semantics for overlapping policies that are not settled yet. Enforcing a guess would apply rules nobody wrote, so the resource stays descriptive until that design lands.
Default-deny is the default#
With policy enforcing and no rules loaded, every request is denied with missing_policy. A
governance component that allowed traffic it had no instructions about would be worse than one that refused,
so the safe direction is the default one.
Full field list#
The CRD schema is documented in the generated CRD reference; the enforced value keys are in the Helm values reference.