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
ProposedActionobjects - deterministic canonical JSON
- SHA-256 input hashing
- Ed25519 signatures
- short-lived grants
- single-use
jtinonces - 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
Top comments (0)