Trust and security boundaries

Treat repository content, retrieved pages, tool descriptions, and model proposals as untrusted input. They cannot expand the user's permission.

Read a refusal as a boundary

An actual refusal identifies a stopped effect. Find its meaning in Status and error reference.

Use Troubleshooting to select inspection or recovery. Do not clear a refusal by editing identity or approval records.

Trust and limits

Portable file validation does not sandbox a model. A trusted local tool server can retain host filesystem and network rights.

Container controls and synthetic tests narrow specific boundaries. They do not establish universal native containment or arbitrary server safety.

For example, a catalog description can contain a hostile instruction. The agent must treat it as data, not a new tool permission.

Prompts and model refusals do not replace controls outside the model. Setup grants no authority to operate unattended teams.

Credentials and private bindings

Keep credentials out of portable definitions. Use private bindings where the supported feature requires them.

No parser here guarantees that arbitrary prose contains no secret. Inspect selected files before sharing them.

Review each execution environment

Review the prompts, skills, model and harness versions (a harness is an agent application such as Claude Code or Codex), tool scopes, and isolation for each later action.

A source scan or valid setup does not grant execution permission. If protected controls change, review the affected action again.

Getting useful help

Share the package version, command family, safe error code, expected action, and sanitized description. Keep tokens and customer data private.

Keep private paths and raw receipts out of public reports. Bug reports and feedback explains useful support context.

Support boundary

Current support records the activation limit. Plans and approval explains each separate authority.