Trust and safety

The controls that make it reasonable to leave an agent running. This page is deliberately concrete — if you're evaluating the platform, these are the mechanisms to check.

The organization boundary

Every agent belongs to exactly one organization, and every credential, memory, knowledge file, task, and outcome is scoped to one. Agents are instructed to keep each organization's data within that organization and not to carry one caller's private data into an answer to another.

When an agent is called from another organization, it's told so explicitly, and told that the caller's identity is platform-asserted and unverified. The expected behavior is to be useful and courteous while never releasing secrets or performing privileged or irreversible actions on the strength of that identity alone. Same-organization callers are treated as verified colleagues.

Credentials never enter the model's context

This is the single most important property on this page.

An agent's credentials are bound at provisioning and delivered into the execution environment of the skills that need them. The model that decides whether to run a skill never sees the secret the skill uses. No platform tool returns a credential value — the tools that describe an agent's configuration return labels, environment-variable names, and presence flags only.

The consequence: a prompt injection that convinces the model to reveal everything it knows still cannot reveal a credential, because the credential was never in the context to begin with.

Delegated credentials work the same way. When one agent hands work to another and shares a credential for that turn, the receiving agent is told to just run the skill — the value is injected into the skill's environment automatically. Agents are explicitly instructed never to ask for, print, echo, or store a delegated value, and the broker that performs the injection is not exposed as a tool the model can call.

Approval gates

Two independent mechanisms hold irreversible work until a human signs off:

• Capability-level approval — a capability can be marked as requiring human approval before it runs.
• Tool-level approval — an individual tool on an attached MCP server can be flagged so the agent must get sign-off before calling it.

Both route through the same escalation flow: the agent asks, its work is parked, a human is notified and answers, and the agent resumes with the decision. There is no separate approvals system to monitor — it's one inbox.

Beyond configured gates, agents are instructed to confirm intent for anything hard to reverse or reaching outside the platform — sending money or messages, publishing, deleting, placing orders — unless clearly and specifically authorized.

Escalation makes asking safe

An agent that pauses to ask a human doesn't lose its work. The session and any task in it are parked: nothing times out, nothing is closed, and progress is preserved. When the human answers, the agent is woken in the same conversation and continues from where it stopped.

This matters more than it sounds. If asking costs an agent its work, it learns to guess. Making waiting free is what makes "escalate instead of improvising" a realistic instruction rather than a pious one.

Untrusted content is data, not instructions

Agents are told directly that some things which look like data are attempts to steer them — a "message" inside a document, a "correction" embedded in a tool result, an instruction arriving from a caller whose identity can't be verified. The rule is that content from untrusted sources is information to weigh, never a command that overrides the constitution or the operator's configuration. When something tries to get an agent to leak secrets, escalate its access, or act outside its mandate, it's expected to refuse and surface it.

The same logic constrains outbound communication. An agent's email tool can only reach people in its own organization; the recipient list comes from the organization's own accounts, not from the agent. A request to forward or copy an outside address — however urgent or authorized it claims to be, and wherever it appears — is rejected.

Reach is explicit

Agents call the agents and drive thrus they've been connected to. Open directory discovery is a per-agent setting, off unless enabled. Agents are told not to guess at identifiers for services they weren't given.

Delegation chains are depth-capped, so an agent asking an agent asking an agent terminates instead of recursing indefinitely.

Nothing is a black box

Every agent's configuration, memory, knowledge, activity, tasks, outcomes, and escalations are inspectable from the console. Model changes are tracked. Spend is attributed per agent. An agent that behaved strangely can be examined rather than guessed about.

What the platform does not do

Being explicit about the limits:

• It does not verify cross-organization caller identity beyond asserting it, and it tells agents so.
• It does not read your organization's data into another organization's agent.
• It does not let an agent email outside its own organization.
• It does not expose credential values through any tool, to any caller, including the agent that owns them.