Vengtoo guardrail for LiteLLM

Use LiteLLM with Vengtoo as the authorization brain for MCP tool calls. A LiteLLM guardrail intercepts each MCP tools/call and asks Vengtoo whether the agent may run that tool, with those arguments, before it executes.

Vengtoo decision	Guardrail returns	LiteLLM behavior
decision: true	should_proceed = True	the tool call runs
decision: false (or PDP error)	should_proceed = False	the tool call is blocked, fail-closed

Run

pip install litellm vengtoo
export VENGTOO_API_KEY=vgt_live_...

# vengtoo_guardrail.py must be importable (same dir or on PYTHONPATH)
litellm --config litellm_config.yaml

Every MCP tool call routed through the proxy is now authorized by Vengtoo before it runs. A denied call comes back to the agent as a blocked tool invocation rather than executing.

How it works

A CustomGuardrail subclass reads the tool name + arguments, builds a single AuthZEN evaluation (subject{ai_agent} / action{invoke} / resource{mcp_tool, id=tool, properties=args}), calls the Vengtoo PDP via the vengtoo SDK, and returns should_proceed from the decision. Arguments ride as resource.properties, which is what enables argument-level (ABAC) decisions: the deny can be on the destructive SQL, not just the tool name. Fails closed if the PDP errors. The decision path is identical to the other MCP integrations; only the LiteLLM guardrail hook is LiteLLM-specific.

Notes

LiteLLM API drift (read this)

LiteLLM's MCP guardrail surface (the exact hook name (pre_mcp_call vs async_pre_mcp_call), the request/response object field names, and the config mode key) has changed across releases. The guardrail reads the tool name/arguments defensively and exposes both hook names, but if a call is unexpectedly allowed/denied, confirm the signature against your installed litellm version. This example was written against the documented MCP-guardrail shape; it was not run end-to-end here.

• Subject identity. The guardrail authorizes as a fixed subject (VENGTOO_SUBJECT, default agent:litellm). For per-user identity, derive the subject from the request in the guardrail.

Security: Vengtoo does not independently verify the subject

If you derive a per-caller subject, it MUST come from LiteLLM's own authenticated session/key, never from an unverified client-supplied header or claim. Doing so allows subject impersonation within your tenant.

• PDP endpoint. Decisions go to the AuthZEN evaluation endpoint via the SDK (pdp.vengtoo.com). Point the SDK at a local Vengtoo Agent for sub-ms, in-network decisions.
• Latency. The SDK call runs in a worker thread so it doesn't block the proxy's event loop.