Shadow AI settings
Manage API keys, syslog sources, rate limiting, data retention, and risk score calculation.
Overview
The Settings page is where you configure the data sources, access controls, and operational parameters for Shadow AI detection. It is divided into five sections: API keys, syslog sources, rate limiting, data retention, and risk score calculation.
API keys
API keys authenticate event ingestion from your network proxy, SIEM, browser extension, or any system that forwards traffic data to VerifyWise.
Creating a key
- Click "Create API key"
- Optionally enter a label (e.g., "Zscaler proxy")
- Click "Create"
- Copy the full key immediately — it will not be shown again
Managing keys
The API keys table shows each key's prefix, label, status (Active or Revoked), creation date, and last-used date. You can:
- Revoke: Deactivates the key immediately. Integrations using this key will stop working. This cannot be undone.
- Delete: Permanently removes a revoked key from the list.
Syslog sources
Syslog sources define where network traffic data comes from. Each source has a unique identifier and a parser type that determines how the incoming log lines are interpreted.
Parser types
| Parser | Description |
|---|---|
| Zscaler | Parses Zscaler Internet Access log format |
| Netskope | Parses Netskope Cloud Security log format |
| Squid proxy | Parses Squid HTTP proxy access logs |
| Generic key-value | Parses generic key=value formatted logs (default) |
To add a source, click "Add source", enter the source identifier (e.g., proxy-01.corp.com), and select the parser type. You can edit or delete sources at any time.
Data formats
This section documents the exact data formats VerifyWise expects when ingesting Shadow AI events, whether through the REST API or via syslog forwarding.
REST API event schema
Send events via POST /api/v1/shadow-ai/events with a JSON request body containing an events array. Authenticate using the X-API-Key header with a valid API key.
{
"events": [
{
"user_email": "alice@company.com",
"destination": "chat.openai.com",
"timestamp": "2026-02-09T14:32:00Z",
"uri_path": "/v1/chat",
"http_method": "POST",
"action": "allowed",
"department": "Engineering",
"job_title": "Senior Engineer",
"manager_email": "bob@company.com"
}
]
}| Field | Required | Description |
|---|---|---|
| user_email | Yes | Email address of the user who made the request |
| destination | Yes | Hostname or domain of the AI tool (e.g., chat.openai.com) |
| timestamp | Yes | ISO 8601 timestamp of the event |
| uri_path | No | URL path of the request (e.g., /v1/chat) |
| http_method | No | HTTP method (GET, POST, etc.) |
| action | No | "allowed" or "blocked" — whether the proxy permitted the request |
| department | No | Department of the user (e.g., Engineering, Finance) |
| job_title | No | Job title of the user |
| manager_email | No | Email address of the user's manager |
X-API-Key header with a valid API key created from the API keys section above. Requests without a valid key receive a 401 response.Syslog format examples
Syslog messages are expected over UDP/TCP using RFC 3164 or RFC 5424 framing. The PRI, timestamp, and hostname header are stripped automatically before parsing. Below are example log lines for each supported parser.
Zscaler (key=value)
user=alice@company.com dst=chat.openai.com method=POST uri=https://chat.openai.com/v1/chat action=allowed department=EngineeringNetskope (JSON-in-syslog)
{
"user": "alice@company.com",
"url": "https://chat.openai.com/v1/chat",
"method": "POST",
"activity": "allowed",
"department": "Engineering",
"timestamp": "2026-02-09T14:32:00Z"
}Squid (space-delimited)
1707489120.000 200 10.0.0.1 TCP_MISS/200 1024 POST https://chat.openai.com/v1/chat alice@company.com DIRECT/chat.openai.comGeneric key-value (CEF-like)
suser=alice@company.com dhost=chat.openai.com requestMethod=POST act=allowedField mapping
Each parser extracts fields from the source format and maps them to the normalized event schema:
| Normalized field | Zscaler | Netskope | Squid | Generic KV |
|---|---|---|---|---|
| user_email | user | user | field 8 | suser |
| destination | dst | url (hostname) | url (hostname) | dhost |
| uri_path | uri (path) | url (path) | url (path) | — |
| http_method | method | method | field 6 | requestMethod |
| action | action | activity | — | act |
| timestamp | syslog header | timestamp | field 1 (epoch) | syslog header |
| department | department | department | — | — |
Rate limiting
Rate limiting controls the maximum number of events that can be ingested per hour. This protects the system from being overwhelmed by a misconfigured data source or traffic spike.
- Set a numeric value to cap hourly ingestion
- Set to 0 or leave empty to allow unlimited ingestion
- Changes take effect immediately
Data retention
Data retention settings control how long different types of Shadow AI data are stored before automatic cleanup. Three categories can be configured independently:
| Category | Default | Description |
|---|---|---|
| Raw events | 30 days | Individual event records from ingestion (highest volume) |
| Daily rollups | 365 days | Aggregated daily statistics (lower volume) |
| Alert history | 90 days | Records of triggered alert rules |
Set a value to 0 or leave it empty to keep data indefinitely. Changes take effect on the next cleanup cycle.
Risk score calculation
The bottom of the Settings page explains how the risk score is calculated. Each AI tool receives a score from 0 to 100, recalculated nightly using four weighted factors:
| Factor | Weight | Description |
|---|---|---|
| Approval status | 40% | Unapproved tools (not in model inventory or not approved) receive the maximum score. |
| Data & compliance | 25% | Based on training-on-data policy, SOC 2, GDPR, SSO, and encryption at rest. |
| Usage volume | 15% | Normalized against the organization average. Higher usage increases the score. |
| Department sensitivity | 20% | Uses the highest sensitivity among departments accessing the tool. Finance, Legal, and HR are rated highest (80). |