Provider and model allowlists are a policy-as-code control that restricts which model providers and which exact model identifiers an agent is permitted to call at runtime. In Claw EA, you express the rule as a WPC (Work Policy Contract) and enforce it at the execution layer using CST (scoped token) and clawproxy, so the agent cannot bypass it with prompt tricks.

This matters because prompt-only guardrails can be overwritten by prompt injection or by tool misuse. A permissioned execution layer fails closed: if the provider or model is not on the allowlist, the call does not happen and you get verifiable evidence of what was attempted.

Step-by-step runbook

  1. Pick the concrete set of allowed providers and models for the job. Write them down as exact identifiers you expect to see on the wire, for example “openrouter” plus a short list of OpenRouter model ids.

    Do not start with “any model from provider X”. Start with the smallest list that supports the workload.

  2. Encode the allowlist as a WPC (Work Policy Contract) and publish it to the WPC registry (served by clawcontrols). Treat the WPC hash as the stable reference for the policy version.

    If you need different allowlists per environment, publish separate WPCs and keep the hashes distinct.

  3. Issue a CST (scoped token) from clawscope for the agent run. Enable optional policy hash pinning so the CST is only valid when enforcing the specific WPC hash you intended.

    This prevents “token reuse with a looser policy” when jobs are replayed or moved across environments.

  4. Route model traffic through clawproxy and configure the agent runtime to use it as the model provider path. Claw EA supports OpenRouter via fal routed through clawproxy (shipped).

    If you use other model vendors, integrate via official API or via an MCP server, then enforce the allowlist at the proxy boundary as part of an enterprise buildout.

  5. In OpenClaw (baseline agent runtime), keep local tool policy tight so the agent cannot introduce an alternate model client path. Use tool allowlists and sandboxing to reduce the chance of “side channel HTTP” to a provider endpoint.

    OpenClaw’s configuration model separates sandboxing (where tools run) from tool policy (which tools exist), which is useful when you want network-facing tools disabled by default.

  6. Run the job and collect the proof bundle produced by the harness. Ensure gateway receipts are present for each model call and that the receipts bind provider, model id, and job context.

    Store the resulting artifact in Trust Pulse when you need a stable audit/viewing location.

Threat model

Threat What happens Control
Model swapping An agent silently switches from an approved model to a higher-risk or non-reviewed model with different behavior. WPC allowlists exact provider and model identifiers; clawproxy rejects calls outside the list and emits gateway receipts for approved calls.
Provider switching to bypass governance An agent routes calls to a different provider to evade logging, content policy, or cost expectations. Execution uses a permissioned path: CST is issued for the job and can pin the WPC hash; clawproxy enforces provider allowlist at the gateway boundary.
Prompt injection disables “rules” A malicious input convinces the agent to ignore system instructions and call an unapproved model. Prompt text is not the enforcement point; the enforcement point is the proxy plus CST scope hash and pinned policy hash.
Shadow client inside tools The agent uses a general-purpose HTTP tool or shell to call a provider API directly, bypassing the proxy. OpenClaw tool policy reduces available network tools; sandboxing limits filesystem and process access. For stricter environments, egress allowlists enforced outside clawproxy are optional and can be implemented.
Replay of a permissive token An attacker reuses an old token to run the same agent with a looser allowlist. Marketplace anti-replay binding uses job-scoped CST binding (shipped). Policy hash pinning ties the CST to the intended WPC.

Policy-as-code example

The core idea is that the allowlist is an auditable artifact (WPC) and the runtime authorization (CST) is bound to it. Keep the policy strict: list allowed providers, list exact allowed models, and require proxy mediation for model calls.

{
  "wpc_version": "v1",
  "control": "provider_model_allowlist",
  "allowed": {
    "providers": [
      "openrouter_via_fal"
    ],
    "models": [
      "openrouter:anthropic/claude-3.5-sonnet",
      "openrouter:openai/gpt-4o-mini"
    ]
  },
  "requirements": {
    "model_calls_must_route_via": "clawproxy",
    "deny_on_unknown_model": true
  },
  "audit": {
    "require_gateway_receipts": true,
    "bundle_on_job_close": true
  }
}

/* CST issuance intent (conceptual) */
{
  "cst": {
    "scope_hash": "sha256:...",
    "pinned_wpc_hash": "b64u:... (optional policy hash pinning)"
  }
}

In OpenClaw, treat this as complementary to local tool policy. You still want OpenClaw tool allowlists and sandboxing configured so the agent cannot easily create a second route to the internet that bypasses the proxy boundary.

What proof do you get?

For each model call routed through clawproxy, you get gateway receipts that can be verified later. These receipts are designed to be concrete evidence of which provider and model were invoked, under which job context, and under which authorization.

At the end of the run, Claw EA produces a proof bundle that aggregates the relevant receipts and metadata needed for audit and verification. When you publish the artifact to Trust Pulse, reviewers can inspect the run without relying on the agent’s self-reported logs.

Rollback posture

Action Safe rollback Evidence
Tighten the model allowlist in the WPC Publish a new WPC hash with fewer models, then issue new CSTs pinned to the new hash. Leave old jobs verifiable by retaining old WPCs. WPC hash history plus proof bundles showing which hash was enforced for each job.
Revoke an in-flight CST Revoke via clawscope and rerun the job with a new CST. This is the quickest way to stop a run that is repeatedly attempting denied models. Gateway receipts stop for that job context; revocation records support incident review.
Remove a provider from allowed providers Publish a replacement WPC removing the provider and rotate the job configuration to only use the remaining approved provider paths. Receipts show provider value per call, so you can confirm the provider is no longer used.
Investigate a suspected bypass via tools Temporarily disable general network tools in OpenClaw tool policy and rerun in sandbox mode “all” while you diagnose. OpenClaw security audit output plus proof bundles demonstrating model calls still went through clawproxy.

If you need network-level egress allowlists, that is optional and can be implemented outside clawproxy. Treat it as a separate control that hardens the “shadow client” class of failures.

FAQ

Why is prompt-only “use model X” not enough?

Because prompts are not an enforcement boundary. An attacker can inject text that changes instructions, or the agent can take a tool path that ignores the prompt and calls another model anyway.

With a WPC plus CST and clawproxy enforcement, the call is blocked even if the agent asks for it, and you get receipts showing what was allowed.

What should I allowlist: model families or exact model ids?

Allowlist exact model ids. Families and aliases are where accidental drift happens, especially when providers introduce new revisions under similar names.

If you need flexibility, publish a new WPC when you approve a new model, then pin new CSTs to that WPC hash.

How does this relate to OpenClaw tool policy and sandboxing?

They cover different failure modes. OpenClaw tool policy and sandboxing reduce what the agent can do locally, while provider and model allowlists constrain what the agent can do over model calls.

Use both: local policy to reduce bypass routes, and clawproxy enforcement to make model usage verifiable.

Can I enforce this for Azure-hosted models or other vendors?

Yes, but do not assume native connectors. Integrate via official API or via an MCP server, then enforce the allowlist at the proxy boundary as an enterprise buildout.

Microsoft platforms also support their own governance controls and guardrails; treat those as complementary, not a substitute for execution-layer enforcement.

What do auditors actually review?

They review the WPC hash, the CST binding, and the gateway receipts inside the proof bundle. This gives a verifiable trail of which model calls happened under which policy.

Trust Pulse can be used as the stored artifact location for audit and viewing.

Sources