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

fcn06 — Mon, 10 Aug 2026 15:44:10 +0000

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.

The idea

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.

Why I think this matters

Imagine an agent with a tool like:

stripe.refund(  
    payment_id="...",  
    amount=50000  
)

There are several possible policies you might want:

Reading a customer record → automatically allowed
Refunding €5 → automatically allowed
Refunding €500 → requires human approval
Refunding €50,000 → always denied
Calling a tool with unexpected parameters → denied

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.

What an integration looks like

The Python SDK lets you guard a tool using a decorator:

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.

Execution grants

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:

structured ProposedAction objects
deterministic canonical JSON
SHA-256 input hashing
Ed25519 signatures
short-lived grants
single-use jti nonces
grants bound to the exact tool and parameter set

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.

Human-in-the-loop without putting humans everywhere

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.

Quickstart

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.

What Trust Gateway is — and isn't

Trust Gateway isn't intended to make an LLM itself trustworthy.

It also isn't a replacement for:

sandboxing
IAM
secret management
network isolation
application-level authorization

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.

Where I'd love feedback

The project is still evolving, and I’m especially interested in feedback from people building:

AI agents with real side effects
MCP/tool servers
internal developer platforms
financial or support automation
agentic DevOps workflows
security infrastructure for autonomous systems

I’d particularly love opinions on the protocol design and threat model.

GitHub:

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

DEV Community: fcn06