Authorization policies

Authorization policies narrow a request that has already passed Axec’s authority checks. A policy has a stable key, an effect of deny or step_up, one surface-bound target, and an optional Boolean CEL condition.

Choose a bounded target

Every target selects exactly one surface: mcp, proxy, or credential_release. Common selectors can narrow by principal kind, requesting Application, gateway Application, User, current directory group, or Connector. MCP targets can additionally select a capability. Proxy targets can select a normalized method and an exact or trailing-prefix path.

Do not put capability, method, or path selectors on credential_release. Axec rejects incompatible or unknown target fields rather than activating a rule that can never match.

key: protect-production-writes
effect: step_up
approval_flow: production-review
target:
  surface: proxy
  connector: crm
  method: POST
  path: /v1/accounts/
when:
  environment: axec.policy.v1
  expression: request.authorization.mode == "delegated"

Treat this as an illustrative operator configuration shape; use the deployment’s configuration schema when reconciling policies.

Write conditions against trusted context

axec.policy.v1 exposes one typed request assembled from server-resolved facts. Useful fields include:

• request.subject.kind, and User ID, email, and current directory groups when the subject is a User
• request.client.application_key, optional authenticated request.actor.workload_uri, and request.gateway.key
• request.authorization.mode, operation scope, delegated root mode, and Grant usage channel
• current Grant and Connector facts under request.resource
• an MCP capability or normalized proxy method and path under request.action

Arguments, headers, bodies, prompts, arbitrary token claims, and caller-supplied identity metadata are deliberately absent. Expressions must compile to bool and stay within fixed evaluation bounds.

request.subject.kind == "user" &&
request.authorization.mode == "delegated" &&
request.action.method == "POST"

Understand precedence

Axec evaluates every applicable rule. Any matching deny wins. Otherwise, matching step_up rules must resolve to the same approval flow; conflicting flows fail closed. If no restrictive rule matches, the result is allow, meaning only that policy did not further restrict the admitted authority.

Configuration replacement is atomic. A duplicate key, invalid expression, unresolved approval flow, or unsupported target preserves the previously active configuration.

Troubleshoot a decision

• Unexpected deny: inspect the closed reason code, evaluator version, snapshot digest, and sorted matched rule keys. Missing trusted context or evaluation errors deny by design.
• Rule did not match: confirm the request surface and normalized selectors, and remember that stale directory membership is not policy context.
• Unexpected step-up conflict: check whether multiple matching rules reference different approval flows.
• Policy appears to grant access: it cannot. Recheck the underlying Connection, Grant or attachment, scope, capability, expiry, and revocation state.

Next, configure human approval or inspect governance evidence.