Show HN: Focus on approving agent actions and managing team MCP access

Open-source control boundary

Proposed action in. Typed decision out. Side effect stays on your side.

Runtime control for production AI agents

Stop AI agentsbefore they send, spend, or execute.

TrustLoopGuard checks a proposed output or action before it becomes a real side effect. Your runtime gets permit, deny, transform, require approval, or defer—plus a receipt showing why.

Built by a former engineer at a company backed bya16z

Try the live refund demoGo to the appSee the control flow

No card. No signup. Runs against the real authorization path.Inspect the source ↗

01

Agent proposes

issue_refund

principalrefund-bot

amount$75.00 USD

Proposed

TrustLoopGuard checks

Authoritypass

Order evidencepass

Refund policyapproval

EffectREQUIREAPPROVAL

Typed decision returned

effect: require_approval

Execution not startedReceipt reserved

01Apache-2.0Inspect every decision path↗02Self-hostableRust runtime in your infrastructure↗03TypeScript · Python · RustOne generated decision contract↗04Decision + receiptAuthorization before, proof after↗

The authorization journey

One proposed action. One controlled path to the real world.

Follow the blue route. The agent can propose an action, but it cannot cross the control boundary until TrustLoopGuard returns an actionable decision.

01Agent proposes

The action has not happened yet.

Your runtime submits the intended action and its context before any side effect reaches a user, tool, or payment rail.

actionissue_refund

amount$75.00 USD

statusproposed

02Control boundary

TrustLoopGuard holds the action at the gate.

Checks run against durable runtime context—not just another instruction in the prompt.

✓Grant & authority

✓Trusted evidence

✓Financial policy

✓Spend window

03Decision point

Every route is explicit.

The response tells the caller exactly what may happen next—and why.

require_approvalWait for approval

denyStop before execution

04Authorized only

Your runtime performs the action.

Approval-required actions wait. Denied actions stop. Only a permitted action continues through the gate to your existing execution code.

executeAction(action.id)

05Evidence after action

The loop closes with proof.

A decision receipt records the authorization before execution. An execution receipt records what actually happened after it.

Decision receipt→Execution receipt

Every domain: the same boundary returns permit, deny, transform, require_approval, or defer.

The evidence

Every authorization leaves a record.

See what was requested, what passed, why approval is needed, and whether execution started.

FinancialActionrefund · issue_refund

principal_idrefund-bot

amount$75.00 USD

authorization_statuspending_approval

execution_statusnot_started

effectrequire_approval

authoritypassed

riskamount_above_threshold

approvalrequired

executionnot_started

01

Authority is checked before policy

Grant scope proves what this principal may do for this specific action.

02

Execution is a separate state

An approval-required action cannot execute until a matching grant and current policy produce permit.

03

Proof exists on both sides

A decision receipt explains authorization before execution; an execution receipt records what moved.

For developers

Install one package. Decorate one agent.

Keep your current model provider and reply call sites. TrustLoopGuard adds one SDK decorator at the final output boundary.

01

Published SDKInstall one package and decorate your agent

Keep calling the same agent.

The SDK decorates your agent once, checks every final reply through the Rust runtime, and preserves the interface your application already calls.

Installnpm install @trustloopguard/sdk

BoundaryYour existing reply function

EndpointPOST /v1/events

Integration example

import { guardAgent } from '@trustloopguard/sdk';

const agent = guardAgent(createAgent(), { agentId: 'support-agent', });

return await agent.reply(customerMessage);

Decorated agent → safe replyDecision returned

Why this exists

Built after watching agents fail in production.

“At an AI voice-testing company, I watched production find the failures demos missed. I built TrustLoopGuard around that lesson: assume the edge case is coming, put policy before action, and leave evidence behind.”

DDucFounder, TrustLoopGuard

Trust is evidenceReview the repository ↗

01

Policy before action

The check runs on the proposed output or action—not after the side effect has already happened.

02

A reason, not a mystery

Every decision returns the effect, the policies that fired, and a human-readable reason.

03

Inspectable by default

The runtime is open source. The wire contract, policy engine, and SDK behavior are available to review.

Where it fits

Start with an action you can recognize.

Choose a real action and follow it through the same control loop: capture the proposal, evaluate policy outside the prompt, return an explicit decision, then let the existing runtime act.

Bash proposes a destructive action

rm -rf /

Toolclaude-code / Bash

Workspace/workspace/project

Tool policy matches shell facts

Riskfilesystem_recursive_delete

Targetroot

Actiondeny

Policy on

Return an explicit effect

rm -rf /DeniedSystem target blocked

rm -rf ./buildApproval requiredExact action waits

The executor stays paused

Denied commands never run. An approved command receives one action-bound execution lease.

Execution boundaryAnalysis parses the command as structured input and never invokes the shell.

View all six use cases →

Start with a real failure path

Bring the agent action you are least comfortable shipping.

We will map the event, the policy boundary, and the decision your runtime needs before that action reaches a user or tool.

Talk through a failure pathReview the sourceRead the docs ↗