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:
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
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