Keep three decisions separate: who may manage the site, what an external tool may access, and who operates the server. One successful sign-in does not grant every capability.
Give people the access their work needs
Review the roles available in your installed version. Use individual accounts and test a limited account before broadening access. Keep publishing, integration configuration and server administration with the people responsible for those actions.
Scope machine access deliberately
Create separate API keys for separate workflows with only the needed scopes. Keep keys on the server or in an appropriate secret store, not in public HTML or a shared content note. Revoke a workflow key when the integration is no longer used.
Review the context sent to AI
Choose the provider, model and exact site or canvas context needed for the task. An external provider may process that context outside your server. Self-hosting the CMS does not make every AI request local or remove the provider’s terms and retention policy.
Read before allowing a change
Review tool destinations, arguments and effects. Read-only inspection and content mutation are different actions. Approval behavior depends on site settings and key policy; inspect the actual permission instead of assuming every request has the same approval path.
Assign recovery and maintenance owners
- Know where site data, media and deployment configuration live.
- Keep backups with restricted access and test restoration in a separate environment.
- Plan an upgrade, verify the release and inspect the result afterward.
- Keep credentials and deployment secrets out of support screenshots and public issue reports.
When something looks wrong
Record the affected page or workflow, time and request details without including secrets. Review the relevant account or key, revoke inappropriate access and investigate the application and provider logs within your permissions. Re-test with a limited account after the correction.