Skip to main content
Open ruleset (MIT): Agent Threat Rules · Reference implementation (MIT): atr-lemonade-guard. This page documents an integration pattern — GAIA core takes no dependency on either.

​
Guarding the model endpoint

​
Overview

GAIA agents talk to Lemonade’s OpenAI-compatible endpoint (LEMONADE_BASE_URL, e.g. http://localhost:13305/api/v1). For local / air-gapped agents that is ideal — but the model + tool I/O is not inspected against agent-specific attacks: prompt injection in user/content, and tool poisoning (malicious tool descriptions or tool results) on the MCP path. This pattern adds a thin, fully-offline guard at the model I/O boundary: point LEMONADE_BASE_URL at a local OpenAI-compatible proxy that scans messages — and, on the MCP path, tool definitions + results — against an open ruleset before forwarding to Lemonade.

​
How it complements gaia.governance

GAIA already ships gaia.governance with a pluggable PolicyEngine (ALLOW / BLOCK / REVIEW). The two operate at different boundaries:

gaia.governance

Guards tool calls. PolicyEngine.evaluate_action(ActionRequest) returns a GovernanceDecision whose .decision is ALLOW / BLOCK / REVIEW for a given tool + args.

Guard proxy

Guards the model I/O boundary — prompt injection in content and tool poisoning on the MCP path, offline, before anything reaches Lemonade.
Run both for defense in depth.

​
Quick start

1

Try the reference implementation offline

The atr-lemonade-guard reference proxy runs fully offline — no model download, no network:
It sends a benign prompt (forwarded), a prompt-injection payload (blocked), and a tool-poisoning payload (blocked) through the proxy and prints a verdict table with the matched ATR rule ids.
2

Put it in front of Lemonade

Run the proxy with your Lemonade endpoint as the upstream, then point GAIA at the proxy:
The proxy is upstream-agnostic — Lemonade, Ollama, or any OpenAI-compatible server.
3

(Optional) cover the MCP path

If your agent uses MCP, route tool definitions and results through the same engine so poisoned tool descriptions / results are caught before the model acts on them (npm run demo:mcp shows this against a mock MCP server).

​
Vendor-neutral by design

The proxy is upstream-agnostic — Lemonade, Ollama, or any OpenAI-compatible server — and runs fully offline. GAIA core adds no dependency; the ruleset is linked externally, not vendored.

​
Honest limitations

Detection at the I/O layer is best-effort heuristic, not a guarantee. Content-layer rules catch known injection / tool-poisoning shapes but can be evaded by novel phrasings. Pair this with gaia.governance on the tool-call side, plus sandboxed execution and human-in-the-loop for high-blast-radius actions.

​
See also