How Trinity Keeps Agents in Bounds

Trinity's approach to guardrails, for operators, security reviewers and buyers. The short version: Trinity bounds agents by what they hold, not what they're told.

The first half of this page is the approach: the bet, the principles behind it, and what we deliberately don't do. The second half, Where it stands, says what ships in the current release, what is coming in the next one, and what is planned. Read the principles as the direction and the table as the facts.

The Bet

Companies don't hold back real work from agents because the agents lack capability. They hold it back because they can't bound them. The usual answers don't scale:

a prompt that says “please don't”

a human approving every step

a rigid workflow that throws away the agent's judgment

We think delegation becomes routine when it is bounded the way a job is.

The Vision

Give an agent a job the way you'd give a person one: a desk, the keys that job needs, someone who signs off on what matters, and a record of what they did. It earns more as it proves itself.

Five Principles

Keys, not rules.

An agent can do only what its credentials allow. A payment belongs to the one agent that holds the payment key, and every other agent has to ask it. A rule can be talked around. A missing key can't.

Limits live outside the agent.

Inside its own workspace an agent is a power user: it installs packages and runs code. The in-container guardrail hooks catch accidents. The boundary that holds sits in the platform: the credentials the agent was granted, the platform calls its key may make, and the settings only a person can change. Prompts shape behaviour; they never set bounds.

Sign-off before the work, never during.

You mark an action on an agent as “needs a yes from <role>”. The request goes to the person in that role before the agent starts. Nothing pauses halfway and resumes on stale state. The asking agent never approves its own request, and silence is never consent.

Trust is earned per kind of work.

A new agent starts on a short leash. A kind of task graduates from “ask first” to “just do it” on evidence, and drops back after a bad call. Earned trust changes when an agent acts, never what it may touch. Only a person removes a gate.

Everything leaves a receipt.

Grants, refusals and approvals are recorded in a tamper-evident audit log, along with which key acted. You can always answer who allowed this, who did it, and how to stop it.

What It Feels Like

This is where the principles lead. Some of it ships today; the table below says which.

An operator opens one agent and sees what it can touch, what needs a yes, and what it did. One click stops it, revokes its credentials, or switches it to read-only.

An approver gets one card: “Pay Acme $4,200, requested by the ops agent.” She approves. The finance agent pays, and the ops agent is told.

An agentthat reaches for something it wasn't given is told plainly what is missing, and it asks.

What We Deliberately Don't Do

Sell prompt-based guardrails as safety.

Block individual functions inside an agent. It routes around them.

Turn agents back into scripts to make them safe.

Put a human on every step. That isn't delegation.

Where It Stands

Available now means shipped in the latest release (v0.9.5). Next release means built and merged, not yet released. Planned means not built. Features marked requires an entitlement are part of the Enterprise edition.

	Available now	Next release	Planned
Hold what an agent can reach	Each agent holds only the credentials injected into it (Credentials). Agent-to-agent permissions: an agent can call only the agents you allow (Agent Permissions). An agent's own API key can never pass an admin check, even when the agent's owner is an admin. Credential vault: an agent fetches a granted secret by name at run time instead of holding it in its `.env`, and grants can be revoked per agent (requires an entitlement).	Settings only a person can change: an agent's or the system's key is refused on autonomy, capabilities, capacity and the API-key setting, and creating API keys or changing a GitHub token needs a signed-in browser session. An agent's own key reaches only itself, the agents it may call and the agents it spawned — on the backend's own routes too, not only through MCP tools (What an agent key reaches). Credential files open only for the agent's owner or an admin; teammates the agent is shared with keep using the agent but cannot read its secrets (Agent Files).	Outbound network allow-lists per agent. Per-agent spend caps.
Sign-off a yes before the work	Agents raise approvals, questions and alerts in the operator queue; a person answers in the Operating Room, and Workspace users answer the asks addressed to them. Unanswered asks expire.	Gated skills: mark a skill on an agent as needing a yes from its primary contact (or an approver role, requires an entitlement). A request that names it is held before the agent sees it, runs exactly once on approval, and an agent or person who asked is told how the run ended. On Claude Code agents, a second check inside the agent stops it loading the skill outside an approved run (Gated-skill approvals). Agents raise asks with the `ask_operator` tool, and an expired ask ends as not approved; an expired approval for an action the agent holds is marked outcome unknown. Only a person can answer, cancel or dismiss an ask: agent and system keys are refused, so no agent approves its own request. Asks addressed to a role instead of a name: the agent's primary owner or the operators in every edition; the approver and viewer roles requires an entitlement. A Workspace Inbox that collects the asks waiting on you, in every edition. An ask can carry the exact action it proposes, frozen with the ask.	Approvals bound to the exact effect (amount, payee) and enforced by the platform.
Trust more autonomy as it proves itself	A per-agent autonomy switch that a person turns on or off for scheduled work. It is manual, and every change is audited.	Admin-granted permissions: an admin grants a named agent the right to change skills, other agents' schedules, instructions or other agents, each a toggle on the agent's Settings tab. Without one the agent is refused by name and told how to ask (Permissions to Change Itself).	Earned trust per kind of work: graduating from “ask first” to “just do it” on evidence, and dropping back after a bad call.
See & stop a receipt, and an off switch	An append-only audit trail of administrative actions (grants and revocations, key changes, logins, credential changes, autonomy changes, emergency stops), with the MCP key that acted. An optional SHA-256 hash chain proves it hasn't been tampered with; the audit dashboard requires an entitlement, the API does not. Per-agent execution history. Stop one agent, or stop the fleet with the emergency stop. Switch an agent to read-only.	—	Refusals recorded in the audit trail alongside grants and approvals. One-click credential revocation for an agent's injected credentials. One control page per agent: what it can touch, what needs a yes, and what it did.

Coverage by Runtime

Trinity runs agents on three runtimes. Everything in the Hold and See & stop rows sits in the platform, so it applies to all three: an agent can use only the credentials and platform calls it was given, whichever runtime it runs on. The in-container controls differ:

In-container control	Claude Code	OpenAI Codex	Gemini CLI
Guardrail hooks (Bash deny-list, credential-file protection, leak scan)	Yes	No	No
Read-only mode	Yes, through a hook	Yes, through Codex's own read-only sandbox	No
Credential redaction of output	Yes, inside the container	Yes, inside the container	No; only the platform's pattern-based scrub when results are stored
Turn limit	Yes	No; the execution timeout bounds the run	No; the execution timeout bounds the run
Per-agent disallowed tools	Yes	No	No
Gated-skill check inside the agent (a request that names a gated skill is held by the platform on every runtime)	Yes	No	No

Guardrails are strongest on Claude Code. On Codex and Gemini CLI, rely on the platform boundary: what the agent holds, and the timeout.

Honest Limits

The in-container hooks catch accidents, not a determined agent. The agent user has passwordless sudo in its own container, so it could rewrite or get around them. That is why they are defence in depth, and why the boundary we rely on is outside the container.

Agents can reach the open internet today. There is no outbound allow-list yet.

A raw credential plus a shell reaches past the skills.An agent that holds a raw credential and a shell can act outside its skills. That is why “one key, one agent” is the boundary we rely on: give the payment key to the one agent that pays, and have every other agent ask it.