Does AgentGuard bound LiteLLM?

The exact install we ran

The test used Python 3.11.14, LiteLLM 1.93.0, Node 20 or newer, AgentGuard Spend 0.15.13, and OpenAI 6.49.0.

python3.11 -m venv .venv311 .venv311/bin/pip install 'litellm==1.93.0' npm install @agentguard-run/[email protected] openai@latest

Start LiteLLM with litellm-config.yaml, bound to 127.0.0.1 on port 40124. Then point a guarded OpenAI client at that local endpoint:

import OpenAI from 'openai'; import { withSpendGuardOpenAI } from '@agentguard-run/spend/frameworks/openai'; const raw = new OpenAI({ apiKey: 'local-proxy', baseURL: 'http://127.0.0.1:40124/v1', }); const client = withSpendGuardOpenAI(raw, { policy, scope: { tenantId: 'acme', agentId: 'litellm-caller' }, capabilityClaim: 'read_only', config: { signingKeys, logStore }, }); await client.chat.completions.create(request);

Three real outcomes

We launched a real local LiteLLM proxy and routed its allowed request to a local OpenAI-compatible fixture. LiteLLM logged exactly one successful POST. Both blocked calls stopped in the Node client before reaching LiteLLM.

ALLOWED

action=allow projected=2c dispatched=1 seq=0

entryHash=75b8edd603168bcec15ba07b4fc6823bb4221e906ea4e5a7803cfec9105416ff

signer=d6821b36daf255dc signature prefix=6347505062b56c2ba882fb05

SPEND CAP REFUSED

action=block dispatched=0 seq=2

reason=Cap 'per_call=1c' exceeded (spent=0c, +call=2c, total=2c) to block

CAPABILITY CEILING REFUSED

action=block dispatched=0 seq=3

reason=Capability 'read_only' below required 'payment_execute'

LiteLLM: POST /v1/chat/completions 200 OK UPSTREAM_REQUEST count=1 model=gpt-4o-mini

Offline verification

OFFLINE_VERIFY valid=true entries=4 TAMPER_VERIFY valid=false reason="Signature or hash invalid at sequence 0"

AgentGuard never received prompts, completions, provider keys, or signing keys. LiteLLM and the configured model provider still receive allowed requests. Blocked requests never reach either one.

The boundary that matters

This is a client-side bound, not a LiteLLM proxy plug-in. Anyone who can call the proxy URL directly can bypass it. Restrict proxy ingress to the guarded application, keep the raw client private, and do not publish the proxy endpoint. If you need centralized enforcement for many untrusted callers, this client-side pattern is not sufficient.

LiteLLM integration verdictyes

spend cap: hard client preflight
capability ceiling: hard client preflight
blocked proxy calls: zero
offline chain: valid, tamper rejected

The complete tested client and local fixture are at sdk-openai-compatible.mjs and mock-openai-server.mjs.