> For the complete documentation index, see [llms.txt](https://docs.omnata.com/omnata-product-documentation/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.omnata.com/omnata-product-documentation/omnata-sync-for-snowflake/how-it-works/security-and-privacy.md).

# Security and Privacy

Omnata Sync is delivered as a [Snowflake Native Application](https://docs.snowflake.com/en/developer-guide/native-apps/native-apps-about).

This means that each customer has a dedicated instance of the application, running within the controlled boundary of their Snowflake account. You can read an overview of the security advantages that the Native Applications Framework offers [here](https://www.snowflake.com/blog/snowflake-native-apps-security/).

### Installation

The Omnata Sync Engine is installed by user with the Snowflake ACCOUNTADMIN role, from the [Snowflake Marketplace](https://app.snowflake.com/marketplace). This creates a special type of database in your Snowflake account, known as an "application". It contains all of the application code required to configure, schedule and observe data sync tasks.

In addition to this, plugin applications are installed from the Marketplace, which contain the application code that communicates with a particular application. The Sync Engine uses these plugins to read data from and/or write data to the application.

In both cases, these applications start with no privileges to access any tables or other objects within the Snowflake account. These are granted as part of the configuration process, for example if you wanted to sync a Leads table to Salesforce, you would first grant **select** privileges on it to the Sync Engine application.

Installing an application does not give the application provider (Omnata) any access into your Snowflake account.

After a consumer installs an application in their account, Omnata is made aware via records in the [LISTING\_EVENTS\_DAILY](https://docs.snowflake.com/en/sql-reference/data-sharing-usage/listing-events-daily) shared table. This provides us with contact details of the person who installed the app, and we will send an automated welcome email. Note that this process does not provide us with any access to your Snowflake account, it is simply a feed of admin contact information.

### Account-Level privileges requested

The following table explains each account-level privilege requested by the Omnata Sync Engine upon installation, what it is used for, and whether it is mandatory for core functionality or optional.

{% hint style="info" %}
All privileges are requested at installation time regardless of whether optional features are used. Optional privileges can be revoked if you do not intend to use the associated features, though this may limit Omnata's ability to provide remote support diagnostics.
{% endhint %}

<table data-search="false"><thead><tr><th>Privilege</th><th>Why Omnata needs it</th><th>Required?</th></tr></thead><tbody><tr><td><code>EXECUTE TASK</code></td><td>Syncs run on schedules via Snowflake Tasks on your warehouse. This privilege allows the app to execute those scheduled sync tasks.</td><td><strong>Mandatory</strong></td></tr><tr><td><code>EXECUTE MANAGED TASK</code></td><td>Runs serverless (warehouse-less) background tasks for billing events, internal table maintenance, and enabling syncs to run without a dedicated warehouse.</td><td><strong>Mandatory</strong></td></tr><tr><td><code>CREATE DATABASE</code></td><td>Creates the database that stores inbound sync results - these are the landed tables you query directly. Also used for internal collaboration tables.</td><td><strong>Mandatory</strong></td></tr><tr><td><code>CREATE EXTERNAL ACCESS INTEGRATION</code></td><td>Creates External Access Integrations (network rules + integration) scoped to only the specific API endpoints each connector needs to reach (e.g., Salesforce, HubSpot). No other outbound traffic is permitted.</td><td><strong>Mandatory</strong></td></tr><tr><td><code>CREATE SECURITY INTEGRATION</code></td><td>Creates OAuth security integrations for connectors that authenticate via OAuth (e.g., Salesforce, Google, Microsoft). Not needed for API key-based connectors.</td><td><strong>Optional</strong> - only required if using OAuth-based connectors</td></tr><tr><td><code>CREATE SHARE</code></td><td>Used for an opt-in support/collaboration feature. When enabled by you, Omnata can send diagnostic SQL queries that run in the app's context, with results shared back via this share. You control when this is active and for how long.</td><td><strong>Optional</strong> - the app functions fully without this. Only used if you explicitly enable the support collaboration feature.</td></tr><tr><td><code>CREATE LISTING</code></td><td>Wraps the support collaboration share (above) into a private listing so it is accessible to Omnata's provider account across regions.</td><td><strong>Optional</strong> - same as above, tied to the opt-in support collaboration feature.</td></tr></tbody></table>

### Configuration

Omnata Sync includes an administration User Interface built with [Streamlit](https://docs.snowflake.com/en/developer-guide/streamlit/about-streamlit), and this runs on a warehouse chosen by the end user.

### Network access

In order to sync data with external systems, three features are used by the Sync Engine:

* [Network rules](https://docs.snowflake.com/en/user-guide/network-rules) are used to permit communication with specific domains
* [Secrets](https://docs.snowflake.com/en/user-guide/api-authentication#managing-secrets) are used to securely store credentials within the Snowflake account
* [External access integrations](https://docs.snowflake.com/en/developer-guide/external-network-access/creating-using-external-network-access) are used to tie network rules and secrets together and collectively permit API calls to be made to applications. External Access Integrations require the ACCOUNTADMIN role to configure, and can not be directly created by the application.

### Data Storage

All configuration data, sync run history and record data are stored as Snowflake tables inside the native application instance. Omnata do not have access to this information. These tables are equivalent to any other regular table in the customer's Snowflake account in terms of how data is encrypted and secured.

To grant permission for a Snowflake role to access this data, run the following SQL statement:

```sql
grant application role OMNATA_SYNC_ENGINE.OMNATA_ADMINISTRATOR 
to role MY_ROLE;
```

### Event Sharing

Event sharing allows the Omnata app (running in your account) to share operational telemetry (logs, traces, metrics) back to Omnata. This gives Omnata visibility into app health and performance so we can proactively support our customer base.

1. The Omnata app emits telemetry (log messages, trace events, metrics) during sync execution
2. This telemetry is written to the **active event table in your account** (default: `SNOWFLAKE.TELEMETRY.EVENTS`)
3. When event sharing is enabled, Snowflake's internal infrastructure performs a **filtered, transformed copy** of only the Omnata app's events to Omnata's event table

#### Key information

* **It is not a share or view on your event table.** Omnata cannot see your event table or any other events in your account. Snowflake copies only the specific events emitted by the Omnata app - nothing else.
* **Privacy masking is applied before data leaves your account.** Database names, query IDs, warehouse names, user names, roles, and session IDs are either hashed (SHA-1) or omitted entirely. Omnata sees operational telemetry about the app's behaviour, not your environment details.
* **You control what is shared.** Event definitions are categorised as MANDATORY (required for Omnata to support the app) or OPTIONAL (you can choose to enable or disable). You can review what is being shared at any time in your event table.
* **Omnata pays for storage.** All costs for ingestion and storage of shared events on Omnata's side are borne by Omnata, not you.

#### What Omnata can see vs. what Omnata cannot see

| Omnata can see                                   | Omnata cannot see                                   |
| ------------------------------------------------ | --------------------------------------------------- |
| App package name, your account locator, region   | Database names, schema names                        |
| Log messages emitted by the app                  | Query IDs, warehouse names                          |
| Trace spans and performance metrics              | User names, roles, session IDs                      |
| Hashed (not readable) database/query identifiers | Any events from other applications or your own code |

**Snowflake reference documentation**

* [Use logging and event tracing for an app](https://docs.snowflake.com/en/developer-guide/native-apps/event-about)
* [Set up and manage an event table in the provider account](https://docs.snowflake.com/en/developer-guide/native-apps/event-manage-provider)
* [Provider guide: Observability for native apps](https://docs.snowflake.com/en/developer-guide/native-apps/native-apps-observability-provider)
* [Configure event definitions for an app](https://docs.snowflake.com/en/developer-guide/native-apps/event-definition)

### Support

In order to diagnose the cause of problems, Omnata may ask the consumer to [enable the sharing of lower level events](https://other-docs.snowflake.com/en/native-apps/consumer-enable-logging) for debugging. This is optional and can be revoked at any time.

In addition, Omnata has an opt-in support/collaboration feature. When enabled by the consumer, Omnata can send diagnostic SQL queries that run in the app's context, with results shared back via this share. This data sharing feature runs separately to the native Event Sharing feature described above. The consumer controls when this is active and for how long.

### Application Upgrades

Omnata can deploy new versions of the Sync Engine and plugins, by [publishing new versions](https://docs.snowflake.com/en/developer-guide/native-apps/versioning) and assigning them to accounts via release directives. Again, this does not give us any form of access into the consumer's account. The upgrade process is managed by Snowflake, we only have visibility of whether or not the upgrade process succeeded, and any error messages.

## Architecture diagram

<figure><img src="/files/jXWKTNNxYvT7BdU49ZdY" alt=""><figcaption></figcaption></figure>


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.omnata.com/omnata-product-documentation/omnata-sync-for-snowflake/how-it-works/security-and-privacy.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.