| # Security Notes | |
| ## Token model | |
| The orchestrator uses Hugging Face OAuth. Do not store a global admin `HF_TOKEN` in the Space. | |
| The user OAuth token is passed to HF Jobs as a secret named `HF_TOKEN`. The worker must never write it to the Bucket, traces, reports, generated files, or logs. | |
| ## Resource ownership | |
| Generated Spaces are constrained to the signed-in user's namespace and are private by default. | |
| The validation workflow is also limited to Spaces under the signed-in user's namespace. | |
| ## Hardware | |
| Hardware assignment is best-effort. GPU upgrades may involve billing and may fail through OAuth. The supported fallback is manual hardware selection by the user followed by a separate validation job. | |
| ## Traces | |
| Pi traces can contain prompts, tool outputs, paths, generated code, and potentially sensitive information. Raw traces should remain private. Redaction is best-effort and should not be treated as a formal data-loss-prevention system. | |
| ## Publication | |
| The app never publishes generated Spaces automatically. Users should review generated code, license requirements, and validation results before making any generated Space public. | |