Back to top
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:
app entity with its name existsEntities created automatically when a threat names an application have no state, so they also read as Discovered until someone reviews them.
| 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 |
| Secure60 Browser | The AI site the browser is on (ai_app_name) |
Prompt and response on ChatGPT, Claude and Gemini; a visit (site, time, user, no content) on the other AI sites in the Secure60 site lists, with warn and block available per site or per list |
| 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 |
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.
The Secure60 Browser extension runs in Chrome and reports the AI sites a user opens. It uses the same application names and providers as the AI Traffic Detection template, so a site seen in the browser and the same site seen on the network are one application on the AI Activity page. On ChatGPT, Claude and Gemini it also records the prompt and response, and whether the signed-in account is corporate or personal. Secure60 publishes six site lists of AI sites that every organisation inherits, and each browser group attaches the lists it wants. For each list, or each site, the group chooses to record the visit, record in full, record metadata only, ignore, warn the user, or block the site. Attaching all six lists as listed records every AI site on them, which is how unknown AI use is discovered. A site on no attached list is not watched. It does not see desktop or mobile apps or other browsers.
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.
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, network_tls_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 |
The destination host reaches those fields from the product parsers:
| Source | http_domain / http_uri |
dns_domain |
network_tls_server_name |
|---|---|---|---|
| Fortinet FortiGate | hostname and url on web filter and application control logs |
qname on DNS logs |
sni on SSL inspection logs |
| Palo Alto Networks | URL on URL filtering logs | — | Server Name Indication on decryption logs |
| Zeek | host and uri in http.log |
query in dns.log |
server_name in ssl.log |
| Squid | the request URL | — | — |
| BIND, dnsmasq | — | the query name | — |
| Cisco ASA | the URL in messages 304001 and 304002 | — | — |
| Juniper SRX | url and obj on UTM web filtering logs |
— | — |
A firewall records these hosts only from the security profiles that see them: a FortiGate logs qname with DNS filtering, hostname with web filtering or application control, and sni with SSL inspection; a traffic log alone carries addresses and ports, which match only the IP range and local port signals.
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"
http_domain, dns_domain, network_tls_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.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.
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).