Stop Giving AI Agents Your API Keys: Introducing Trust Gateway (WIP)

A developer has introduced Trust Gateway, a work-in-progress security tool that decouples AI agents from the API keys they use to perform actions. The gateway evaluates proposed actions against policy and issues short-lived, cryptographically signed execution grants that executors independently verify, ensuring agents can propose but not directly execute sensitive operations.

AI agents are getting increasingly capable at calling tools: issuing refunds, updating tickets, sending emails, modifying infrastructure, querying databases, and triggering deployment pipelines. But there’s a security problem I kept coming back to: Why should the agent itself possess the credentials needed to perform those actions? If an agent has a Stripe key, GitHub token, cloud credential, or database password, then the security boundary is effectively inside the agent runtime. I wanted to see if there was a cleaner way to decouple intent from execution, so I started building a small side project called Trust Gateway . It’s very much a work in progress, and I’m sharing it early to get feedback from the community on the core design, hear how others are approaching this, and learn where it can be improved. Trust Gateway separates proposing an action from having authority to execute it . The model is simple: Agents propose. Gateway decides. Executors verify. Instead of giving an AI agent a downstream API key, the agent submits a structured ProposedAction to the gateway. The gateway evaluates that action against policy. If it is allowed, the gateway issues a short-lived, cryptographically signed ExecutionGrant bound to the exact tool and parameters that were approved. The gateway dispatches the granted action to the appropriate executor. Before any side effect, the executor independently verifies the grant's signature, expiry, audience, tool binding, argument hash, and single-use nonce. ┌────────────┐ ProposedAction ┌───────────────┐ │ AI Agent │ ─────────────────────────▶ │ Trust Gateway │ └────────────┘ └───────┬───────┘ │ No downstream credentials │ GrantedAction │ + ExecutionGrant ▼ ┌───────────────┐ │ Executor │ │ owns API key │ └───────┬───────┘ │ ▼ API The important part is that the executor does not trust the agent when it says: “This action was approved.” It verifies the authorization itself. Imagine an agent with a tool like: stripe.refund payment id="...", amount=50000 There are several possible policies you might want: But even if you implement those policies inside your agent framework, the agent may still hold the credential that bypasses them. Trust Gateway moves that authorization boundary outside the agent. The agent can ask. It cannot simply decide. The Python SDK lets you guard a tool using a decorator: python from trust gateway.client import TrustGatewayClient, guard tool client = TrustGatewayClient.dev mode gateway url="http://localhost:3060" @guard tool client, "stripe refund" def process refund amount: int, order id: str : return { "status": "refunded", "amount": amount } Now when an agent attempts: process refund amount=500, order id="ord 123" the function is not automatically executed. Trust Gateway first evaluates the proposed action. A policy can return something like: require approval and no execution grant is issued until the required approval exists. I wanted authorization to be independently verifiable, rather than just another HTTP response saying "approved": true . So Trust Gateway defines an Execution Authorization Protocol with: ProposedAction objects jti nonces That means an authorization for: { "tool": "stripe refund", "amount": 500 } cannot simply be reused to execute: { "tool": "stripe refund", "amount": 50000 } The parameters are part of what is authorized. I also wanted HITL to be a policy decision rather than the architecture itself. Not every tool call should trigger a Slack message asking someone to click Approve. For example: search docs → allow read customer → allow send email → require approval stripe refund < $20 → allow stripe refund = $20 → require approval delete database → deny The gateway can distinguish between routine actions and high-impact mutations. You can run it locally with Docker: git clone https://github.com/fcn06/trust gateway.git cd trust gateway docker compose -f deploy/docker-compose.yml up -d Then install the Python SDK: pip install -e sdks/python There’s also a standalone Docker demo if you don’t want to install Rust. Trust Gateway isn't intended to make an LLM itself trustworthy. It also isn't a replacement for: Instead, it addresses a narrower problem: How do we let an autonomous or semi-autonomous agent request privileged actions without giving that agent unrestricted possession of the authority required to perform them? That is the security boundary I'm exploring. The project is still evolving, and I’m especially interested in feedback from people building: I’d particularly love opinions on the protocol design and threat model. GitHub: https://github.com/fcn06/trust gateway https://github.com/fcn06/trust gateway If you're building agents that can do more than just generate text, I'd be curious: Where do you currently put the authorization boundary between the model and the systems it can modify? ai mcp opensource python