Security

Optional tracing sends sessions to the tracing service. Drafting sends scrubbed excerpts and skill content to a model provider. Security scans make no model calls.

This describes the hosted service. The Terms and Privacy Policy are unreviewed legal drafts.

Where your data goes

1. Sessions go to a tracing project for your workspace. After an admin approves slancha auth --tracing and the developer runs slancha init --tracing, Claude Code sends each turn, prompt and answer included, to a tracing project that belongs to your workspace alone. This covers every Claude Code session on that machine. The tracing service keeps what it receives under its own terms. See Sessions.

2. When an admin asks Slancha to write or improve a skill, scrubbed excerpts go to the workspace's model provider. The draft job reads sessions from your tracing project. It sends scrubbed excerpts of them, and the skill content it works on, to that model provider on your workspace's own key. The provider's own terms and retention apply to what it receives. The admin acknowledges this each time, and the acknowledgement is recorded. An admin can also let agent tokens start drafts in Workspace settings; that acknowledgement is given once, recorded, and covers every draft they start until it is turned off. The scrub is not perfect: a session can hold anything someone typed. The job checks everything it writes for credentials for that reason, and a hit proposes nothing. See Draft a skill from your sessions.

3. The security scan calls no model. It runs a skill scanner with its model-assisted analysis off, on the version being scanned, and nothing else. The scan needs no key.

4. Approved skills are served to enrolled machines. A developer's CLI downloads approved versions over HTTPS with a personal token. The CLI reports skill use: the skill, the version, success, a hash of the session id and a time. See Install the CLI.

Slancha stores every skill you upload and every proposal. When you request Decision-model training, your labeled examples are used to train a model for your organization. This differs from a model provider using content to train its own general-purpose models. Provider processing is described in the Privacy Policy. The Terms and Privacy Policy remain drafts under legal review; they do not establish a blanket no-training promise.

Who can do what

Roles and permissions are listed in Getting started. Each request is limited to its selected workspace. Approvers can approve their own uploads; a second reviewer is not required.

Tokens and keys

• Personal tokens start with slancha_pat_. Slancha stores a hash, never the token, and shows it once. A plain token can read the workspace's published skills and report their use, and cannot change anything. An agent token, from slancha auth --manage, can also upload, scan and run jobs, never above the proposer role, and expires after 30 days; it cannot approve, set acceptance criteria or manage anyone. Each person sees and revokes only their own.
• The model key is encrypted, bound to your workspace, when you save it. The API never returns it. It is decrypted only to run the job you started. You can replace or delete it.
• Tracing keys are a key pair for your workspace's tracing project. The ingest secret is encrypted the same way. The API decrypts it to read tracing status, when an admin asks for it on the Tracing page, and when an admin-approved CLI request for tracing pays out. Reads by an admin are recorded. On a developer machine it is stored in plain text, in ~/.config/slancha/tracing.json and in ~/.claude/settings.json, both readable only by that user. Every developer in the workspace holds the same pair. A Slancha operator can replace it.
• Sign-in approval. Members approve their own skill access. Only an admin can approve a request that includes tracing keys, and a request for an agent token needs a proposer or above. The code lives ten minutes and pays out once.

What is recorded

History shows every publication, with the person who approved it, and an audit trail of approvals, rejections, rollbacks and skill downloads. The audit trail in the database also records CLI sign-ins, token creation, draft acknowledgements and reads of the tracing keys. The console does not show those yet.

Limits

• No zero-retention promise. The tracing service and the model provider keep what they receive under their own terms.
• No SOC 2 or other audit report.
• A clean scan is not proof that a skill is safe. A skill is instructions an agent follows. Read what you approve.
• The download checks in the CLI are hashes, not signatures.
• Slancha shows scan findings and usage counts; it does not grade skill quality or say a skill is better.
• The Terms and the Privacy Policy are drafts.