Read-only by architecture, not by promise.
Assurance monitors over an app that holds no write permission at all. Actions and Studio run under separate authorizations you grant knowingly, per product — and everything leaves an audit record.
Permissions, per product.
Assurance — read-only, structurally
Monitoring runs on an app that reads only the Webex operational data required for the checks you use. It holds no write permission — not a setting, a structural boundary.
Actions — separately authorized
Guided fixes use their own connection, authorized separately by a Webex administrator. Every fix follows preview, named approval, apply, verify — and lands in the audit trail.
Studio — permissions per builder
Workflows, macros, and bots state their permissions before an administrator enables them, and run only within rules an authorized administrator has reviewed and published.
Data and access boundaries.
No content access in Assurance
Assurance never requests access to Webex messages, recordings, transcripts, files, or meeting content. Optional products state their additional permissions before an administrator enables them — a bot you build processes only the messages and commands directed to it, in the spaces where it is installed.
No hidden changes
Guided fixes require a named approval. Automations run only after an authorized administrator publishes their explicit rules, within the scopes those rules were granted. Both leave an audit record.
No selling of customer data
We do not sell customer data. Approved subprocessors handle only the data needed to provide hosting, monitoring, and email services.
No data kept after offboarding
Live tenant data is deleted within the contracted period after offboarding. Backup copies expire under the published backup-retention schedule, and minimal deletion evidence is retained for the stated period.
Your data lives in its own isolated space.
Isolated by design
Every customer’s data lives in its own isolated space — a request without your organization’s context sees nothing.
Verified before every release
Isolation and read-only boundaries are verified automatically before every release — not checked once and assumed.
Logs minimize personal data
Operational logs minimize personal data. Names, email addresses, configurations, and credentials are excluded or scrubbed.
The paperwork and the controls.
DPA and subprocessor list
A data processing agreement and the subprocessor list are part of onboarding — in place before any customer organization is connected.
Role-based portal access
Portal access follows roles: who can view findings, who can approve fixes, who can publish automations. Approvals always carry a name.
Audit trail on every change
Every guided fix, workflow run, macro deployment, and bot response is recorded: what changed, who approved it or which published rule allowed it, and when.
Disconnect any time
Remove the authorization in Control Hub and access ends. Deletion follows the published timelines — see how offboarding works below.
How offboarding works.
Revoke in Control Hub
A Webex administrator removes the authorization in Control Hub — the same place it was granted.
Access ends
OmniCanary marks the connection inactive, discards stored token material, and stops scheduled access. Webex deauthorization can take a few minutes to propagate.
Data is deleted
Live tenant data is deleted within the contracted period. Backup copies expire under the published backup schedule; minimal deletion evidence is retained as described in the retention notice.
OmniCanary is hosted in the European Union (Amsterdam) on managed, encrypted infrastructure — encrypted in transit and at rest, TLS-only at the public edge. Before customer onboarding we publish a backup retention schedule and an incident contact.
Build a calmer Webex operation.
Tell us about your Webex environment and the work you want to improve. Onboarding opens in scheduled waves. Join the launch list for availability updates.