Axemere.ai

Configuration Overview

For: Platform operators and administrators configuring Axemere Gateway.

Axemere Gateway is configured through three interlocking surfaces: credentials, workloads, and policies. Together they determine who can call which AI providers, under what conditions, and with what cost and attribution controls.

Table of Contents

The Conceptual Model

Workloads -- the calling service identity

Every request carries a workload_id. The gateway uses this to establish who is calling, what default attribution to apply, and which ingress modes are permitted. Without a registered workload, the request is rejected before policy evaluation begins.

Credentials -- the API key registry

Credentials are never selected directly by callers -- they are always selected by policy rules based on request context. The gateway resolves the selected credential_id to a live API key at execution time. Credentials support three modes: caller-supplied (BYOK), environment-variable alias, and inline secret.

Policies -- the governance layer

Policies evaluate every request through an ordered pipeline of governance layers, making decisions (allow, deny, downgrade, require_approval, rate_limit, quarantine) and selecting which credential to use. The default decision is deny -- no rule matching means the request is rejected.

Request Lifecycle

Request arrives with
workload_id + attribution

Workload lookup
applies default_attribution
checks allowed_connection_types

Policy engine evaluates
rule layers in order

targets -> credentials -> budgets -> risk -> transforms

Credentials layer
selects credential_id

Gateway resolves
credential_id -> live API key

Connector executes
request to AI provider

Key Interaction Points

Workloads feed into policy context. The fields context.workload_id, context.org_id, and default attribution all come from the workload registry. Policy rules reference these fields in conditions to control per-workload behaviour.

Policies reference credentials by ID. A select_credential: cred-openai effect in a policy rule refers to a credential_id defined in credentials.yaml. The credential must exist in the registry for the request to succeed.

Attribution flows through all three. Workloads provide default attribution fields (customer_id, account_id, project_id, labels). Policies can enforce, modify, or require specific attribution. Credentials record billing_owner for cost attribution. All three work together to produce a complete attribution trail in every execution record.

The policy default is deny. No rule matching means the request is rejected. Both workload registration AND credential registration AND a matching policy rule are required for any request to succeed.

CP-managed deployments simplify setup. When a credential is registered via the control plane (UpsertCredential), the CP automatically generates the matching policy rules (auto.allow.{provider}) in both the connectors and credentials layers. You do not need to author or manage those rules manually. Deleting a credential (DeleteCredential) removes the auto-rules atomically. New orgs also receive a "default" workload automatically on provisioning.

Common Themes

  • YAML-based configuration. All three surfaces are defined in YAML files loaded from configurable directories (MVGC_CREDENTIALS_DIR, MVGC_WORKLOADS_DIR, MVGC_POLICIES_DIR).
  • Hot reload without restart. All three support runtime updates via the admin API -- no gateway restart required.
  • Org-scoped. All three are scoped to an org_id, enabling multi-tenant deployments.
  • Validated at load time. Parse or validation failures result in denial. The gateway never silently operates on malformed configuration.
  • Auto-rules (CP-managed only). Credential registration auto-generates policy rules. Rule IDs with the auto. prefix are managed by the CP and must not be authored manually.

How They Fit Together

workload_id / org_id

credential_id

governs

evaluated in layer order

PolicyDecision

workloads.yaml
workload identity + default attribution

credentials.yaml
credential metadata + secret resolution

bundle.yaml
evaluation order + expiry

policy rule files, per-layer rules

Gateway policy engine

Connector execution

A workload is authenticated by the gateway using workload_id. The policy engine evaluates the request against the active policy bundle. Rules in the bundle select a credential by ID, which the gateway resolves to a live API key using the credentials registry.

Detailed Reference

  • Credentials -- API key registry, modes, secret resolution
  • Workloads -- service identity, default attribution, ingress modes
  • Policies -- bundle layout, rule language, per-layer files, add-ons
  • Identity and Attribution -- identity vs attribution fields, fill-in waterfall, examples by deployment pattern