Concept
Safety & compliance
“Safe” means the system cannot take irreversible actions without policy and (usually) a human. “Compliant” means secrets, consent, platform rules, and audit trails are designed in — not bolted on.
Safety controls you will build
- Policy gate — allow/deny by actor + action + resource
- HITL states — approve / changes_requested before publish
- Budgets — max steps, tokens, wall time, revisions
- Idempotent publish — retries do not double-post
- Labeled fallbacks — never pretend canned text is a live model
Compliance checklist (practical)
| Area | Practice |
|---|---|
| Secrets | Encrypt at rest; never commit; redact from traces |
| OAuth | Real consent; store least privilege; support disconnect |
| Audit | Log denies, publishes, auth events (without raw tokens) |
| Platform | Respect Meta rate limits and content/app policies |
| Data | Know what PII you store; define retention if needed |
Threat model (½ page you will write in Step 17)
- What assets matter? (tokens, brand voice, publish capability)
- Who might misuse them? (prompt injection, stolen env, buggy tool)
- What control stops each path? (policy, encryption, HITL, evals)
Remember
Prompt text that says “never publish without approval” is not a control. A policy function that returns deny — and a test that proves it — is a control.