Protected skills

The local_protected execution mode adds verified integrity to skills that run on your machine. It is the right choice for enterprise skills that need local resources — files on disk, VPN, certificates, internal network — without exposing the skill's content to casual inspection or redistribution. This page makes clear what it protects and, with equal emphasis, what it does not.

local_plain exposes the files on disk; local_protected verifies integrity, runs in a temporary folder, and cleans up afterward.

The two modes

Mode	Where the content lives	Integrity	Transparency
local_plain (normal)	Files open at ~/.imaginne/skills/<key>/.	No extra verification.	Full — you can read everything.
local_protected	On disk, only a summary remains; the executable content arrives in a .imskill bundle.	Verified (HMAC signature + digest) on every run.	The content is not visible at rest.

What local_protected guarantees

• Integrity. The .imskill bundle carries an HMAC signature and a digest that are checked before any execution. If the content has been tampered with, execution is refused — you do not unknowingly run a modified version.
• Isolated, ephemeral execution. The verified content is extracted into a temporary folder with restricted permissions (0700), executed from there, and removed at the end. At rest, only the summary remains in the skills directory, not the code.
• Anti-shadowing. A local skill with the same name cannot "hijack" (replace) a protected skill from the organization. The governed version takes precedence, preventing anyone from injecting a malicious substitute under the same name.
• Resistance to casual redistribution. Because the content does not sit loose in the skills directory, copying the folder does not hand the skill to a third party.

What local_protected does NOT guarantee

Integrity is not secrecy

local_protected is not DRM nor content encryption. It protects against tampering and casual inspection, not against a determined operator.

• It does not hide execution from whoever controls the machine. The skill runs on your computer. Anyone with administrative access to the device can, in principle, observe the process while it executes.
• It does not encrypt the working data. Input files and the artifacts generated in outputs/ follow the same rules as any other skill.
• It does not replace access governance. Who can use the skill is still decided by profile and policy, not by the execution mode.

When to use each mode

• Use local_plain for transparent, team-internal skills, where code auditability matters more than hiding the content.
• Use local_protected when the skill encapsulates proprietary knowledge or integrates with internal systems (VPN, certificates, private endpoints) and you want to ensure it runs intact and cannot be silently replaced.

The remote_server mode has been retired — there is no server-side skill execution on the app surfaces. Every skill runs locally, in one of the two modes above.

How the mode is set

The execution mode is a property of the skill, declared in the manifest (execution_mode: local_plain | local_protected) and adjustable in the Skill Studio editor. See:

• Execution modes — the full mechanics from the skill author's point of view.
• Skills governance — where the administrator sets and reviews the mode.

If the protected executor is not available on the client, the call may return tool_deferred — in that case, talk to your organization's administrator.

See also

🔒Security & privacy

The full trust model.

Open →⚙️Skill execution modes

The mechanics of local_plain and local_protected.

Open →🔑Credentials & secrets

How skills receive secrets without exposing them.

Open →