Least-privilege access
Request and enable only the Meta access required for a documented support workflow.
Security language should be specific enough to be useful and restrained enough to be true. This page describes working principles without claiming certifications, guarantees, or controls that have not been independently verified.
These principles guide the private beta and ongoing release decisions. They are not an audit report or certification statement.
Request and enable only the Meta access required for a documented support workflow.
Restrict private-beta workspaces to approved participants and already-authorized Page connections.
The contact interface rejects attachments and warns users not to share passwords, tokens, credentials, or secrets.
Access, provider relationships, contact routes, incident handling, form delivery, and legal disclosures must stay aligned with the service’s actual operation.
Verify who can reach each workspace and which Page authorizations remain valid.
Keep service secrets out of public code, forms, screenshots, and customer messages.
The inquiry form shows whether delivery is available and limits the data it accepts.
Use neutral synthetic product scenes and avoid unrelated private deployment content.
Do not include passwords, access tokens, credentials, customer message content, or other secrets in an inquiry. Use the Security category when the contact form indicates that delivery is available.
This page intentionally makes no claim of SOC 2, ISO 27001, encryption scope, penetration testing, uptime, or breach-response timing. Any future claim must be backed by current evidence and legal review.
See how the service approaches Meta Platform Data, customer context, access, disconnection, and deletion requests.