Trust and security

Remote Skills checks downloaded files before making them available to your agent. Those checks protect the download and loading process; deciding whether to follow a skill's instructions still belongs to your application.

A verified download is not a trusted instruction

Each catalog entry includes a SHA-256 digest: a fingerprint of the skill's exact bytes. The SDK rejects a download that does not match, catching corruption or changes to the file. This is byte integrity, and it does not prove that the instructions are correct or safe: a publisher can publish harmful instructions with a perfectly matching digest.

Your application therefore chooses which publishers to trust and what tools the agent may use. A skill's request to run a command or read a file still goes through your application's permissions. Remote Skills never executes bundled scripts, and a skill's allowed-tools field does not grant permission to use those tools. Instructions and resources are content for the agent to consider, not authority to act.

Skill files stay inside their own folder

Skills with resources travel as archives that the SDK unpacks into its cache. Because an archive specifies where its files go, the SDK checks that unpacking it cannot write outside the skill's folder. Only ordinary files and directories are accepted; filesystem links and device files are rejected too.

Conflicting paths are also rejected, including two paths pointing to the same file or names such as Guide.md and guide.md that some operating systems treat as identical. This prevents files from overwriting one another. A failed check rejects the whole skill instead of returning an incomplete result.

For publishers, the build checks the source folder and packages it with an ordinary SKILL.md file at the archive's top level, alongside any resources. There is no extra enclosing folder inside the archive.

Downloads have size limits

A small compressed file can expand into a much larger folder. To keep a skill from consuming unbounded bandwidth or disk space, Remote Skills limits both the download and the extracted contents:

These checks apply to the bytes actually received and unpacked, not just the sizes declared by the server or archive. Exceeding a limit stops loading instead of leaving the agent with incomplete content. Publishers can adjust their build limits through Configuration, while applications configure client limits through the API.

Requests follow your network policy

Production hosts use HTTPS to protect traffic in transit. The SDK checks the destination address on each connection and redirect, preventing a download link from reaching a blocked internal address. Non-public addresses are blocked by default; applications using an internal skill host can explicitly allow its addresses in the client's network policy. Local development has a separate opt-in for loopback HTTP.

Credentials go only to the configured host, so downloads from another private host need their own credentials. Authentication and authorization explains both the client configuration and the host's access checks.

If a request fails, diagnostics identify the problem without including credentials, response bodies, or skill content, and URLs are sanitized. Temporary connection failures may be retried, but invalid or unsafe content is rejected; the request failure reference has the details.

Your build environment remains part of the trust boundary

The publisher rejects output paths redirected through filesystem links and verifies the completed files before reporting success. Its locking mechanism also coordinates concurrent CLI builds, helping avoid mixed output.

These checks assume a trusted machine or CI runner: they can detect inconsistent output, but they do not isolate the build from another process running under the same user account. Access to the source and build directory is controlled by that environment, not by Remote Skills.