Security model

Skills, versions, collections and sources live inside a workspace 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 workspaces.
• Scopes are minimal: direct keys can read granted Ready packages and save authorized Drafts, but cannot release, approve, grant access or switch workspaces.
• 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 workspace.

Every new Ready version starts from an exact package snapshot. Codenskills 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. Company Workspaces 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, then expose only the immutable Ready version through granted, signed installs.

Draft, Review and Ready are distinct version states. Company Workspace releases require the trusted automated scan and an authorized human reviewer; medium-risk approval requires a review note.

Connected agents can only receive Ready versions — never unreviewed drafts — and 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 workspace data.

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