Trust tiers
A trust tier answers one question: how much do you trust whoever wrote this agent’s configuration? It is a statement about provenance, and it sets a ceiling on capability that the configuration itself cannot raise.
There are two tiers, trusted and untrusted, declared on a
plugin and inherited by every agent it defines. An agent
created directly in the platform declares its own.
Why a ceiling instead of a checklist
Section titled “Why a ceiling instead of a checklist”An agent’s tools list is authored by the same person who authored its
system prompt. If that list were the whole story, capability would be
self-granted: an agent could ask for anything and get it, and reviewing an
agent would mean reading its prose carefully and hoping.
The tier breaks that loop. Capability is the intersection of what the configuration asks for and what the tier permits. A configuration can narrow itself below its tier; it can never climb above it. Reviewing an agent’s blast radius therefore means reading one field, not auditing a prompt.
Markdown is never a security boundary. A system prompt saying “you may only do X”, a skill saying “this script is safe” — those are instructions to a model. The tier is enforced before the model is ever asked.
What each tier permits
Section titled “What each tier permits”untrusted agents may use retrieval-class tools — today, search.
This is the tier every tenant-authored agent gets.
Search is available to untrusted agents deliberately, not by oversight. Its safety does not come from the tier: it comes from the tenant filter and the per-agent collection ceiling, both applied server-side on every query regardless of who is calling. Withholding it from untrusted agents would have bought nothing real while making it impossible for a tenant to build a working knowledge agent for itself.
trusted agents may use any tool in the shared registry, plus tools
from external tool servers that an operator has registered and reviewed.
An operator opts an external server into untrusted use explicitly; until
they do, its tools are denied to untrusted agents. The default is denial.
Anything the platform does not recognise gets the restrictive answer. An
agent that reaches the runtime with no tier at all is treated as
untrusted — the failure mode of a missing field is less capability, not
more.
What tiers do not change
Section titled “What tiers do not change”Code execution is not tier-gated, because it is not tier-able. An agent that runs a script does so in an isolated sandbox, and that sandbox is identical for every tier. There is no tier that gets a weaker one.
Writes to the skill store are denied to every agent, at every tier. Agents read skills; only the authoring paths write them.
So the tier governs which tools an agent may reach for. It does not govern how safely those tools execute, because that is uniform.
A denied tool is announced, not hidden
Section titled “A denied tool is announced, not hidden”When the tier strips a tool an agent’s configuration asked for, the agent is told: this tool was configured for you, it exceeds your tier, and you must not substitute something else and pretend it is equivalent.
That sentence exists because of a real failure. A silently missing tool produced agents that reached for whatever remained — a generic file search in place of a real one — and answered with confidence, with no failed tool call and no error anywhere to show what had happened. The user saw a vaguely unhelpful answer; the trace looked clean.
Now the agent says plainly that it cannot do the thing. An honest refusal is diagnosable in a way that a confident wrong answer is not. If you see one, check the agent’s tier against the tools its configuration requests.
The same applies to a tool that no longer resolves at all — an external server removed, or a tool withdrawn from it. The agent is told that separately and specifically, because the fix is different: one is a permission decision, the other is a registry change.
Who can assign which tier
Section titled “Who can assign which tier”Tenant roles can assign untrusted. trusted is reserved for platform
operators.
Nobody can grant above their own ceiling. Importing a plugin that declares a tier you cannot assign is refused; so is creating an agent that way, and so is minting an API key with a role above your own. The escalation gate is the same in every path, checked server-side against your credential’s actual role.
Which means: if you hold a tenant key and need a capability beyond retrieval, that is a conversation with an operator, not a configuration change you can make. There is no request shape that works around it.