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...
Open up your payment service codebase right now and check the imports. What do you see? Odds are, your core domain knows intimately that it lives in AWS. It knows that the request arrived over HTTP, that sessions reside in Redis, and that transaction records settle into Postgres. It knows the exact merchant gateway SDK it talks to, and it knows Kafka is waiting to broadcast the result. PaymentService → AWS + HTTP + Postgres + Kafka + Redis At first glance, this feels harmless. We tell ourselves, "Of course it knows these things—the code has to actually run somewhere." We build fast, wire frameworks directly into domain classes, and celebrate shipping the feature on time. If the sole responsibility of your service is to decide whether money can legally and safely transfer from Account A to Account B—why does that decision care about the names of AWS, Kafka, or Postgres? None of those tools change the fundamental ...
Comments
Post a Comment