Skip to main content
The Netskope connector reads application events from your Netskope tenant through Netskope’s REST API v2 and keeps only the activity for GenAI services. Each AI service then appears as Seen by Netskope in your Shadow AI discovery findings, with usage and blocked attempts counted separately. The gateway reaches Netskope over outbound HTTPS. Nothing needs to reach the gateway.

​
What the gateway reads

  • Application events only, from GET /api/v2/events/dataexport/events/application.
  • Not page, network, or transaction events, and not alerts. Findings never add up numbers in different units, so Netskope contributes exactly one stream. Reading alerts as well would count every block twice.
  • No content. No prompts, responses, or files are read.

​
Prerequisites

  • Shadow AI discovery turned on for your deployment. See Shadow AI discovery.
  • A Netskope admin who can create a service account and a role for it.
  • Someone who can set an environment variable on the gateway host. If Openlayer runs your gateway, that’s us.

​
Set up

1

Create a service account and API token in Netskope

In the Netskope console, go to Settings → Administration → Administrators & Roles → Administrators and click Service Account.
  • Assign it a role that can read application events through REST API v2. The token only needs read access to /api/v2/events/dataexport/events/application.
  • Generate a REST API token, and set its expiration in days.
Copy the token.
2

Allow the gateway's IP addresses

If your tenant restricts API access with an IP allowlist (Settings → Administration → IP Allowlist), add the gateway’s egress IP addresses to it. If Openlayer runs your gateway, ask us for them. Skip this step if your tenant has no allowlist.
3

Put the token on the gateway host

Set the token in an environment variable on the gateway host, such as NETSKOPE_API_TOKEN, and restart the gateway. If Openlayer runs your gateway, coordinate with us to set it.The admin portal stores only the variable’s name, never the token.
4

Connect Netskope

In the admin portal, go to Shadow AI → Discovery, click Connect, and choose Netskope. Fill in:
  • Tenant hostname: your tenant’s host, such as acme.goskope.com. A pasted URL is reduced to its host.
  • API token env var: the variable from the previous step. It defaults to NETSKOPE_API_TOKEN.
  • Backfill days: how far back the first sync reads, from 1 to 30. It defaults to 7.
Click Connect. The gateway checks the tenant and token with one call on a throwaway iterator index, so its real read position is never touched by the check. If the token is rejected, the error says so.The first sync starts right away. Findings appear as it reads, and a long backfill catches up over several syncs.

​
How the gateway reads

  • It uses its own read position. Netskope’s export API tracks each consumer’s position by an iterator index. The gateway uses its own, olga_discovery_<hash>, shown on the connector card as Iterator index. Never reuse it in a SIEM, the Splunk add-on, or Cloud Exchange: Netskope splits the records between consumers that share an index, so each would miss events.
  • It syncs every 5 minutes. Click Sync now on the card to start one immediately. Only one sync runs at a time.
  • The first sync reads back the backfill. Later syncs continue from where the last one stopped.
  • It respects Netskope’s rate limit. The export API allows 4 requests per second per endpoint, shared with your other consumers. The gateway waits as long as Netskope asks between pages, and backs off when it’s told to.
  • It recovers from interruptions without double-counting. If a sync is cut off mid-page, the next sync asks Netskope to resend that page, and events already counted aren’t counted again. If a page still can’t be stored or read again after 3 attempts, the gateway moves on and the card shows a warning.

​
Which events count as GenAI

An application event is kept if one of these matches, checked in order:
  1. The host of its url (or its domain, when the URL has none) is a domain in the catalog of AI services.
  2. Its app is the name of a catalog service, matched exactly. Netskope names every SaaS app, so a loose match would turn “Notion” into “Notion AI”.
  3. Its appcategory is an AI category, such as “Generative AI”. The app appears under Netskope’s name for it, with Unknown risk until it’s added to the catalog.
Everything else is counted by reason on the connector card and discarded, never stored. Netskope’s export API has no server-side filter, so every application event in your tenant passes through the gateway to be filtered.

​
Usage and blocked attempts

Netskope’s action field decides how an event counts:

​
Fields used

The gateway stores per-minute counts by service, host, user, and outcome for 30 days, plus the IDs of events it has already counted. It never stores raw events. Disconnecting Netskope deletes what it stored.

​
How findings appear

  • Findings list Seen by Netskope, counted in app events. A count is the number of activities Netskope recorded, not prompts or sessions: one event may carry many prompts, or none.
  • Blocked attempts are reported separately and never count as usage.
  • Per-user figures come from the user email.

​
The connector card

Open Connect on the Discovery page to see the Netskope card. It shows:
  • How often it syncs, and Sync now.
  • Totals: GenAI app events stored, duplicates, app events not stored (not GenAI or an unrecognized action), and rejected events.
  • The newest event seen, and how far behind now it is.
  • The Iterator index.
  • Warnings, if a page failed to store or the gateway gave up re-reading one.
  • What the last sync read and kept.
  • Values seen: the most common action, activity, access_method, and appcategory values on your GenAI app events.

​
Limitations

  • Only traffic that Netskope steers and inspects produces application events.
  • Events from apps connected through Netskope’s CASB API are included and counted too.
  • There are no device counts. Netskope’s device field is a device type, not an ID.
  • No prompt or file content is available.

​
Troubleshooting

Netskope rejected the token. Check that the service account’s role can read /api/v2/events/dataexport/events/application and that the token hasn’t expired. If your tenant uses an IP allowlist, check that it includes the gateway’s egress IP addresses.After you replace the token, update the environment variable on the gateway host and restart the gateway.
Something else is reading with the gateway’s iterator index. Remove the index from whatever else uses it. Only the gateway should read with olga_discovery_<hash>.
A long backfill takes several syncs to catch up, so give it time after connecting. If it keeps falling behind, your tenant may produce more application events than the gateway reads per sync. Reach out to us.
Your tenant sends action values the gateway doesn’t map. They’re listed under Values seen on the card. Send them to us so they can be mapped.