Shadow AI Monitoring: Known Endpoints and Reported Authorization

What 1-SEC checks

The known-endpoint check compares reported destination hosts with its implemented AI-service host list. Separate API-call handling can flag explicitly unauthorized calls and track endpoint/model/user context. These observations help maintain an AI-service inventory.

Read the implementation: handleNetworkForShadowAI

Required telemetry and context

Relevant input events: network_request, ai_api_call, llm_api_call, model_inference. Use a trusted producer at the real application boundary.

• dest_host
• endpoint
• model
• user
• authorized (string)

Field names above describe relevant context, not a complete API request. Consult the current event contract for envelope and detail requirements. Preserve booleans, numbers, and strings as the receiving handler expects them. Agent-provided text cannot independently verify identity or authorization.

Deployment, prevention, and response

Correlate service use with the organization's actual approved-service policy. Inspect host normalization and source provenance in the collector. Enforce network and credential permissions in the corresponding systems; the monitor does not itself issue approvals or block every external AI call.

Record the source event, affected agent/host, actual target, policy decision, and response result. Review enforcement configuration separately from detection. A recommendation, selected action, dry-run record, and completed action are different outcomes.

Reproduce the source fixtures

From a checkout of the linked 1-SEC source revision, run the selected fixtures with the repository's Go toolchain. These commands run tests; they do not execute a real attack against your systems.

go test ./internal/modules/aicontainment -run '^(TestShadowAIDetector_KnownEndpoints|TestShadowAIDetector_UnknownEndpoints)$' -count=1

The referenced source fixtures ran in the selected local package suites. Helper tests and synthetic events establish only the assertions shown, not production prevention or framework compatibility.

func TestShadowAIDetector_KnownEndpoints(t *testing.T) {
	sd := NewShadowAIDetector()
	known := []string{
		"api.openai.com", "api.anthropic.com",
		"generativelanguage.googleapis.com",
		"api.cohere.ai", "api.mistral.ai",
		"api-inference.huggingface.co",
		"api.replicate.com", "api.together.xyz",
		"api.groq.com", "api.perplexity.ai",
		"api.deepseek.com",
	}
	for _, host := range known {
		if !sd.IsKnownAIEndpoint(host) {
			t.Errorf("IsKnownAIEndpoint(%q) = false, want true", host)
		}
	}
}

func TestShadowAIDetector_UnknownEndpoints(t *testing.T) {
	sd := NewShadowAIDetector()
	unknown := []string{
		"api.example.com",
		"google.com",
		"internal.corp.net",
		"",
	}
	for _, host := range unknown {
		if sd.IsKnownAIEndpoint(host) {
			t.Errorf("IsKnownAIEndpoint(%q) = true, want false", host)
		}
	}
}

Tuning, evaluation, and coverage limits

Known AI traffic is not necessarily unauthorized, and a host list is not an exhaustive discovery engine. A new or proxied endpoint can be unknown. The authorized field must come from real policy context; untrusted callers cannot grant themselves permission by supplying a string.

Evaluate this behavior with representative authorized activity and a controlled known-positive case. Investigate the exact rule, inputs, and state before suppressing an alert. Do not assume a hard-coded heuristic is a configurable setting. Measure your own deployment; the source fixtures do not establish a benchmark, detection rate, compliance certification, or incident-prevention claim.