{"slug": "stop-giving-ai-agents-your-api-keys-introducing-trust-gateway-wip", "title": "Stop Giving AI Agents Your API Keys: Introducing Trust Gateway (WIP)", "summary": "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.", "body_md": "AI agents are getting increasingly capable at calling tools: issuing refunds, updating tickets, sending emails, modifying infrastructure, querying databases, and triggering deployment pipelines.\n\nBut there’s a security problem I kept coming back to:\n\n**Why should the agent itself possess the credentials needed to perform those actions?**\n\nIf an agent has a Stripe key, GitHub token, cloud credential, or database password, then the security boundary is effectively inside the agent runtime.\n\nI 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**.\n\nIt’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.\n\nTrust Gateway separates **proposing an action** from **having authority to execute it**.\n\nThe model is simple:\n\nAgents propose. Gateway decides. Executors verify.\n\nInstead of giving an AI agent a downstream API key, the agent submits a structured `ProposedAction`\n\nto the gateway.\n\nThe gateway evaluates that action against policy.\n\nIf it is allowed, the gateway issues a short-lived, cryptographically signed `ExecutionGrant`\n\nbound to the exact tool and parameters that were approved.\n\nThe 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.\n\n```\n┌────────────┐       ProposedAction       ┌───────────────┐\n│  AI Agent  │ ─────────────────────────▶ │ Trust Gateway │\n└────────────┘                            └───────┬───────┘\n                                                │\n      No downstream credentials                 │ GrantedAction\n                                                │ + ExecutionGrant\n                                                ▼\n                                        ┌───────────────┐\n                                        │   Executor    │\n                                        │ owns API key  │\n                                        └───────┬───────┘\n                                                │\n                                                ▼\n                                               API\n```\n\nThe important part is that the executor does **not** trust the agent when it says:\n\n“This action was approved.”\n\nIt verifies the authorization itself.\n\nImagine an agent with a tool like:\n\n```\nstripe.refund(  \n    payment_id=\"...\",  \n    amount=50000  \n)\n```\n\nThere are several possible policies you might want:\n\nBut even if you implement those policies inside your agent framework, the agent may still hold the credential that bypasses them.\n\nTrust Gateway moves that authorization boundary outside the agent.\n\nThe agent can ask.\n\nIt cannot simply decide.\n\nThe Python SDK lets you guard a tool using a decorator:\n\n``` python\nfrom trust_gateway.client import TrustGatewayClient, guard_tool\n\nclient = TrustGatewayClient.dev_mode(  \n    gateway_url=\"http://localhost:3060\"\n)\n\n@guard_tool(client, \"stripe_refund\")  \ndef process_refund(amount: int, order_id: str):  \n    return {  \n        \"status\": \"refunded\",  \n        \"amount\": amount  \n    }\n```\n\nNow when an agent attempts:\n\n```\nprocess_refund(  \n    amount=500,  \n    order_id=\"ord_123\"  \n)\n```\n\nthe function is not automatically executed.\n\nTrust Gateway first evaluates the proposed action.\n\nA policy can return something like:\n\nrequire_approval\n\nand no execution grant is issued until the required approval exists.\n\nI wanted authorization to be independently verifiable, rather than just another HTTP response saying `\"approved\": true`\n\n.\n\nSo Trust Gateway defines an **Execution Authorization Protocol** with:\n\n`ProposedAction`\n\nobjects\n`jti`\n\nnonces\nThat means an authorization for:\n\n```\n{  \n  \"tool\": \"stripe_refund\",  \n  \"amount\": 500  \n}\n```\n\ncannot simply be reused to execute:\n\n```\n{  \n  \"tool\": \"stripe_refund\",  \n  \"amount\": 50000  \n}\n```\n\nThe parameters are part of what is authorized.\n\nI also wanted HITL to be a policy decision rather than the architecture itself.\n\nNot every tool call should trigger a Slack message asking someone to click Approve.\n\nFor example:\n\nsearch_docs → allow\n\nread_customer → allow\n\nsend_email → require approval\n\nstripe_refund < $20 → allow\n\nstripe_refund >= $20 → require approval\n\ndelete_database → deny\n\nThe gateway can distinguish between routine actions and high-impact mutations.\n\nYou can run it locally with Docker:\n\n```\ngit clone https://github.com/fcn06/trust_gateway.git\ncd trust_gateway\ndocker compose -f deploy/docker-compose.yml up -d\n```\n\nThen install the Python SDK:\n\n```\npip install -e sdks/python\n```\n\nThere’s also a standalone Docker demo if you don’t want to install Rust.\n\nTrust Gateway isn't intended to make an LLM itself trustworthy.\n\nIt also isn't a replacement for:\n\nInstead, it addresses a narrower problem:\n\n**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?**\n\nThat is the security boundary I'm exploring.\n\nThe project is still evolving, and I’m especially interested in feedback from people building:\n\nI’d particularly love opinions on the protocol design and threat model.\n\nGitHub:\n\n[https://github.com/fcn06/trust_gateway](https://github.com/fcn06/trust_gateway)\n\nIf you're building agents that can do more than just generate text, I'd be curious:\n\n**Where do you currently put the authorization boundary between the model and the systems it can modify?**\n\n#ai #mcp #opensource #python", "url": "https://wpnews.pro/news/stop-giving-ai-agents-your-api-keys-introducing-trust-gateway-wip", "canonical_source": "https://dev.to/fcn06/stop-giving-ai-agents-your-api-keys-introducing-trust-gateway-wip-1c8f", "published_at": "2026-08-10 15:44:10+00:00", "updated_at": "2026-08-10 15:49:19.456785+00:00", "lang": "en", "topics": ["ai-agents", "ai-safety", "ai-infrastructure", "developer-tools"], "entities": ["Trust Gateway"], "alternates": {"html": "https://wpnews.pro/news/stop-giving-ai-agents-your-api-keys-introducing-trust-gateway-wip", "markdown": "https://wpnews.pro/news/stop-giving-ai-agents-your-api-keys-introducing-trust-gateway-wip.md", "text": "https://wpnews.pro/news/stop-giving-ai-agents-your-api-keys-introducing-trust-gateway-wip.txt", "jsonld": "https://wpnews.pro/news/stop-giving-ai-agents-your-api-keys-introducing-trust-gateway-wip.jsonld"}}