Axemere.ai

Scenario: Approval Workflows

Require human sign-off before specific AI requests are allowed through. Approval workflows let you gate request patterns (sensitive workloads, expensive models, or high-risk actions) on an explicit decision from an authorized reviewer.

How it works

When a request matches a require_approval policy rule, the gateway:

  1. Terminates the original request immediately: returns HTTP 202 with an approval_id
  2. Creates a pending approval record: visible in the console under Govern → Approvals
  3. Pre-authorizes on approval: once approved, future requests matching the same workload, action type, and target host bypass the approval check

The gateway does not hold the HTTP connection open. The caller receives a 202 and must retry the request after approval is granted.

Example: require approval for a sensitive workload

Gate all requests to the customer-comms workload on explicit approval:

targets:
  - id: approval.customer-comms
    priority: 100
    when:
      field: context.workload_id
      equals: wl-customer-comms
    effect:
      decision: require_approval
      reason: "Customer-facing content requires review"

Policy rules are written in YAML and loaded via:

  • Free Gateway: YAML file on disk, reloaded with SIGHUP or PUT /v1/admin/policy-bundle
  • CP-connected: org overlay YAML in Policies → Advanced tab; pushed by the control plane

Application-side handling

When a request hits an approval rule, the gateway returns HTTP 202:

{
  "approval_id": "apr-01hx..."
}

Your application should store the approval_id and retry the original request after the approval is granted. There is no webhook or push notification; the caller is responsible for retrying.

Once approved, the next matching request (same workload, action type, target host) proceeds without triggering the approval check again.

Reviewing requests in the console

  1. Go to Govern → Approvals in the console
  2. Filter by Pending to see requests awaiting review
  3. Review the request details: workload, model, estimated cost, attribution
  4. Click Approve (no body required) or Deny (reason required)

Reviewing via the API

# Approve a pending request
curl -s -X POST "https://gw.your-company.com/v1/admin/approvals/apr-01hx.../approve" \
  -H "MVGC-Admin-Token: $MVGC_ADMIN_TOKEN"

# Deny a pending request
curl -s -X POST "https://gw.your-company.com/v1/admin/approvals/apr-01hx.../deny" \
  -H "MVGC-Admin-Token: $MVGC_ADMIN_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"reason": "Use a lower-cost model for this task"}'

Risk-score based approval

You can also trigger approval workflows based on the request's risk score rather than a fixed rule. In the console, go to Policies → Risk and set a risk score threshold above which requests require approval. This requires no YAML; it is a console-only setting.

Next steps