March 2026
Best Practices for IP-Preserving Paid Skills
When you sell a skill as a service, customers pay to use it — not to see how it works. Skillbase provides two mechanisms to keep your sensitive information safe while your skill earns revenue.
Environment Variables
If your skill calls external APIs, don't put API keys in your source files. For example, if your skill uses the OpenAI API to generate reports, hardcoding your API key in the source means anyone who downloads or inspects the skill can see — and use — your key. Use environment variables instead: your keys are stored encrypted on the server and injected at runtime, so they never appear in your skill's source code.
Setup
Go to your skill's Settings → Environment Variables and add each secret with:
- Name — e.g.
OPENAI_API_KEY - Value — your actual key (stored encrypted, never displayed again)
- Allowed origins — URL prefixes the key is permitted to reach, e.g.
https://api.openai.com
Reference them anywhere in your skill with $VARIABLE_NAME:
In SKILL.md, describe the usage naturally:
Use $OPENAI_API_KEY to call the OpenAI chat completions API
for generating analysis reports.In scripts, use them directly:
curl -H "Authorization: Bearer $OPENAI_API_KEY" \
https://api.openai.com/v1/chat/completionsHow it's protected
- Values are encrypted at rest — not visible in the UI, API, or logs after saving
- Injected into the execution environment only at runtime
- Allowed origins restrict where each key can be sent — even if a script is modified, the key can only reach the domains you specified
Private Directory
We recommend following the Claude skill best practices for structuring your skills. On top of that standard structure, Skillbase adds a ./private directory. Files placed here are available to your skill at runtime, but our agent and sandbox are designed to ensure they are never exposed to customers.
This is where you put the things that make your skill uniquely valuable — proprietary prompts, custom algorithms, curated data:
my-skill/
├── SKILL.md
├── scripts/
│ └── main.sh
├── references/
│ └── guide.md
└── private/ ← protected
├── secret_sauce.md
├── scoring-model.json
└── training-data.csvHow it's protected
Each customer call runs in an isolated sandbox — a fresh container that is destroyed after the session. Your private files are available to the skill during execution, but:
- The customer's agent cannot read the sandbox filesystem
- Network egress is controlled — files cannot be exfiltrated to external servers
- The container is destroyed after each session — nothing persists
- Each customer gets their own isolated instance — no cross-session leakage
Customers get the output of your skill. They never see the files that produced it.
Best Practices
| What you have | Where to put it |
|---|---|
| API keys, tokens, credentials | Environment Variables |
| System prompts, proprietary prompts | ./private |
| Scoring models, algorithms | ./private |
| Curated datasets, training data | ./private |
| Database connection strings | Environment Variables |
Use both together: environment variables for credentials, the private directory for everything else you want to keep to yourself.