Skip to main content
Gemini CLI is Google’s coding agent for the terminal. It reads repositories, runs shell commands, edits files and calls external tools from the developer’s machine. The TrustGuard extension evaluates those actions through lifecycle hooks on the machine where Gemini CLI runs. TrustGate provides the MCP tools assigned to an application and, separately, can serve the model traffic itself.

NeuralTrust controls

The three are independent. Each has its own configuration in Gemini CLI and its own credential, and any one works without the other two.
Use separate credentials for TrustGuard and TrustGate. The hooks use a tgk_… collector key in gemini-cli.json. TrustGate authenticates as an application with OAuth or an ag_… API key. A tgk_… key does not authenticate MCP or model traffic, and gemini-cli.json does not accept TrustGate settings.

Deployment options

Before you start

Create the policy in Observe mode. Observe records decisions in Activity without enforcing them. Review the results, then switch the policy to Enforce. See Policies. Developers do not need NeuralTrust accounts for the hooks path.

Set up prompt and tool screening (TrustGuard)

The Gemini CLI extension registers hooks for BeforeAgent, BeforeTool and AfterTool. Before an action runs, each hook calls POST /v1/evaluate with the collector tgk_… key and answers in Gemini CLI’s hook contract: deny with a reason, ask, or allow.

Install the extension (pilot)

Gemini CLI asks for consent because the extension ships hooks; --consent accepts it in a script. On the first hook event the bootstrap downloads the pinned release binary into ~/.trustguard/bin and evaluates from the next event on. Then write the key config to ~/.trustguard/gemini-cli.json and chmod 600 it:
Start a new session, run /hooks panel to confirm the three TrustGuard hooks are listed, and send a test prompt.

Deploy under MDM (enterprise)

An MDM deployment consists of four components: Managed key config.
Gemini CLI system settings. System settings override user and workspace settings, so hooks declared here cannot be removed by the developer, and hooksConfig.enabled set here cannot be turned off:
Declare BeforeTool and AfterTool with the same command and "matcher": "*". The full file is docs/enterprise-settings.json in the extension repo. admin.secureModeEnabled: true in the same file removes YOLO mode and the always allow options, so an Ask verdict is always answered by a person. A developer can still point Gemini CLI at another system file with GEMINI_CLI_SYSTEM_SETTINGS_PATH; deploy a wrapper script that pins the variable if that matters in your environment.

Set up governed tool access (TrustGate MCP)

Gemini CLI treats TrustGate as a streamable HTTP MCP server: one httpUrl per MCP application, and the agent sees the tool set that application is routed to. Copy the endpoint from the application’s Connect tab:

OAuth applications

Add the server and nothing else:
On the first call TrustGate answers 401 with a WWW-Authenticate challenge. Gemini CLI follows it: it reads the protected-resource metadata, discovers the authorization server, registers itself as a public client and opens the sign-in in the browser. No client id is configured anywhere. Run /mcp auth TrustGate to sign in again; tokens live in ~/.gemini/mcp-oauth-tokens.json.

API-key applications

Or in settings.json:
The MCP plane also accepts the key as Authorization: Bearer ag_… or x-api-key. On a private (Hybrid) data plane add "X-AG-Gateway-Slug": "<gateway-slug>" to headers.

Enterprise

Two settings in the system settings file give the organization the same control a Claude organization connector gives Claude Code:
Which tools the application exposes is decided in the NeuralTrust console, on the application’s General tab. To limit MCP tool calls, attach the Per-Tool Rate Limiter policy.

Route model traffic through TrustGate

Gemini CLI can send its own model requests through an LLM application instead of straight to Google, so the same rate limits, budgets, guardrails and traces apply to the coding agent as to any other application. Gemini CLI speaks the Gemini API; TrustGate serves it at /{application-slug}/v1beta/models/{model}:generateContent and :streamGenerateContent, and routes it to whichever registry the application binds. This applies to the API-key authentication modes only. Login with Google talks to the Code Assist service and ignores the base URL.
  1. Create an LLM application, bind a Gemini registry and the models it may use, and issue an ag_… API key. Copy the LLM host from the Connect tab.
  2. Point Gemini CLI at the application:
    With the base URL set, Gemini CLI switches to its gateway authentication mode and sends the key as x-goog-api-key, which TrustGate accepts like X-AG-API-Key. Extra headers go in GEMINI_CLI_CUSTOM_HEADERS, which takes comma-separated Header: value pairs and reaches model requests only. On a private (Hybrid) data plane add X-AG-Gateway-Slug: <gateway-slug>, and to name the person behind the key add X-NeuralTrust-End-User: ana@example.com:
    The end-user value is attribution only: it lands on the trace and in Activity, and grants nothing.
  3. Start a new session and send a prompt. The request appears in TrustGate traces under the application.
An administrator can require this mode with "security": { "auth": { "enforcedType": "gateway" } } in the system settings file, alongside the environment variables deployed by MDM. Gemini CLI names Gemini models. On a route to a Gemini registry they pass through. On a cross-format route a bound registry must serve the model name Gemini CLI sends, so set GEMINI_MODEL to a model the registry offers. Limit. TrustGate does not serve :countTokens. Gemini CLI calls it only when a prompt carries an image or a file attachment; text and tool calls are counted locally. A prompt with an attachment fails through the gateway until that route exists.

Verify

Hooks.
  1. In Gemini CLI, run /hooks panel and confirm the three TrustGuard hooks are listed.
  2. Send a test prompt.
  3. Confirm the event in TrustGuard Activity with source.application = gemini-cli-plugin.
Smoke-test the binary (optional):
{} means allow. If Gemini CLI still never evaluates, the extension is disabled or the session predates the install. MCP.
  1. Run /mcp and confirm TrustGate is connected, then call a tool from a bound registry.
  2. Confirm the call in TrustGate Activity.
Model traffic. Run /about and confirm the auth method reads gateway, then send a prompt and open the trace in the console. A 401 means the key is wrong or revoked; a 404 means the slug or the path is wrong. The base URL must end with the application slug, no /v1beta.

Reference

Coverage

This table describes the TrustGuard extension, not the TrustGate connections. Ask. Gemini CLI honours an ask decision on BeforeTool: it opens its own confirmation prompt and shows the TrustGuard reason beside it. Gates with Ask, and DLP findings under the default transform_action: "ask", therefore reach the developer as a question. An ask on BeforeAgent does not stop the prompt: Gemini CLI has no confirmation dialog for that event, so the prompt is submitted with the message shown in the terminal and appended as context. Use a Block gate to stop a prompt. Limits. The extension does not support redaction and does not evaluate tool declarations. The AfterModel hook exists but fires per streamed chunk, so model responses are not evaluated. Route model traffic through TrustGate for controls on that side.

What is evaluated

For an MCP tool, tool.name is the name the server itself uses, taken from Gemini CLI’s mcp_context; the server name travels separately as attributes.mcp.server. Gate on the short tool name. The policy’s detectors decide the verdict.

Configuration

gemini-cli.json (TrustGuard hooks only). Keys: data_url, api_key, fail_mode, plus the optional settings below. It never holds TrustGate values. When the managed file includes api_key:
  • Locked: api_key, data_url, fail_mode. A user file and environment variables cannot replace them.
  • User-overridable settings may still be loaded from ~/.trustguard/gemini-cli.json: timeout_ms, transform_action, report_notice, events, consumer_id.
Without a managed file, all configuration is loaded from ~/.trustguard/gemini-cli.json (chmod 600). fail_mode: open plus an empty hook body {} means allow; that is also the response when evaluate returns allow. Binary discovery. The bootstrap checks PATH, then ~/.trustguard/bin under the stable name, then the versioned name it downloads to. If the download fails, the bootstrap fails open and warns on stderr. Remote sessions. Over SSH or WSL, the hooks run on the remote host. An MDM-deployed binary on the Mac does not cover that session. The config and binary must exist where the agent runs. MCP auth. The CLI accepts OAuth2 or an ag_… application key in headers (the plane also takes it as Authorization: Bearer ag_… or x-api-key). Which IdP backs the OAuth login is configured on the application. See Authentication. Authenticating to TrustGate is separate from authenticating to the upstream servers; a registry using OAuth (forwarded) returns a connect link on the first call for a user without a stored credential.

Attributes

The extension stamps source.application = gemini-cli-plugin and, when Gemini CLI is signed in with Google, user.email from its account cache. consumer_id is sent only when set in config or through TRUSTGUARD_CONSUMER_ID. To target the extension, create a gate with source.application eq gemini-cli-plugin, then choose Ask or Block as appropriate for the event. Gates run before detectors. In Observe mode, Block is recorded but not enforced. Test the condition on the policy Test tab with Extra parameter Source application set to gemini-cli-plugin.

Troubleshooting