EQTY LabDocs

Agent Coverage

See, for each way of running an agent through Viper, which model traffic is signed and audited, what the Guardian Platform records about the agent, and what is not covered.

View as Markdown

Viper signs and the gateway audits the model traffic that passes through Viper. Anything that does not pass through it, the Guardian Platform does not see. This page sets out, for each way of running an agent, what is covered and what is not, so you can decide what else you need.

What every integration covers

For every integration on this page, each model request that reaches Viper is:

  • Signed with a key Viper holds: the named agent’s own, or the app’s when the request names no agent. If Viper cannot sign a request, it refuses it rather than sending it unsigned.
  • Checked by the gateway’s signature verification and your policies before it reaches the provider.
  • Recorded with the response and a reference to the agent’s state, captured when the session started. See Audit Trail.

The provider key stays the agent’s own. It passes through the gateway to the provider unchanged.

By integration

IntegrationModel traffic coveredRecorded about the agent
Claude CodeAnthropic APIConfiguration, skills and permissions derived from it, working directory and git details, and each request’s model, tools and system prompt
CodexChatGPT Codex backend with a ChatGPT sign-in, or the OpenAI API with an API key, which does not work yetAs for Claude Code
OpenCodeOpenAI only; Viper refuses to start OpenCode when its configuration or --model names another provider, sets its own OpenAI endpoint, or cannot be parsedConfiguration, working directory and git details, with no skills, permissions or request details derived
OpenClawAnthropic API, OpenAI API, ChatGPT backend and ChatGPT Codex backend; Viper refuses any otherConfiguration and the files in OpenClaw’s own workspace, with no skills, permissions or request details derived
LangGraphEvery model the Guardian Agent SDK routes for the graphThe agent definition the SDK registers: the graph, a fingerprint of each node’s code, its models and their settings, tools and package versions
Deep AgentsEvery model the SDK routes: the agent’s, and each sub-agent’sThe agent definition, with what Deep Agents adds and each sub-agent, and which sub-agent made each request
OpenShellAll of the agent’s model traffic, while the sandbox policy lets only Viper outThe agent definition, and the sandbox’s OPENSHELL_SANDBOX variable
Any other agentEvery model client pointed at viper proxyProcess provenance only, and the request is signed as the proxy, not as the agent

Every integration also records the provenance of the process that runs Viper: host, user, git details and the Viper version. Agent Configuration describes the recorded state in detail.

For OpenCode and OpenClaw, an empty permission set means Viper derived none, not that the agent was granted none. The raw configuration is still recorded.

What is not covered

These hold for every integration unless the row says otherwise.

Not coveredWhy, and what to do
What a tool doesThe model’s request to call a tool, and the result it is given, travel inside the recorded model traffic. Running the tool happens in the agent, so the shell commands it runs, the files it edits and the MCP servers it calls are not recorded.
The agent’s other network trafficPackage downloads, web fetches, API calls and database connections do not go through Viper. The Claude Code, Codex, OpenCode and OpenClaw wrappers can capture HTTP and HTTPS traffic with --egress-capture; see below.
Other traffic behind viper proxyviper proxy, which the LangGraph, Deep Agents and OpenShell integrations use, has no --egress-capture. Its --relay mode carries plain HTTP, or one service through a base URL, but does not decrypt HTTPS. In OpenShell, any other rule you add to the sandbox policy lets that traffic out unrecorded.
Agents started without ViperViper covers an agent only when the agent sends its model traffic through Viper. An agent started on its own, or a second model client pointed straight at the provider, goes to the provider unrecorded. Only OpenShell enforces the route; everywhere else it depends on how the agent is started.
Provider families Viper does not routeViper does not read Claude Code’s or Codex’s configuration for other providers, as it does for OpenCode and OpenClaw. If either is set up to use a provider beyond the ones in the table above, its requests go straight to that provider. For OpenCode and OpenClaw, Viper checks the configuration before it starts them, and a sidecar viper proxy checks the configuration files but cannot see a --model switch on the agent’s command line. With OpenClaw in sidecar mode, any family you do not give a proxy goes straight to the provider.
Per-step framework stateLangGraph node names, run IDs, thread IDs and checkpoints are not attached to requests.
Proof of where the agent ranSandbox variables such as OPENSHELL_SANDBOX, E2B_SANDBOX_ID and DAYTONA_SANDBOX_ID are recorded as the machine reports them. Any process can set them, so treat them as a claim, not as proof.
An agent that impersonates ViperThe agent runs as the same user as Viper, so it can read a software key and sign requests itself, with a state record it made up. The gateway still records those requests, but what they say about the agent’s configuration is the agent’s own claim. A hardware signer such as a YubiKey stops the key being copied, but not used: while it is plugged in, any process running as that user can still ask it to sign. See Key storage and signers.
The project’s filesViper records the agent’s configuration and skill files, and Codex’s and OpenClaw’s instruction files, not the files of the project it works on. Claude Code’s CLAUDE.md is not recorded. Of MCP configuration, only where each server is reached is recorded; MCP servers from claude.ai connectors, --mcp-config, .mcpb bundles or files a plugin manifest names are not recorded at all. Even among the recorded files, symbolic links and folders nested more than 16 levels deep are left out, and for OpenClaw so are files over 2 MiB.
Which agent behind a proxy sent a requestRequests sent to viper proxy without an agent header are signed as the proxy, so the Guardian Platform cannot tell the agents behind one proxy apart. Run each as a named agent, as the quickstarts do, and start the proxy with viper proxy --require-agent-header to refuse requests that name no agent instead of signing them as the proxy.
Which sub-agent sent a requestThe Guardian Agent SDK signs each Deep Agents sub-agent’s requests as the agent, and names the sub-agent in each one. It refuses a sub-agent it can’t route, such as a compiled or async sub-agent, or one the task tool would build as the agent runs, rather than let it send unsigned. Guardian does not yet show which sub-agent made a request; it is in the request’s signed state.

Egress capture

With --egress-capture, a wrapper also routes the agent’s other HTTP and HTTPS traffic through the gateway, which records it as relay exchanges. To read HTTPS, Viper decrypts it locally with its own root certificate, which it tells the agent’s tools to trust for the session. It still leaves gaps:

  • Programs that ignore the proxy settings connect directly, and are not recorded. These include Java programs, which do not read the proxy environment variables by default.
  • Programs that use the proxy but do not trust Viper’s certificate fail rather than connect, so nothing leaks, but their traffic is not recorded either. These include clients that pin certificates, and on macOS Go programs such as gh until you run viper ca trust.
  • Traffic that is not HTTP, such as git over SSH, is not captured.

To start Claude Code with egress capture:

bash
viper claude --egress-capture

On macOS, check whether Go programs such as gh will trust Viper’s certificate:

bash
viper ca trust --check
console
Local MITM root: <home>/.config/viper/mitm/ca.crt
Trusted for SSL in the login keychain (fingerprint match).

When the root is not trusted, the check exits with an error; run viper ca trust to add it.