Security model

Skills, versions, collections and sources live inside a vault boundary. Nothing is public: access starts at zero and is opened intentionally through workspace membership, grants and connected agents.

Hosted surfaces such as ChatGPT Apps and Claude Connectors authenticate through the host's OAuth and connector flow and are tracked as app installations.

Direct clients such as Claude Code, Codex, Cursor and VS Code use workspace-bound API keys. The two paths never mix: a key cannot act as a user session, and a session cannot act as a key.

Direct agent access uses restricted credentials, kept separate from ownership, review and admin actions inside the app.

• The plaintext key is shown exactly once, at creation.
• Only a one-way hash of the key is stored — the platform never keeps the key itself.
• Each key is bound to a single workspace and cannot switch vaults.
• Scopes are minimal: direct keys can read granted Ready packages and save authorized Drafts, but cannot release, approve, grant access or switch vaults.
• Keys expire (30/90/180 days), rotate in place with a 24-hour grace window, and can be killed instantly if exposed.
• The creator can always revoke their own keys; workspace owners and admins can revoke any key in the vault.

Every new Ready version starts from an exact package snapshot. Installskills validates its structure, inventories every file and treats all skill content as untrusted data before the version can be released.

The built-in engine checks secrets exposure, prompt injection, unsafe execution, external access, dependency risk, data handling and permission boundaries. Team and Enterprise Vaults may add independent organization criteria, but those rules can only add risk — never weaken the built-in result.

1. Validate SKILL.md, package paths, sizes and file inventory without executing package code.
2. Hash the exact draft and run deterministic checks plus the automated security assessment.
3. Record a server-trusted attestation bound to that package hash and policy revision.
4. Allow clean/low risk, require explicit acknowledgement or reviewer notes for medium risk, and block high/critical risk.
5. Re-check the same attestation at approval or Personal release, then expose only the immutable Ready version through granted, signed installs.

Draft, Review and Ready are distinct version states. Personal Vault releases require the trusted automated scan and an owner acknowledgement for medium risk. Team and Enterprise releases add an authorized human reviewer after the scan.

Connected agents receive granted Ready versions by default. The only Draft exception is an explicit, short-lived test package for the exact author; it stays Unreviewed and cannot participate in collections, grants or update checks. A newer release supersedes the previous version without rewriting history.

Every privileged action resolves the user, workspace membership, role and grants against the database before executing. Client type and user agent are treated as formatting hints, never as an authorization signal. Short-lived caching can speed checks up, but the database stays the source of truth.

The client-access layer applies rate limits and concurrent-request guards, so a misbehaving integration is contained before it reaches vault data.

Version history and access changes are recorded per workspace: what changed, who approved it and which agents can use it.