Ternivo Connect Security
Ternivo Connect is designed so customers and AI agents can operate social workflows without placing provider passwords or raw provider credentials into prompts, scripts or support messages.
Workspace isolation
- Customer organizations and workspaces are isolated in the Connect data model.
- Connect backend tables use row-level security with direct anonymous/authenticated table grants revoked.
- A provider social identity cannot silently belong to two Ternivo owners.
- Customer delivery records are scoped to the owning organization/workspace.
Credential handling
- Provider OAuth tokens are stored server-side using application-layer encryption.
- Ternivo API/service credentials are stored as hashes where supported; raw values are shown once at creation.
- Provider passwords are not requested by Ternivo Connect.
- Organization SSO/SCIM and service identities are scoped separately from provider credentials.
Safer automation
- Idempotency prevents replay from duplicating the same canonical publish request.
- Provider deliveries retry independently so one failure does not resend successful networks.
- Public publishing can require approval by organization policy.
- Paid-media activation requires an explicit confirmation action.
- Signed webhooks and audit history make asynchronous actions inspectable.
Operational resilience
Ternivo distinguishes preflight, queued, provider-processing, published, verified, retriable-failure and action-required states. Failures remain visible with diagnostic context and next actions instead of disappearing into a generic queue.
Responsible reporting
If you believe you found a security issue, contact security@ternivo.app. Please do not publicly disclose a vulnerability before we have had a reasonable opportunity to investigate it.