Kimi K2.5 just shipped Agent Swarm — one prompt spawns up to 100 parallel sub-agents making 1,500+ tool calls. Manus (now Meta, $2B) runs agents async while you sleep. So: how do you budget-cap 100 parallel agents sharing one API key?
Rate limits won't help — they're per-key, not per-agent. Spending alerts won't help — by the time the email arrives, the swarm is done. Revoking the key kills all 100 agents, not just the one that's hallucinating against a paid API.
We built satgate-proxy to solve this with macaroon delegation trees. Macaroons are bearer tokens with cryptographically enforced caveats. The key property: any token can be attenuated (made more restrictive) without contacting the server. So an orchestrator with a 1,000-credit token can locally mint 100 child tokens capped at 10 credits each. Each sub-agent gets its own token. When agent #37 burns through its budget, it gets blocked — the proxy returns either HTTP 402 (server mode) or a JSON-RPC error (local mode) — and stops. The other 99 keep running.
No dashboard to watch. No human in the loop. The budget is enforced on every request.
Zero dependencies. Wraps any MCP tool server with hard budget caps locally. Every tool call deducts from the budget. When it hits zero, the proxy returns a clean JSON-RPC error and the agent stops. No account needed for local mode.
The npm package is the lightweight proxy. The full server (macaroon minting, delegation trees, L402/Fiat402 protocol support) is the Go codebase: https://github.com/SatGate-io/satgate
Both MIT licensed. We're building the economic constraint layer for agent systems. Happy to answer questions about the macaroon model, the protocol design, or how this fits into MCP.
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.
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.
Interesting execution but this highlights the exact infrastructure gap nobody's talking about: when agents operate autonomously at scale, every API call costs money. 10,000 founder agents making decisions, calling payment processors, hitting third-party APIs — who enforces the budget? Who audits the spend?
The "Real World Boundaries" they mention are really economic boundaries. And right now there's no standard way for an API to say "this request costs $0.003, do you authorize it?" to a machine caller the way we do with humans.
The plumbing for the agent economy is still missing. That's where the real opportunity is.
The hype is real but the infrastructure isn't there yet. I've spent 25+ years in enterprise security and the pattern is familiar — new capability ships fast, governance catches up slow.
The actual hard problem with agents isn't intelligence, it's economic. When you give an agent access to APIs, who's tracking what it spends? Who enforces a budget? Right now most teams find out their agent burned through $10K in API calls after the invoice hits.
Agents are useful. But until we solve identity, authorization, and cost control for machine-to-machine traffic the same way we solved it for human traffic, it's going to be the Wild West.
Rate limits won't help — they're per-key, not per-agent. Spending alerts won't help — by the time the email arrives, the swarm is done. Revoking the key kills all 100 agents, not just the one that's hallucinating against a paid API.
We built satgate-proxy to solve this with macaroon delegation trees. Macaroons are bearer tokens with cryptographically enforced caveats. The key property: any token can be attenuated (made more restrictive) without contacting the server. So an orchestrator with a 1,000-credit token can locally mint 100 child tokens capped at 10 credits each. Each sub-agent gets its own token. When agent #37 burns through its budget, it gets blocked — the proxy returns either HTTP 402 (server mode) or a JSON-RPC error (local mode) — and stops. The other 99 keep running.
No dashboard to watch. No human in the loop. The budget is enforced on every request.
Try it:
npx satgate-proxy --local --budget 5.00 --config satgate.yaml
Zero dependencies. Wraps any MCP tool server with hard budget caps locally. Every tool call deducts from the budget. When it hits zero, the proxy returns a clean JSON-RPC error and the agent stops. No account needed for local mode.
The npm package is the lightweight proxy. The full server (macaroon minting, delegation trees, L402/Fiat402 protocol support) is the Go codebase: https://github.com/SatGate-io/satgate
Both MIT licensed. We're building the economic constraint layer for agent systems. Happy to answer questions about the macaroon model, the protocol design, or how this fits into MCP.