Show HN: SatGate – An economic firewall for AI agent traffic

Show HN: SatGate – An economic firewall for AI agent traffic(github.com)

1 points by satgate 96 days ago | 2 comments

SatGate is an API gateway that enforces budgets on AI agent traffic. Open source (Go, Apache 2.0).

The problem: AI agents make API calls that cost money — LLM inference, tool calls, third-party services. Most setups have no hard spending limits. An agent loop or prompt injection can burn through hundreds of dollars before anyone notices. Rate limiting doesn't help because it doesn't understand cost.

SatGate sits in front of your agent's outbound calls and enforces economic policy:

• Hard budget caps — per-agent, per-tool, per-time-window. Not alerts, actual enforcement. The call gets rejected.

• Per-tool cost attribution — MCP-aware. Knows which tool in a chain caused what spend. Not just "1,000 requests" but "Agent X spent $47 on search_database and $12 on send_email."

• Macaroon capability tokens — cryptographic credentials with built-in caveats (budget, time window, allowed tools). Agents can sub-delegate scoped tokens without calling home. Not API keys.

• L402 Lightning micropayments — agents can pay for API access per-call using HTTP 402. Sub-cent pricing that doesn't work on card rails.

It's not a routing gateway. LiteLLM and Bifrost solve which provider handles a request. SatGate decides whether the request should happen at all given your budget constraints. They're complementary — SatGate sits in front of a routing gateway.

What it doesn't do: It doesn't optimize costs, negotiate rates, or pick cheaper providers. It's a policy enforcement layer, not an optimizer.

Single binary, 60-second quickstart, <50ms overhead.

GitHub: https://github.com/SatGate-io/satgate Blog: https://satgate.io/blog/why-routing-isnt-governance

satgate 95 days ago |

Timely coincidence — Lightning Labs just open-sourced agent payment tools today (lnget, an L402-aware curl for agents). They're solving the client side: teaching agents to pay Lightning invoices automatically. SatGate is the server side: the policy enforcement and budget layer that sits in front of your APIs. If you're running an API that agents consume, SatGate lets you go from "observe what's hitting you" to "enforce per-agent budgets" to "charge per-request via L402" — without changing your backend. An agent running lnget hits your SatGate endpoint, gets a 402, pays the invoice, and proceeds. No signup, no API keys. The two projects are complementary. They're building the roads. We're building the toll infrastructure.

satgate 96 days ago |

I've spent 27 years in enterprise cybersecurity — firewalls, IDS, access control, the usual stack. When I started running AI agents against production APIs last year, I had a familiar feeling: this looks exactly like the early internet before we figured out network security.

Agents make outbound calls with real dollar costs attached. The tooling to control that spend mostly comes down to "set an alert and hope someone's watching." I've seen agents in tight loops burn through $400 in minutes on tool calls nobody intended. One prompt injection away from draining a prepaid API balance.

The security stack has authentication, authorization, rate limiting — but nothing that understands cost as a first-class constraint. You can't express "this agent can spend $50/day across these tools" in a WAF rule.

So I built SatGate. It's a policy enforcement point for economic decisions. It reads cost metadata from MCP tool manifests, tracks cumulative spend per agent, and hard-blocks calls that would exceed budget.

We use macaroon tokens instead of API keys because they support attenuation — an agent can delegate a sub-token with tighter constraints without any server round-trip. A parent agent gives a child agent a token that says "you can spend $10 on search_database in the next hour." The child can't escalate.

The L402/Lightning piece came later — it turns out micropayments are a natural fit for agent-to-API commerce where you want per-call settlement without monthly invoices or API key management.

I looked at the existing landscape: Bifrost has soft budgets (alerts, no enforcement). Zuplo and Kong are solid API gateways but have no concept of economic controls. Nothing combined hard limits + per-tool costs + payments in one layer.

It's open source because I think this needs to be infrastructure, not a product. <50ms overhead, single Go binary, runs anywhere.

Happy to answer questions about the architecture, the macaroon auth model, or the problem space.