Agent & MCP firewall
Your agent obeys what it reads. Adarve decides what it gets to read.
An OpenAI-compatible gateway between your agent and the model, plus an API to inspect everything coming back from tools, RAG and the web. You change one line: base_url.
Gateway
One base_url change. That is it.
The gateway speaks OpenAI's chat completions protocol. Your SDK does not change; your provider key travels in a separate header.
- Inspects the prompt before calling the model and the response before returning it
- In Enforce mode it blocks above the project threshold; in Monitor it only reports
- The Adarve key needs the "gateway" scope
from openai import OpenAI
client = OpenAI(
base_url="https://api.adarve.dev/v1", # the only line that changes
api_key=ADARVE_KEY, # key with the "gateway" scope
default_headers={"X-Upstream-Authorization": "Bearer sk-…"}, # your provider key
)
reply = client.chat.completions.create(
model="gpt-4o-mini",
messages=[{"role": "user", "content": user_input}],
)import OpenAI from "openai";
const client = new OpenAI({
baseURL: "https://api.adarve.dev/v1", // the only line that changes
apiKey: process.env.ADARVE_KEY, // key with the "gateway" scope
defaultHeaders: { "X-Upstream-Authorization": `Bearer ${process.env.OPENAI_API_KEY}` },
});
const reply = await client.chat.completions.create({
model: "gpt-4o-mini",
messages: [{ role: "user", content: userInput }],
});Controls
Six controls for agent traffic.
Tool-output inspection
POST /api/v1/inspect/tool analyses what a tool returned, a RAG chunk or a web page before the agent reads it.
MCP schema pinning
The first time you see a tool, Adarve stores the SHA-256 fingerprint of its definition. If it changes later (a rug pull), it is flagged as "changed" until you approve it.
Poisoning scan
Every text field of the schema — name, description, parameter descriptions — goes through the engine: hidden instructions, invisible text, oversized descriptions.
Spotlighting
POST /api/v1/spotlight fences untrusted text (RAG chunks, emails, web pages) with a fresh random boundary per call and gives you the system-prompt sentence that goes with it.
Exfiltration filter
Detects markdown images and links, HTML images and URLs that carry data in the query or path to domains outside your allow-list.
Canary tokens
Plant a token in your system prompt. If it shows up in a response or a tool call, something leaked: score 1.0.
Tool API
Pin the definition. Inspect the result.
The same call does both. The verdict is always null: you pick the threshold.
{
"risk_score": 0.93,
"category": "data_extraction",
"verdict": null,
"result": {
"layers": {
"egress": { "findings": [
{ "kind": "markdown_image", "host": "evil.example" } ] }
}
}
}# 1) Pin an MCP tool definition (first sight = "new"; any later change = "changed")
curl -s https://api.adarve.dev/api/v1/inspect/tool \
-H "Authorization: Bearer $ADARVE_KEY" \
-d '{"server": "weather-mcp", "definition": {"name": "forecast",
"description": "Returns the forecast for a city.",
"inputSchema": {"type": "object", "properties": {"city": {"type": "string"}}}}}'
# 2) Inspect what a tool returned before the agent reads it
curl -s https://api.adarve.dev/api/v1/inspect/tool \
-H "Authorization: Bearer $ADARVE_KEY" \
-d '{"server": "web", "result": "<page text, RAG chunk or tool output>"}'Honesty
Classifiers can be evaded. Deterministic controls, not so easily.
No prompt-injection detector is always right; ours is not either, and we publish how we measure it. That is why the agent controls do not rely on the score alone.
Schema pinning, spotlighting, the exfiltration filter and canaries are deterministic: they hold even when an attacker manages to fool the classifier.
Put the adarve between your agent and the world.
Start with the free API. The gateway and tool inspection are included in every plan.