Discover AI Applications

An AI application appears on AI → AI Activity as soon as one source reports it. Until someone registers it and sets its lifecycle state, it is listed as Discovered and counted under Unknown AI. Discovery never creates an entity by itself: registering an application is a decision made on the AI Application Lifecycle.

An application is Discovered when it has AI activity and any of these holds:

Entities created automatically when a threat names an application have no state, so they also read as Discovered until someone reviews them.


Sources

Source How an application is identified What is recorded
Secure60 AI Protector The backend’s application name (app_name) and AI provider Every call with content, findings, model and tokens
AI Traffic Detection parser template The AI service a proxy, DNS, firewall or endpoint event reached (ai_app_name) The event: destination, host, user; no content
Secure60 agents The agent (s60-l1-analyst, s60-threat-hunter) Session steps, tool calls and decisions
Vendor audit records Records sent to the project with operation = ai-usage and the application in app_name Who, which application, which files; no prompt or response text

Secure60 AI Protector

Every Protector container reports the applications and users it served. Every 60 seconds each worker sends a seen list to the project as entity-tracking records: one record per application, carrying the backend’s AI provider, and one per resolved user. An application with a provider in these records is an AI application on the AI Activity page, whether or not it has made a call in the selected window.

Variable Default Meaning
S60_PROTECTOR_ENTITY_TRACKING on off stops the seen list, for deployments where a collector already tracks these applications and users
S60_PROTECTOR_SEEN_INTERVAL_SECONDS 60 How often the seen list is sent
S60_PROTECTOR_SEEN_MAX_ENTRIES 500 Applications, and separately users, kept per worker per interval; more are dropped and counted in the container log

The provider comes from the backend’s upstream URL (api.openai.com → OpenAI) or from the backend’s AI provider field when the URL does not identify it, such as a gateway, a proxy or a custom domain. See Secure60 AI Protector.


Network and endpoint logs

AI Traffic Detection is a Secure60-managed parser template in Integrations → Secure60 Collector → Parser Templates. Deployed to an organisation and linked to a collector profile, it runs on every event of that profile and marks events that show use of an AI service:

Field added Meaning Example
ai_app_name The AI application the event shows ChatGPT (web), OpenAI API, Ollama
ai_provider The provider OpenAI, Anthropic, Microsoft
ai_category The kind of use chat, api, coding, local, assistant
ai_detection The signal that matched domain, ip, user_agent, path, port, process

app_name is left unchanged. On proxy, DNS and firewall sources it names the log producer (squid, zeek, fortigate), and existing rules and searches filter on it. Events that already carry ai_provider, such as Protector events, are left alone.

Signals

The signals are tried in this order and the first match wins, so a third-party API called through the OpenAI SDK is named by its domain:

Order Signal Fields read Example
1 Domain or parent domain the first of http_domain, dns_domain, event_query_name, event_query, server_name (TLS SNI) chatgpt.com, *.openai.azure.com
2 Dedicated IP range ip_dst_address Anthropic’s published API ranges
3 SDK user agent http_user_agent, user_agent, http_useragent OpenAI/Python, Anthropic/Python, claude-cli/
4 LLM API path http_uri /v1/chat/completions, /v1/messages, /api/generate
5 Local model port ip_dst_port 11434 (Ollama), 1234 (LM Studio)
6 AI process process_name ollama, claude, cursor, codex

Shared service domains that carry non-AI traffic (for example raw.githubusercontent.com, graph.microsoft.com and *.office.com) are excluded, so ordinary Microsoft 365 or GitHub use is not tagged.

Example, a Squid proxy line:

in    app_name="squid"  http_domain="api.openai.com"  user_name="r.shah"
out   app_name="squid" (unchanged)
      ai_app_name="OpenAI API"  ai_provider="OpenAI"  ai_category="api"  ai_detection="domain"

Setting it up

  1. Deploy AI Traffic Detection from Parser Templates into the organisation (Parser Templates).
  2. Link it to the collector profile that receives your proxy, DNS, firewall or endpoint logs.
  3. Check the order. The template reads fields that the product parsers set (http_domain, dns_domain, server_name), so it must run after them. Parsers on a profile run in the order they were created; a copy created before the organisation’s Squid, Zeek or BIND parser runs first and finds nothing. Deploy the template after the product parsers, or deploy it again to move it last.
  4. Set ENTITY_TRACKING_APPNAME=true on the collector. With it, an event carrying ai_app_name produces an application tracking record for the AI application with its provider, beside the unchanged record for the log producer. These records put network-detected applications on the AI Activity page.

The domain list is maintained by Secure60. A new list reaches an organisation as a template update, shown as update available on the template; it is not applied automatically.

What network detection shows

A network-detected application is listed with Network only visibility. Its calls column counts tracking sightings, which grow with the collector’s export interval, and are not calls. Opening its audit trail lists its events, newest first, with the time, user, host and destination, marked Detected on the network · no content. Routing the application through a Secure60 AI Protector adds the prompt, reply and findings.

isEntity, isEntityGroup and isEntityState also match ai_app_name on raw events, so a rule can key on the AI application a network event names. The AI Governance pack uses this for its network rules (AI Application Lifecycle).


Back to top