Protect your sign-in
Socializioz uses its hosted authentication flow and maintains the authenticated session used by the application. Use these practices:- Use a strong, unique password when your sign-in method uses a password.
- Protect the Google account or other identity account used to sign in, including its own multi-factor authentication when available.
- Do not share login links, session tokens, OAuth authorization codes, or access tokens.
- Sign out after using a shared or public device.
- Treat unexpected sign-in prompts or authorization screens as suspicious until you confirm the domain and requested action.
Session behavior
The application restores the authenticated session through the canonical Socializioz authentication flow and tracks authenticated session activity for product observability. Use Log out when you want to end the current Socializioz session on a device. If you suspect that another device or browser has unauthorized access, secure the underlying sign-in account first and contact Support for help reviewing the incident. The public documentation does not promise a specific session lifetime, device-history interface, or global session-revocation behavior because those details can depend on the authentication service and current product implementation.Workspace boundaries
A workspace is an authorization and data boundary, not just a visual folder. Actions that operate on workspace data should resolve the authorized user and relevant workspace before accessing posts, campaigns, media, connected accounts, integrations, or brand context. For team workspaces:- Invite only people who need access.
- Use the minimum role required for the person’s work.
- Remove members who no longer need access.
- Keep separate client or business work in the appropriate workspace rather than mixing unrelated authorization boundaries.
- Review consequential work through approval workflows when the workspace and plan support them.
Connected social accounts
Social accounts are authorized through the provider connection flow. Socializioz does not need the user’s social-network password in order to operate an OAuth-authorized connection. A connected account can still be unusable for a specific action when:- Authorization expired or was revoked.
- Required provider permissions are missing.
- The account type does not support the requested capability.
- The account is associated with a different workspace.
- The current plan does not include the publishing action.
- The post, media, approval, or destination state is not valid.
Disconnecting versus provider revocation
Disconnecting a service in Socializioz stops Socializioz from using the active connection according to the product’s current disconnect workflow. If you also want to revoke authorization at the provider, use that provider’s authorized-app or business-integration controls. Review scheduled or pending work before disconnecting a publishing destination because removing authorization can prevent that content from executing.Apps, data services, and external integrations
Productivity and file integrations do not automatically become unrestricted access to an external account. Socializioz should use only the capabilities registered for the authorized connection and the relevant user/workspace context. External provider credentials stay behind the Socializioz integration boundary rather than being exposed to the browser or an AI client as ordinary workflow data. For integrations that are still in staged rollout, availability in internal source or testing does not mean the capability is public for every user. See Integrations for the current public map.Socializioz MCP and external AI clients
The native Socializioz MCP lets supported external AI clients operate authorized Socializioz workflows. It does not grant those clients a bypass around Socializioz controls. MCP actions remain subject to the applicable boundaries, including:- Socializioz authentication and client authorization.
- Workspace membership and selected workspace scope.
- Role and administrative permissions.
- Plan and feature availability.
- Connected-account ownership and health.
- Provider permissions and account capabilities.
- Post and approval state.
- Media and destination requirements.
- Publishing and retry validation.
Publishing safety
A request to publish is not proof that a post is live. Socializioz distinguishes the persisted workflow state and provider result so a client or user can tell the difference between:- A draft.
- Waiting for approval.
- Scheduled.
- Publishing/provider processing.
- Requiring external user action.
- Failed.
- Confirmed published.
Media and URL safety
When importing or attaching media:- Use the supported upload flow or a public HTTPS media URL when URL import is offered.
- Do not use URLs that embed private credentials or temporary secrets.
- Confirm that the asset belongs to the intended workspace.
- Review the media before publishing.
- Let Socializioz validate destination requirements rather than assuming a stored asset is publishable everywhere.
Activity and review
Use the Activity log and the affected product surface to investigate unexpected changes or execution results. Useful checks include:- Unexpected account connect/reconnect/disconnect activity.
- Posts or campaigns you did not create or modify.
- Approval actions you did not expect.
- Publishing failures or retries.
- Agent or external-client actions associated with the workspace where those events are exposed.
If you suspect unauthorized access
1
Secure the sign-in account
Change or recover the credentials for the identity you use to sign in. If you use Google, secure the Google account and review its security settings.
2
Log out from devices you control
End active Socializioz sessions on browsers or devices you can access.
3
Review workspace members
Check the current workspace membership and remove access that should not be there.
4
Review connected services
Open Connections, inspect unfamiliar or unhealthy connections, and revoke provider authorization where necessary.
5
Review operational history
Check the Activity log, Publishing Hub, scheduled work, campaigns, and other affected surfaces for unauthorized changes.
6
Contact Socializioz Support
Open Support and include the workspace, approximate time, affected account or post, and the unexpected behavior. Do not include passwords or raw access tokens.
Security and privacy claims
Product documentation should not invent or freeze legal or infrastructure claims that can change independently of the interface. For example, this page intentionally does not promise:- A particular TLS protocol version.
- A particular cloud encryption implementation.
- A fixed token-refresh interval for every provider.
- A specific incident-notification deadline.
- SOC 2, ISO 27001, GDPR, CCPA, DPA, SLA, data-residency, or retention commitments that are not stated in the controlling policy or customer agreement.