I built mcp-gate , a small Go reverse proxy for a problem I keep coming back to with LLM agents: How much authority should we actually give a model when it calls a tool? Repo: ananthaprakashb/mcp-gate on GitHub A typical agent integration eventually ends up holding something powerful: an API key, service credential, OAuth token, or access to an MCP/tool server that can perform multiple operations. Even when the model is supposed to perform one very specific action, the credential it indirectly controls may authorize far more. I wanted the authorization boundary to look more like this: The model never receives the upstream API credential. Instead, the trusted orchestrator exchanges its gate credential for an ephemeral capability token authorizing one specific operation. For example: { "route": "tickets", "method": "POST", "path": "/v1/tickets", "ttl_seconds"...
1. The Membership Card (Identification) Imagine your son, Sai Krishna, wants to enter a high-tech "Gamers Clubhouse" in San Ramon. Identification is him walking up to the door and saying, "I’m Sai Krishna." * In the tech world, this is the Username or Email . It’s public info. Anyone can say they are him. 2. The Secret Handshake (Authentication) The bouncer at the door doesn't just take his word for it. He says, "If you’re really Sai Krishna, show me the secret handshake." Authentication is the act of proving that identity. It’s the Password . Only the real Sai Krishna and the Clubhouse bouncer know what that handshake looks like. 3. How the "Clubhouse" (Server) Remembers In the old days of the internet, every time you wanted to go to a different room in the clubhouse (like the Snack Bar or the Game Room), the bouncer would stop you and ask for the handshake again. That’s annoying! To fix this, the bouncer gives you a Hand Stamp once y...
Transaction Boundary Failures — and the infrastructure we need before agents are trusted with real-world actions A customer asks an AI agent to upgrade an account. The workflow looks harmless. First, charge the card. Then update the subscription ledger. Then provision the new entitlement. The agent calls the payment API. The payment provider charges $500. And then the connection times out. What happened? That sounds like a simple question. It isn't. The agent knows that it did not receive a successful response. It does not know that the charge failed. Those are two very different things. The payment may have failed before reaching the provider. The payment may still be processing. Or the payment may have completed perfectly and only the response was lost somewhere between the provider and the agent. Now imagine what happens when we put an LLM in the middle of this uncertainty. “The payment request timed out. I still need to complete the upgrade. Let me try again.” That sentence...
Comments
Post a Comment