Policies and approvals

Policies and approvals are controls over authority that Axec has already admitted. They cannot create a Grant, attach a Connector, expand a scope, or make an unavailable credential usable.

Policy narrows live authority

An Authorization Policy targets one surface: mcp, proxy, or credential_release. It can narrow by server-resolved facts such as subject, client Application, gateway, Connector, capability, normalized proxy method and path, and current directory group.

An optional CEL condition runs only in the typed axec.policy.v1 context. Caller arguments, headers, bodies, prompts, arbitrary token claims, and caller-supplied provenance are not policy inputs.

Every applicable rule evaluates against one immutable snapshot:

1. A matching deny wins.
2. Otherwise, matching step_up rules must select the same approval flow.
3. Otherwise, policy returns allow, meaning it did not further restrict the already-admitted action.

Invalid context, evaluation errors, incompatible targets, conflicting approval flows, and exceeded limits fail closed. Policy never contains a permit effect.

Approval pauses one exact action

A step_up decision creates an ActionRequest before Axec resolves an upstream credential, dispatches a call, or releases a provider token. The request binds the subject, client, optional workload actor, gateway, scope, Grant or attachment, Connector and action, canonical input, policy snapshot, expiry, idempotency binding, and correlation ID.

An Approval Flow selects who may decide that gate by exact tenant User email, current directory group, or Workspace administrator role. The first eligible approve or deny decision wins. Expiry never approves automatically.

Approval changes the request from awaiting_approval to approved; it does not execute the action. Polling reads only the safe status. The original authenticated client must retry the identical request, then Axec reloads live authority and current policy before allowing one execution attempt.

Changed input, expired approval, revoked authority, a current deny, or a different required flow prevents continuation. Mutating requests require idempotency, and outcome_unknown is terminal rather than an instruction to redispatch.

For configuration and troubleshooting, use Governance operations. For the resulting receipt, read Evidence.