Docs/Guides/Enterprise Deployment

Enterprise Deployment Guide: Ensuring Complete Agent Coverage

How to guarantee every agent request flows through SatGate — MCP, HTTP, and network-level enforcement.

The Problem

In enterprise environments, AI agents have multiple ways to make API calls: through configured MCP tools, through built-in client tools (Cursor, Claude Desktop), or through direct HTTP. If SatGate only covers one path, agents can bypass governance by using another. This guide explains how to close every gap.

Three Layers of Enforcement

Complete coverage requires three complementary layers. Each one closes a different bypass path.

🎯
Layer 1: MCP Proxy

Tool-Level Governance

🛡️
Layer 2: HTTP Proxy

API-Level Governance

🔒
Layer 3: Network Policy

Guarantee

Layer 1: MCP Proxy — Tool-Level Governance

  • In Cloud mode, add your MCP server as an upstream — governance is automatic. In self-hosted mode, configure a route with MCP parsing enabled.
  • SatGate parses every JSON-RPC tools/call and attributes cost per tool automatically
  • No per-tool route configuration needed
  • Gives you: which tool was called, what parameters, projected cost, delegation chain
  • Supports all policy modes: Observe for visibility with no enforcement, Control for budget enforcement per tool call
  • Budget enforcement works at the per-tool granularity — each tool call is individually governed via ToolCosts

When to use

When agents are configured to use MCP tools and you want per-tool governance, cost attribution, and budget enforcement.

☁️ SatGate Cloud

  1. Open MCP → Upstreams in the dashboard and add your MCP server
  2. Set enforcement mode in MCP → Settings
  3. Connect your agent's MCP client to the SatGate MCP endpoint
  4. Configure per-tool costs in MCP → Cost Profiles

No route configuration needed — governance is automatic.

🔧 Self-Hosted Gateway

  1. Add your MCP server as an upstream in gateway.yaml
  2. Create a route with mcp.enabled: true
  3. Set policy to Observe or Control
  4. Configure toolCosts for per-tool cost attribution

Route parses JSON-RPC bodies for tool-level governance.

Layer 2: HTTP Proxy — API-Level Governance

  • One route per upstream API (e.g., /openai/, /anthropic/, /internal-api/)
  • Each route gets its own policy and cost-per-request configuration
  • Route transforms can inject API keys via headers — agents never see the real credentials
  • Budget enforcement happens BEFORE the upstream call is made
  • Governs agents that call APIs directly — built-in tools, curl, SDKs, or any HTTP client
  • Independent from the MCP proxy — covers a different traffic path (HTTP requests vs JSON-RPC tool calls)

When to use

Always. This governs direct API calls — REST, HTTP, any non-MCP traffic. Agents using built-in tools, SDKs, or direct HTTP clients are covered here, independent of MCP proxy.

Setup

  1. Add each API provider as an upstream (OpenAI, Anthropic, your internal APIs)
  2. Create a route per upstream with appropriate path prefix
  3. Configure Strip Prefix in Advanced settings
  4. Set policy and budget per route
  5. Point agent traffic to SatGate's address instead of the API directly

Layer 3: Network Policy — Guarantee

  • Block direct outbound access from agent hosts to LLM provider IPs
  • Only the SatGate gateway gets outbound access to upstream APIs
  • Same pattern as a corporate web proxy or egress firewall
  • Agents can attempt ANY path (MCP, built-in, direct HTTP) — network policy routes all traffic through SatGate. Without a valid token, requests are rejected (401)

When to use

Production enterprise deployments where bypass prevention is a requirement.

Implementation options

Cloud / K8s

Network policies that restrict pod egress to SatGate's cluster IP only.

Corporate Network

Firewall rules blocking direct access to api.openai.com, api.anthropic.com, etc. from agent subnets.

Key Principle

The goal is simple: agents cannot reach LLM providers without going through SatGate. Once traffic arrives at SatGate, deny-by-default handles the rest — no valid token means no access, preventing ghost spend at the infrastructure level.

Coverage Matrix

ScenarioMCP ProxyHTTP ProxyNetwork PolicyCovered?
Agent uses SatGate MCP tools✅ Full governance + attributionN/AN/A✅ Per-tool governance + enforcement
Agent uses native tool, traffic through proxyN/A✅ Budget enforcedN/A✅ Enforced
Agent uses native tool, direct internet❌❌✅ Blocked / redirected✅ Guaranteed — blocked without token, governed with token
All three layers active✅ Tool-level governance✅ API-level governance✅ Guarantee✅ Complete coverage

Recommended Enterprise Configuration

1
Start with Layer 1 + Layer 2

MCP + HTTP proxy in Observe mode. Zero disruption.

2
Review Shadow Report

Understand agent traffic patterns before enforcing anything.

3
Enable Control mode

Activate budget enforcement. Agents exceeding budget get HTTP 402.

4
Add Layer 3 — network policy

Production hardening. Block direct outbound to LLM providers.

5
Monitor with Delegation Tree

Visualize the full delegation hierarchy. See every agent, every token, every budget.

Ensuring MCP Tool Priority

Even with SatGate MCP configured, AI coding assistants may choose built-in tools over SatGate tools. The model picks whichever tool seems most relevant — there's no protocol-level "force MCP" switch. These techniques ensure SatGate tools are used consistently.

Tier 1: Client Rules (Most Practical)

Each client supports project-level rules that steer tool selection toward SatGate MCP tools:

Cursor — .cursor/rules/satgate.mdc

--- description: SatGate MCP enforcement globs: "**/*" alwaysApply: true --- # SatGate Policy All external API calls MUST go through SatGate MCP tools. ## Required behavior: - Use SatGate MCP tools for ALL API requests (OpenAI, Anthropic, internal APIs) - NEVER use built-in web search, URL fetch, or direct HTTP tools for API calls - If a SatGate MCP tool exists for the action, always prefer it over built-in alternatives ## Why: All API traffic must be governed for cost attribution, budget enforcement, and audit compliance.

Claude Desktop / Claude Code — .claude/settings.json or system prompt

{ "systemPrompt": "All external API calls must go through SatGate MCP tools. Never use built-in tools for API requests. SatGate tools provide cost governance and audit compliance." }

Or in .claude/CLAUDE.md:

All API calls must use SatGate MCP tools. Do not use built-in HTTP, web search, or direct API tools.

Windsurf — .windsurfrules

All external API calls must use SatGate MCP tools. Do not use built-in alternatives for any API requests. SatGate provides cost governance and audit compliance.

⚠️ Note

These are prompt-level instructions — the model follows them ~95% of the time. For guaranteed enforcement, combine with Layer 3 (Network Policy).

Tier 2: Tool Naming Optimization

When SatGate MCP tool names and descriptions closely match the user's intent, models prefer them over built-in alternatives.

  • Use clear, action-oriented names: search_web, call_api, query_database
  • Write descriptions that match natural language: "Search the web for information" beats "Execute web search query via proxy"
  • If SatGate exposes a tool that overlaps with a built-in (e.g., both have web_search), make the SatGate description more specific and useful
  • Include "governed" or "audited" in descriptions — models learn these signal compliance requirements

Tier 3: Network Policy (Backstop)

DNS override and firewall rules from Layer 3 above catch the calls that slip through prompt-level steering. When an agent ignores client rules and uses a built-in tool to call an API directly, network policy redirects that traffic through SatGate anyway.

See the Layer 3: Network Policy section above for implementation options including DNS override, cloud network policies, and firewall rules.

💡 Best Practice

Use all three tiers together. Client rules handle 95% of cases. Tool naming improves selection. Network policy guarantees no bypass.

Preventing Ghost Spend

"Ghost spend" — API costs from agents bypassing governance — is a top enterprise concern. SatGate's deny-by-default architecture eliminates it without any additional features. Here's how the existing layers work together.

The Attack Scenario

A developer (or their agent) tries to skip SatGate MCP and call OpenAI/Anthropic directly — using a built-in tool, curl, or a custom HTTP client. Without governance, this spend is invisible and unbudgeted.

How SatGate Prevents It

# What happens when an agent tries to bypass SatGate:

Agent → direct call to api.openai.com

  ↓ (network policy intercepts)

Network Policy → routes to SatGate Gateway

  ↓ (check for macaroon token)

SatGate → valid token?

❌ No token

401 Rejected — ghost spend = $0

✅ Valid token

Policy enforced → budget checked → request proxied

The Three-Layer Defense

1
Client Rules (Prevention)

Steer agents to use SatGate MCP tools. 95% of bypass attempts never happen because the model follows the rules.

2
Network Policy (Redirection)

All LLM traffic routes through SatGate regardless of which tool made the call. The agent can't reach OpenAI/Anthropic without going through the gateway.

3
Deny-by-Default (Enforcement)

Every non-public route requires a valid macaroon token. No token = 401. No exceptions. The API key never reaches the upstream provider.

✅ Result

Zero ghost spend. The agent either uses SatGate (governed, budgeted, audited) or it doesn't reach the API at all.

💡 Key Insight

You don't need a new feature to prevent ghost spend. SatGate's existing deny-by-default architecture + standard network policy = complete prevention. This is infrastructure-level enforcement, not prompt-level hope.

Summary

MCP Proxy

= Tool-Level Governance

Per-tool costs, budgets, attribution

HTTP Proxy

= API-Level Governance

Per-route costs, direct API traffic

Network Policy

= Guarantee

No bypass possible

All three together = complete enterprise coverage

Related guides

Shadow Report (Observe) →Enforcement Modes (Control) →MCP Upstreams →Per-Agent Budgets →