Shadow AI Discovery

This page is under review — the API examples below do not work

Every request example on this page targets cloud.arbitex.ai, which was decommissioned on 2026-07-28 and no longer resolves. These endpoints are not currently served at any host, and the capability described here is being reassessed.

The surface available today in the Arbitex admin console is Monitoring → AI Inventory, which reports the governed AI estate — the providers, models, MCP servers, and retrieval sources configured through Arbitex, with per-model usage. Do not follow the API examples on this page.

Shadow AI Discovery identifies unauthorized AI service usage across your organization by analyzing network traffic, DNS logs, proxy logs, and IdP audit events. It surfaces which AI services employees are using outside the Arbitex gateway — without requiring endpoint agents or browser extensions.

Discovery is a visibility-only function. Arbitex reports what it finds; enforcement is handled through your existing network controls (proxy policy, firewall rules). The output informs which services to sanction, route through the Arbitex gateway, or block at the network layer.

Data Sources

Shadow AI Discovery aggregates signals from three independent channels. Configure one or more depending on the network infrastructure available in your environment.

Proxy Log Analysis

Accepts log feeds from Zscaler, Netskope, and Palo Alto CASB. Arbitex analyzes HTTP/HTTPS traffic to known AI service endpoints and identifies user activity by source IP or authenticated identity where available.

Feed delivery options:

Method	Transport	Notes
Syslog push	UDP/TCP 514 or TLS 6514	Proxy sends events to Arbitex syslog receiver
API pull	HTTPS polling	Arbitex queries the CASB API on a configurable interval

Configure a proxy log source:

curl -X POST https://cloud.arbitex.ai/api/v1/admin/shadow-ai/sources \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "type": "proxy_log",
    "vendor": "zscaler",
    "delivery": "syslog",
    "syslog_port": 6514,
    "tls": true,
    "label": "Zscaler NSS Feed"
  }'

For API pull integrations, provide the CASB API credentials and polling interval (poll_interval_seconds).

DNS Log Analysis

Detects resolution of known AI service domains by passively analyzing DNS query logs. Accepts feeds from BIND, Infoblox, and Azure DNS. Because analysis is passive, this channel adds no latency and requires no inline deployment.

DNS analysis identifies which hosts are resolving AI service domains — it does not inspect payload content and cannot determine session volume from DNS alone.

Configure a DNS log source:

curl -X POST https://cloud.arbitex.ai/api/v1/admin/shadow-ai/sources \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "type": "dns_log",
    "vendor": "infoblox",
    "delivery": "api_pull",
    "api_endpoint": "https://infoblox.corp.example.com/wapi/v2.12",
    "api_key_secret": "infoblox-api-key",
    "poll_interval_seconds": 300,
    "label": "Infoblox WAPI"
  }'

For Azure DNS, use "vendor": "azure_dns" and provide the subscription ID and Log Analytics workspace ID.

IdP Event Correlation

Analyzes SCIM/SAML audit logs for SSO events to AI service providers. Detects OAuth grants and SAML assertions directed at known AI services, even when the actual traffic is not visible in proxy logs (for example, when employees are on unmanaged networks).

Supported IdPs: Okta, Entra ID (Azure AD).

Configure an IdP source:

curl -X POST https://cloud.arbitex.ai/api/v1/admin/shadow-ai/sources \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "type": "idp_events",
    "vendor": "okta",
    "okta_domain": "corp.okta.com",
    "api_token_secret": "okta-system-log-token",
    "poll_interval_seconds": 60,
    "label": "Okta System Log"
  }'

For Entra ID, use "vendor": "entra_id" and provide tenant_id and the client credentials for a service principal with AuditLog.Read.All.

AI Service Catalog

Arbitex maintains a built-in catalog of 200+ known AI service domains and API endpoints. Each catalog entry carries a classification that determines how discovery events are handled.

Classification	Meaning
sanctioned	Approved for use; traffic should be routed through the Arbitex gateway
unsanctioned	Not approved; usage generates alerts
unknown	Newly detected service not yet reviewed by an admin

New detections that match catalog entries are classified automatically. Services observed for the first time and not yet in the catalog are recorded as unknown and queued for admin review.

Listing Catalog Entries

curl https://cloud.arbitex.ai/api/v1/admin/shadow-ai/catalog \
  -H "Authorization: Bearer $TOKEN"

Filter by classification:

curl "https://cloud.arbitex.ai/api/v1/admin/shadow-ai/catalog?classification=unsanctioned" \
  -H "Authorization: Bearer $TOKEN"

Response fields per entry: service_id, name, domains[], classification, first_detected, last_seen, active_user_count.

Reclassifying a Service

curl -X PATCH https://cloud.arbitex.ai/api/v1/admin/shadow-ai/catalog/{service_id} \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "classification": "sanctioned",
    "note": "Approved via security review SR-2026-041"
  }'

Reclassification is recorded in the audit log with the admin identity, timestamp, previous classification, and the note field. See the audit log management guide for export and verification procedures.

Adding a Custom Entry

For AI services not yet in the built-in catalog:

curl -X POST https://cloud.arbitex.ai/api/v1/admin/shadow-ai/catalog \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Internal AI Service",
    "domains": ["ai.internal.example.com"],
    "classification": "sanctioned"
  }'

Discovery Dashboard

The discovery dashboard is available in the Arbitex Cloud portal under Security > Shadow AI Discovery.

Overview Panel

Displays organization-wide summary metrics:

• Total AI services detected (broken down by classification)
• Active users accessing unsanctioned services (rolling 7-day window)
• New detections timeline (daily bar chart, last 30 days)
• Classification backlog: count of unknown services awaiting review

Per-Service Detail

Click any catalog entry to view:

• Users who accessed the service, with access frequency and last-seen timestamp
• Access timeline chart (hourly activity over the selected date range)
• Estimated data volume where proxy log data is available
• Source channels that detected the service (proxy, DNS, IdP, or combination)

Per-User View

Navigate to Shadow AI Discovery > Users to view activity by identity:

• Which AI services each user has accessed
• Access frequency per service
• Last-seen date per service
• Total unsanctioned service count per user

User identity is resolved from proxy authenticated-user fields or IdP event subjects. Where only a source IP is available (unauthenticated proxy traffic), the entry is attributed to the IP address.

Alerts

Configure alerts to notify when new or high-volume unsanctioned activity is detected.

Alert Triggers

Trigger	Field	Description
New unsanctioned service	new_unsanctioned_service	Fires when a service classified unsanctioned is observed for the first time
Unsanctioned user threshold	unsanctioned_user_threshold	Fires when the number of distinct users accessing a single unsanctioned service exceeds threshold
New unknown service	new_unknown_service	Fires when a service is observed that is not yet in the catalog

All alert events are always written to the audit log regardless of webhook configuration.

Configuring Alerts

curl -X PUT https://cloud.arbitex.ai/api/v1/admin/shadow-ai/alerts \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "triggers": {
      "new_unsanctioned_service": true,
      "new_unknown_service": true,
      "unsanctioned_user_threshold": {
        "enabled": true,
        "threshold": 5
      }
    },
    "webhook": {
      "enabled": true,
      "url": "https://hooks.example.com/shadow-ai-alerts",
      "secret": "webhook-hmac-secret"
    }
  }'

Webhook payloads include trigger, service_id, service_name, classification, user_count, and timestamp. The payload is signed with the configured secret using HMAC-SHA256 in the X-Arbitex-Signature header.

Retrieving Current Alert Config

curl https://cloud.arbitex.ai/api/v1/admin/shadow-ai/alerts \
  -H "Authorization: Bearer $TOKEN"

Reports

Shadow AI Discovery generates scheduled summary reports available via the Cloud portal and API export.

Report Schedules

Report	Cadence	Contents
Weekly Discovery Summary	Every Monday	New services detected, classification changes, top 10 users by unsanctioned service count
Monthly Trend Report	First of each month	Usage trends, classification backlog age, data volume estimates, source channel health

Exporting Reports via API

List available reports:

curl https://cloud.arbitex.ai/api/v1/admin/shadow-ai/reports \
  -H "Authorization: Bearer $TOKEN"

Download a specific report:

curl "https://cloud.arbitex.ai/api/v1/admin/shadow-ai/reports/{report_id}/export?format=json" \
  -H "Authorization: Bearer $TOKEN"

Supported export formats: json, csv. Reports are also available for download directly from the Cloud portal under Security > Shadow AI Discovery > Reports.

Important Notes

Discovery does not block. Shadow AI Discovery is a visibility tool. It identifies and reports unauthorized AI service usage but does not intercept or block traffic. Enforcement requires action through your existing network controls — proxy policy, firewall rules, or conditional access policies in your IdP.

Enforcement path. The typical workflow is: discover unauthorized services via Shadow AI Discovery, classify them in the catalog, route approved services through the Arbitex gateway for policy enforcement, and use your network controls to block or redirect services that should not be used at all.

No endpoint software required. Discovery operates entirely from network-layer and identity-layer signals. No browser extensions, endpoint agents, or client-side software are installed on user devices.

Tenant isolation. All discovery data is stored within your organization’s tenant. There is no cross-tenant visibility or data sharing.

Integration deployment model. Data source integrations are either pull-based (Arbitex polls the CASB or IdP API on a scheduled interval) or push-based (your infrastructure sends syslog to the Arbitex receiver). No inline proxy deployment is required for any integration type.

Coverage gaps. DNS analysis cannot identify the authenticated user behind a query without additional enrichment (for example, DHCP lease correlation). IdP event correlation only captures sessions that go through your managed SSO — direct API key usage by employees is not visible through IdP logs alone. Layering multiple data sources improves coverage.