Chapter 90 — Secure AI Platform Security Analytics & Threat Detection: Detection Engineering, Behavioral Analytics, Threat Intelligence, Correlation, Risk Scoring, Automated Detection & SOC Architecture
90.1 Introduction
Runtime observability provides the raw security signals needed to understand an AI platform.
Security analytics turns those signals into actionable conclusions.
A modern AI platform may generate millions of events from:
- users,
- sessions,
- APIs,
- authentication systems,
- authorization systems,
- databases,
- object storage,
- vector databases,
- AI models,
- RAG pipelines,
- agents,
- tools,
- containers,
- Kubernetes,
- networks,
- and cloud infrastructure.
Simply collecting these events is not enough.
The security system must determine:
- which events are normal,
- which events are suspicious,
- which events are related,
- which events indicate an attack,
- which assets are affected,
- how serious the activity is,
- and what response is appropriate.
This chapter develops a defensive security analytics architecture covering detection engineering, behavioral analytics, threat intelligence, event correlation, risk scoring, automated detection, Security Operations Center (SOC) integration, and continuous improvement.
90.2 Security Analytics vs Logging
Logging answers:
What happened?
Security analytics asks:
What does what happened mean?
For example:
Login failure
Login failure
Login failure
Successful login
New device
Large data download
A logging system records these events individually.
An analytics system can recognize a potentially suspicious sequence:
Repeated authentication failures
↓
Successful authentication
↓
New session/device
↓
Unusual resource access
↓
Large data transfer
The individual events become meaningful when analyzed together.
90.3 Security Analytics Architecture
A typical architecture is:
Applications
|
Infrastructure
|
AI Runtime
|
Identity
|
Network
|
Storage
|
v
Telemetry Collection
|
v
Normalization
|
v
Enrichment
|
v
Correlation
|
v
Detection Engine
|
+----------------+
| |
v v
Risk Scoring Alerting
| |
+--------+-------+
|
v
SOC / SIEM
|
v
Incident Response
The architecture should allow new telemetry sources and detection rules to be added without redesigning the entire system.
90.4 Detection Engineering
Detection engineering is the disciplined process of creating and maintaining security detections.
A detection should have:
- a defined threat,
- required telemetry,
- detection logic,
- expected behavior,
- false-positive conditions,
- severity,
- response guidance,
- test cases,
- an owner,
- and a review schedule.
A detection is therefore a maintained security control, not simply a query.
90.5 Detection Lifecycle
A useful lifecycle is:
Threat
↓
Detection hypothesis
↓
Required telemetry
↓
Detection logic
↓
Testing
↓
Deployment
↓
Monitoring
↓
Tuning
↓
Retirement
This lifecycle should be managed similarly to software development.
90.6 Detection Hypotheses
A detection begins with a hypothesis.
Examples:
Account abuse
A compromised account may exhibit authentication and access behavior inconsistent with its normal baseline.
Tenant probing
An attacker may repeatedly attempt access to resources belonging to other tenants.
Agent compromise
A compromised AI agent may execute unusual tool sequences or request permissions outside its normal task boundary.
Data exfiltration
A compromised identity may suddenly access and export unusually large amounts of sensitive information.
These hypotheses can then be translated into measurable signals.
90.7 Detection Inputs
A detection may consume:
- authentication logs,
- authorization logs,
- API events,
- network events,
- storage events,
- database events,
- AI execution events,
- tool-call events,
- configuration events,
- deployment events,
- endpoint/runtime telemetry,
- threat intelligence.
The more useful context a detection has, the better its ability to distinguish legitimate behavior from suspicious behavior.
90.8 Detection Rules
Simple rules are useful for obvious violations.
Examples:
IF
authorization_denied_count > threshold
FOR
same session
WITHIN
time window
THEN
generate alert
Another:
IF
privileged_configuration_changed
AND
no approved_change_record
THEN
high-severity alert
Simple rules should remain understandable.
Complexity should be introduced only when it improves detection quality.
90.9 Threshold Detection
Threshold detection is one of the simplest methods.
Examples:
failed_logins > 20 / 5 minutes
or:
tool_calls > 100 / task
or:
downloaded_data > configured_limit
Thresholds are easy to implement but can create false positives.
Therefore thresholds should consider context.
90.10 Context-Aware Detection
A threshold that is suspicious for one workload may be normal for another.
For example:
10,000 requests/hour
might be abnormal for a normal user.
But it may be completely normal for:
- a batch processor,
- an indexing service,
- a media-processing worker.
Therefore detections should consider:
- identity type,
- workload type,
- tenant,
- role,
- time,
- resource,
- application,
- environment.
90.11 Behavioral Analytics
Behavioral analytics attempts to understand normal patterns.
Signals can include:
- login times,
- request frequency,
- accessed resources,
- model usage,
- tool usage,
- data volume,
- geographic/network patterns,
- session duration,
- API sequence.
The system can compare current behavior against historical behavior.
90.12 User and Entity Behavior Analytics
A generalized behavioral model can monitor entities such as:
- users,
- service accounts,
- agents,
- workloads,
- tenants,
- devices,
- API clients,
- tools.
For example:
User A:
normal = 10–30 requests/day
today = 900 requests
or:
Agent B:
normal = 2–5 tool calls/task
today = 70 tool calls/task
Both may warrant investigation.
90.13 Behavioral Baselines
A baseline should not be a single fixed number.
A better model may consider:
average
median
percentiles
time-of-day
day-of-week
task type
tenant type
seasonality
This reduces false positives.
For example, higher traffic during business hours may be normal.
90.14 Entity Risk Profiles
Each important entity can maintain a dynamic risk profile.
Conceptually:
Entity
|
+-- identity risk
+-- behavior risk
+-- resource sensitivity
+-- recent security events
+-- policy violations
+-- anomaly score
The risk profile should be explainable.
Operators should be able to understand why risk increased.
90.15 Risk Scoring
A risk score can combine multiple signals.
Conceptually:
Risk Score =
Identity Risk
+
Behavior Anomaly
+
Resource Sensitivity
+
Policy Violations
+
Threat Intelligence
+
Historical Context
This does not need to be a single mathematical formula.
It is a decision-support mechanism.
90.16 Risk Score Example
Suppose an account:
- has several failed logins,
- successfully logs in,
- accesses a sensitive dataset,
- attempts an unauthorized action,
- then begins unusually high-volume downloads.
The analytics engine may increase the risk score progressively:
Initial login anomaly → low
New device → medium
Sensitive resource access → medium-high
Authorization violations → high
Large data transfer → critical
This is more useful than treating each event independently.
90.17 Risk Decay
Risk should not necessarily remain permanently elevated.
If suspicious activity stops and no additional evidence appears, risk can gradually decay.
Conceptually:
Incident
↓
High risk
↓
No additional suspicious activity
↓
Risk decreases over time
However, confirmed security incidents should remain associated with the entity's historical record even after the immediate risk decreases.
90.18 Event Correlation
Correlation connects events that may belong to the same incident.
Correlation dimensions can include:
- user,
- session,
- tenant,
- request ID,
- trace ID,
- IP/network source,
- workload,
- resource,
- model execution,
- agent execution.
Example:
Event A → user_123
Event B → session_456
Event C → request_789
Event D → tenant_A
The analytics system can determine that these events belong to one activity chain.
90.19 Temporal Correlation
Security events often become meaningful when they occur close together.
Example:
09:10 Login failure
09:11 Login failure
09:12 Successful login
09:14 New device
09:16 Sensitive document access
09:18 Bulk download
The time sequence provides important context.
90.20 Sequence Analytics
AI systems make sequence analytics particularly important.
An agent may perform:
read_document
→ summarize_document
→ generate_response
as normal behavior.
A suspicious sequence might be:
read_document
→ search_credentials
→ access_secret
→ invoke_network_tool
→ upload_external_resource
Each action may require separate authorization.
The sequence itself can provide an additional detection signal.
90.21 Graph-Based Security Analytics
A security platform can represent relationships as a graph.
For example:
User
|
Session
|
Request
|
Agent
|
Tool
|
Resource
|
Tenant
This makes it possible to identify relationships that may be difficult to see in individual logs.
Graph analytics can help answer:
- Which identity accessed this resource?
- Which agents used this tool?
- Which tenant was affected?
- Which workloads contacted the same destination?
- Which events share the same execution chain?
90.22 AI-Specific Threat Detection
AI platforms introduce unique signals.
Security analytics may monitor:
- prompt injection indicators,
- jailbreak attempts,
- abnormal prompt sequences,
- unexpected model routing,
- tool-call anomalies,
- retrieval anomalies,
- suspicious agent plans,
- policy violations,
- model-output anomalies,
- excessive inference consumption.
These signals should be correlated with conventional security events.
90.23 Prompt-Injection Detection
Prompt injection should not rely on a single classifier.
Useful signals may include:
- suspicious instruction patterns,
- untrusted retrieved content,
- attempts to override system policy,
- unexpected tool requests,
- sudden changes in agent behavior,
- repeated policy failures.
A stronger approach is:
Input signal
+
Context trust
+
Agent plan
+
Tool request
+
Policy decision
The combination is often more informative than any individual signal.
90.24 Indirect Prompt Injection Analytics
RAG systems may process external documents containing malicious instructions.
Security analytics can track:
document retrieved
↓
document trust classification
↓
model execution
↓
unexpected tool request
↓
policy denial
If this pattern repeatedly occurs around the same document, the document can be quarantined or re-evaluated.
90.25 Agent Behavior Detection
Agents should have task-specific behavioral baselines.
Monitor:
- number of steps,
- tool diversity,
- tool frequency,
- authorization failures,
- retries,
- execution duration,
- data accessed,
- external communication,
- task completion patterns.
A large deviation may indicate:
- prompt injection,
- broken planning,
- tool failure,
- compromised state,
- malicious input,
- or software regression.
90.26 Model Routing Analytics
AI platforms may route requests among multiple models.
Security telemetry should track:
request
→ selected model
→ reason/routing policy
→ execution result
Unexpected routing can indicate:
- configuration drift,
- policy failure,
- deployment error,
- unauthorized configuration change.
90.27 Model Abuse Detection
Attackers may attempt to consume excessive model resources.
Signals include:
- extreme request rates,
- unusually long prompts,
- unusually large outputs,
- repeated expensive-model calls,
- automated request patterns,
- excessive concurrent generations.
Defenses include:
- quotas,
- rate limits,
- concurrency limits,
- model-specific budgets,
- anomaly detection.
90.28 Data Exfiltration Analytics
Data exfiltration detection combines:
- identity,
- resource sensitivity,
- access volume,
- download volume,
- network destination,
- time,
- historical behavior.
Example:
Normal:
5 documents/day
Observed:
4,000 sensitive documents/hour
The system should increase risk and potentially trigger additional authorization or containment.
90.29 Sensitive Resource Risk
Not every resource has equal security importance.
A useful classification may include:
Public
Internal
Confidential
Restricted
Highly Restricted
Access to a highly sensitive resource should contribute more strongly to risk analytics than access to public data.
90.30 Threat Intelligence
Threat intelligence provides external context about potentially suspicious indicators.
Possible indicators include:
- malicious IP addresses,
- suspicious domains,
- known compromised infrastructure,
- malicious file hashes,
- known attack patterns.
Threat intelligence should be treated as contextual evidence, not absolute proof.
90.31 Threat Intelligence Enrichment
A network event can be enriched:
Source:
IP_A
Threat intelligence:
Known suspicious infrastructure
Combined result:
Higher investigation priority
Enrichment can also include:
- ASN,
- domain reputation,
- certificate information,
- malware classification,
- known campaign references.
90.32 Intelligence Quality
Threat intelligence can become stale.
Therefore track:
- source,
- confidence,
- timestamp,
- expiration,
- provenance,
- update frequency.
A stale indicator should not permanently label an otherwise legitimate resource as malicious.
90.33 Internal Threat Intelligence
Security teams should also maintain internal intelligence.
Examples:
- previously compromised accounts,
- previously malicious files,
- known attack patterns,
- confirmed malicious sessions,
- known vulnerable workloads,
- previously abused API clients.
Internal intelligence is particularly valuable for recurring attacks.
90.34 Detection Enrichment
A detection should combine multiple dimensions.
For example:
Authentication anomaly
+
New device
+
Sensitive data access
+
Threat-intelligence match
+
Abnormal download
The resulting alert is much stronger than any single signal.
90.35 Confidence vs Severity
These are different concepts.
Severity
How damaging could the event be?
Confidence
How strongly does the evidence indicate malicious behavior?
For example:
High severity
Low confidence
might mean a potentially dangerous event requiring investigation.
Conversely:
Medium severity
High confidence
might be a confirmed but limited incident.
Security systems should track both.
90.36 Detection Confidence
Confidence can be increased by:
- multiple independent signals,
- reliable telemetry,
- repeated behavior,
- strong contextual evidence,
- confirmed policy violations.
Confidence should decrease when:
- telemetry is incomplete,
- the event is known to have legitimate explanations,
- detection inputs are unreliable.
90.37 Detection Suppression
Some alerts are known to be expected.
For example:
scheduled backup
may produce large data transfers.
A suppression rule can prevent unnecessary alerts.
However, suppressions should be:
- explicit,
- scoped,
- time-limited,
- reviewed,
- audited.
Avoid broad permanent suppression.
90.38 Alert Deduplication
The same incident may generate hundreds of events.
Instead of producing:
500 separate alerts
the system should produce:
1 incident
500 related events
This reduces analyst workload.
90.39 Incident Aggregation
Related alerts can become an incident.
Example:
Incident #1234
User:
user_123
Tenant:
tenant_A
Events:
42 authentication anomalies
15 authorization failures
3 sensitive-resource accesses
1 bulk export
Risk:
Critical
The incident becomes the unit of investigation.
90.40 Security Operations Center Integration
A SOC typically requires:
- alert queue,
- incident management,
- investigation tools,
- dashboards,
- threat intelligence,
- case management,
- response workflows.
AI-specific incidents should integrate into the same operational process while preserving AI-specific context.
90.41 SOC Analyst Investigation View
An analyst should be able to view:
Identity
↓
Session
↓
Requests
↓
AI executions
↓
RAG retrieval
↓
Tool calls
↓
Resources
↓
Network activity
↓
Security detections
This dramatically reduces investigation time.
90.42 Automated Triage
Security analytics can automatically classify alerts.
For example:
Alert
↓
Context enrichment
↓
Risk calculation
↓
Known-good checks
↓
Threat intelligence
↓
Duplicate detection
↓
Priority assignment
The objective is to help analysts focus on the most important incidents.
90.43 Automated Response
Depending on risk, the platform may automatically:
- revoke a session,
- disable a token,
- block an IP/network source,
- rate-limit an account,
- quarantine a file,
- disable an agent,
- revoke a tool permission,
- isolate a workload.
High-impact actions should use carefully tested policies.
90.44 Response Guardrails
Automated response should include:
- authorization,
- scope limits,
- approval requirements,
- rollback capability,
- audit logging,
- emergency override,
- expiration.
Example:
Suspicious session
→ temporary restriction
→ human review
→ restore or permanently revoke
This is safer than irreversible automatic actions.
90.45 SOAR Integration
Security Orchestration, Automation and Response systems can coordinate repetitive response workflows.
Examples:
Alert
↓
Enrich identity
↓
Check threat intelligence
↓
Check recent deployments
↓
Check tenant impact
↓
Create incident
↓
Notify security team
Automation should reduce repetitive work while preserving human control over high-risk decisions.
90.46 Threat Detection for Multi-Tenant AI
Tenant-aware detection is critical.
A detection should distinguish:
normal activity within tenant A
from:
attempted access from tenant A into tenant B
Cross-tenant access attempts should generally receive strong security attention because they may indicate:
- application bugs,
- authorization failures,
- compromised accounts,
- malicious probing.
90.47 Cross-Tenant Detection
Possible detection logic:
IF
request.tenant != resource.tenant
AND
authorization_denied = true
THEN
record security event
IF
same actor repeats this pattern
THEN
increase risk
Repeated attempts may indicate deliberate probing.
90.48 Database Analytics
Database security analytics can detect:
- unusual query volume,
- privilege changes,
- unexpected schema modifications,
- bulk reads,
- unusual connection sources.
Database analytics should be combined with application-level context.
A query that appears suspicious in isolation may be completely normal for a scheduled background job.
90.49 Object Storage Analytics
Monitor:
- unusual downloads,
- bulk deletion,
- unusual sharing,
- unexpected access patterns,
- metadata changes,
- repeated failed access.
Sensitive object access should be correlated with identity and application context.
90.50 Runtime Threat Detection
Runtime analytics should identify:
- unexpected processes,
- abnormal CPU consumption,
- unexpected network connections,
- privilege changes,
- filesystem anomalies,
- container behavior deviations.
These events should be connected to:
workload identity
deployment version
container image
tenant
request/task
90.51 Deployment-Aware Analytics
Security analytics must understand deployments.
A sudden behavior change immediately after a deployment may indicate:
- software defect,
- configuration regression,
- policy change,
- compromised artifact,
- expected feature behavior.
Therefore security events should be correlated with:
- release ID,
- image digest,
- model version,
- configuration version,
- deployment timestamp.
90.52 Change Correlation
Example:
14:00 Configuration changed
14:02 Model routing changed
14:05 Unsafe-output rate increased
14:10 Security alerts increased
This sequence is significantly more useful than viewing each metric separately.
90.53 Detection During Canary Releases
Canary deployments provide a valuable security comparison.
Compare:
old version
vs
new version
for:
- authorization failures,
- security events,
- model policy violations,
- tool calls,
- resource consumption,
- suspicious outputs.
Unexpected security changes can automatically halt rollout.
90.54 Detection During Model Changes
Model upgrades should be monitored for changes in:
- refusal behavior,
- tool usage,
- token usage,
- output safety,
- latency,
- retrieval behavior.
Security analytics can identify regressions that ordinary infrastructure monitoring would miss.
90.55 Detection During Policy Changes
Policy changes can have immediate security consequences.
Monitor:
policy version
→ policy deployment
→ affected workloads
→ behavior changes
A policy change that unexpectedly increases denied or allowed actions should be investigated.
90.56 Detection Rule Governance
Every production detection should have:
Detection ID
Owner
Purpose
Threat
Data sources
Logic
Severity
Confidence
Testing status
Last review
Response
This prevents undocumented security logic from accumulating.
90.57 Detection Versioning
Detection rules should be versioned.
Example:
DETECT-042 v1
DETECT-042 v2
DETECT-042 v3
When an incident occurs, investigators should know which rule version produced an alert.
90.58 Detection Regression Testing
Changes to detection rules can accidentally remove security coverage.
Therefore test:
- known attack scenarios,
- normal scenarios,
- boundary cases,
- telemetry failures,
- evasion variants.
A detection should not be considered production-ready merely because its query executes successfully.
90.59 Detection Coverage Matrix
A platform should maintain a matrix:
| Threat | Data Source | Detection | Automated Response | Test |
|---|---|---|---|---|
| Account compromise | Identity | Yes | Partial | Yes |
| Tenant probing | Authorization | Yes | Yes | Yes |
| Data exfiltration | Storage/network | Yes | Partial | Yes |
| Agent misuse | Tool telemetry | Yes | Yes | Yes |
| Runtime compromise | Host/container | Yes | Yes | Yes |
| Config tampering | Audit/config | Yes | Yes | Yes |
Coverage should be reviewed regularly.
90.60 Measuring Detection Quality
Useful metrics include:
Detection rate
How often known suspicious activity is detected.
False-positive rate
How often legitimate activity produces alerts.
Mean time to detect
How quickly suspicious activity is identified.
Mean time to triage
How quickly an analyst can classify the alert.
Mean time to respond
How quickly containment begins.
Detection coverage
How much of the relevant threat surface is monitored.
90.61 Detection Latency
Detection speed matters.
Conceptually:
Attack begins
↓
Telemetry generated
↓
Event collected
↓
Analytics processed
↓
Detection triggered
↓
Alert delivered
Reducing unnecessary delay can significantly improve incident containment.
90.62 Analytics Reliability
Security analytics must itself be monitored.
Track:
- detection engine availability,
- processing delay,
- event loss,
- rule execution failures,
- enrichment failures,
- threat-intelligence availability.
A broken detection pipeline can create a dangerous false sense of security.
90.63 Analytics Privacy
Security analytics may process sensitive information.
Therefore:
- minimize data,
- redact sensitive fields,
- restrict access,
- encrypt storage,
- audit analyst access,
- apply retention controls.
Analytics should not become an unrestricted secondary copy of all platform data.
90.64 Secure Security Analytics
The analytics infrastructure itself should use:
- strong identity,
- least privilege,
- network segmentation,
- encryption,
- protected configuration,
- immutable audit records,
- secure backups.
Attackers must not be able to manipulate risk scores or detection results easily.
90.65 Attackers Against Detection Systems
An adversary may attempt to:
- flood telemetry,
- evade detection thresholds,
- trigger false alerts,
- disable detection rules,
- manipulate timestamps,
- generate misleading events,
- exploit parser weaknesses.
Therefore detection systems require their own threat model.
90.66 Detection Evasion Resistance
Do not rely on one signal.
For example, instead of detecting only:
requests > threshold
combine:
request rate
+
identity behavior
+
resource sensitivity
+
session context
+
data volume
Multiple independent signals make evasion more difficult.
90.67 Canary Detection Rules
New detections can be deployed gradually.
Example:
Development
↓
Security test environment
↓
Shadow mode
↓
Limited production
↓
Full production
Shadow mode allows detection logic to operate without automatically affecting users.
90.68 Shadow Detection
In shadow mode:
event
↓
detection
↓
risk result
↓
log only
The platform can measure:
- alert volume,
- false positives,
- performance,
- analyst usefulness.
Only after validation should automated response be enabled.
90.69 Detection Performance
Security analytics must not create unacceptable application latency.
Heavy analytics should often operate asynchronously:
Request
↓
Primary security controls
↓
Application response
↓
Asynchronous analytics
Critical authorization decisions remain synchronous.
Large-scale behavioral analytics can operate asynchronously.
90.70 Streaming Security Analytics
Real-time streams are useful for:
- authentication anomalies,
- API abuse,
- agent behavior,
- data exfiltration,
- runtime events.
A streaming pipeline might be:
Events
↓
Stream
↓
Normalization
↓
Enrichment
↓
Correlation
↓
Detection
↓
Alert
90.71 Batch Security Analytics
Batch processing remains useful for:
- historical analysis,
- trend detection,
- model behavior analysis,
- long-term baselines,
- retrospective investigations.
A mature platform generally uses both streaming and batch analytics.
90.72 Historical Threat Hunting
Threat hunting asks:
If an attacker behaved this way, where else did it happen?
Analysts can search historical telemetry for:
- related identities,
- related resources,
- similar tool sequences,
- similar network destinations,
- similar model behavior.
This helps determine incident scope.
90.73 Threat Hunting Hypotheses
A hunt should start with a hypothesis.
Example:
An attacker may have attempted to enumerate tenant resources before a successful unauthorized access.
The analyst can then search:
authorization denials
+
resource enumeration
+
session identity
+
successful access
Hypothesis-driven hunting is more effective than arbitrary searching.
90.74 AI-Assisted Security Analytics
AI can assist security analysts with:
- summarizing incidents,
- grouping related events,
- explaining detection logic,
- identifying unusual sequences,
- generating investigation timelines,
- suggesting additional evidence.
However, AI-generated security conclusions should remain advisory unless explicitly governed.
High-impact security actions should rely on deterministic controls and authorized workflows.
90.75 Protecting AI Security Analysts
If AI is used to analyze security data, the security-analysis agent itself needs protection.
Controls include:
- read-only access by default,
- strict data scope,
- tool allowlists,
- no unrestricted network access,
- human approval for response actions,
- prompt-injection protection,
- output validation,
- complete audit logging.
Security automation must not create a new privileged attack surface.
90.76 Security Analytics for AI Agents
A security-analysis agent may be given:
logs
alerts
traces
configuration
threat intelligence
It should not automatically receive:
unrestricted credentials
unrestricted production access
arbitrary shell execution
unrestricted data export
Analysis permissions and response permissions should be separate.
90.77 Incident Confidence
Security analytics should communicate uncertainty.
Instead of:
ATTACK CONFIRMED
when evidence is weak, use:
High-risk anomaly
Confidence: Medium
Evidence:
- unusual login
- new device
- sensitive data access
This improves analyst decision-making.
90.78 Security Analytics Feedback Loop
Every investigation should improve the detection system.
Detection
↓
Investigation
↓
Confirmed / False Positive
↓
Rule tuning
↓
New test case
↓
Improved detection
This creates continuous improvement.
90.79 Post-Incident Detection Review
After a confirmed incident, ask:
- Was the attack detected?
- How quickly?
- Which signal triggered detection?
- Which signals were missing?
- Were false positives involved?
- Could detection have occurred earlier?
- Was telemetry complete?
- Did the attacker evade a known rule?
- Should a new rule be created?
- Should existing rules be modified?
90.80 Security Analytics Governance
Security analytics should have formal governance.
Govern:
- detection ownership,
- data access,
- rule changes,
- severity changes,
- automation permissions,
- retention,
- threat-intelligence sources,
- analyst access.
Critical detection changes should require appropriate review.
90.81 Reference AI Threat Detection Architecture
AI PLATFORM
|
+----------------------+----------------------+
| | |
Identity Application AI Runtime
| | |
+----------------------+----------------------+
|
Event Collection
|
Normalization
|
Data Enrichment
|
+----------------+----------------+
| | |
Rule Engine Behavior Engine Threat Intel
| | |
+----------------+----------------+
|
Correlation
|
Risk Scoring
|
+---------+---------+
| |
Alert Hunt
| |
+---------+---------+
|
SOC
|
Incident Response
|
Containment
|
Recovery
|
Detection Feedback
90.82 Security Analytics Checklist
Detection Engineering
- [ ] Detection hypotheses are documented.
- [ ] Detection rules have owners.
- [ ] Rules are versioned.
- [ ] Rules are tested.
- [ ] False positives are measured.
- [ ] Detection coverage is tracked.
Behavioral Analytics
- [ ] User behavior is monitored.
- [ ] Service behavior is monitored.
- [ ] Agent behavior is monitored.
- [ ] Tenant behavior is monitored.
- [ ] Baselines are contextual.
- [ ] Risk scores are explainable.
AI Security
- [ ] Prompt attacks are monitored.
- [ ] RAG anomalies are monitored.
- [ ] Tool calls are monitored.
- [ ] Agent sequences are analyzed.
- [ ] Model routing is monitored.
- [ ] AI resource abuse is detected.
Threat Intelligence
- [ ] External intelligence can enrich events.
- [ ] Intelligence sources have provenance.
- [ ] Intelligence freshness is tracked.
- [ ] Internal threat intelligence is maintained.
SOC
- [ ] Alerts are correlated.
- [ ] Incidents are aggregated.
- [ ] Analysts can reconstruct timelines.
- [ ] Threat hunting is supported.
- [ ] Automated response is governed.
Security
- [ ] Analytics infrastructure is protected.
- [ ] Security data is access-controlled.
- [ ] Sensitive telemetry is minimized.
- [ ] Detection systems are monitored.
- [ ] Evidence can be preserved.
90.83 Security Analytics Maturity Model
Level 0 — Reactive
Manual review of basic logs.
Level 1 — Rule-Based
Basic threshold detections and centralized alerts.
Level 2 — Correlated
Multiple event sources are correlated.
Level 3 — Behavioral
User, workload, tenant, and agent baselines are implemented.
Level 4 — AI-Aware
Model, RAG, prompt, policy, and tool behavior are included.
Level 5 — Adaptive
Continuous threat hunting, automated enrichment, governed response, detection testing, and feedback-driven improvement operate continuously.
90.84 Final Principles
Principle 1 — Detection must be evidence-based
An alert should have explainable supporting evidence.
Principle 2 — Context matters
The same event can have different meanings in different environments.
Principle 3 — Correlation is powerful
Attack behavior often emerges from sequences rather than individual events.
Principle 4 — AI requires specialized analytics
Models, agents, RAG, prompts, and tools create security signals unavailable in traditional applications.
Principle 5 — Risk must be explainable
Security analysts should understand why risk increased.
Principle 6 — Automation requires guardrails
Automatic response must be controlled, reversible, and auditable.
Principle 7 — Detection is software
Rules require testing, versioning, ownership, and maintenance.
Principle 8 — Threat intelligence is context
External intelligence should enrich evidence rather than replace internal verification.
Principle 9 — Monitor the detection system
A security platform must know when its own detection capability is degraded.
Principle 10 — Every incident should improve detection
Security analytics should continuously learn from confirmed incidents and false positives.
90.85 Conclusion
Security analytics transforms raw telemetry into defensive intelligence.
For a modern AI platform, effective threat detection must span:
- identity,
- APIs,
- applications,
- databases,
- storage,
- networks,
- containers,
- models,
- RAG,
- agents,
- tools,
- policies,
- configurations,
- and user behavior.
The strongest architecture combines:
Telemetry
+
Context
+
Correlation
+
Behavior
+
Threat Intelligence
+
Risk Analysis
+
Detection
+
Human Investigation
+
Governed Automation
The objective is not to generate the largest number of alerts.
The objective is to identify meaningful security threats quickly, explain why they are suspicious, understand their scope, and enable safe containment.
Final principle:
A mature AI security analytics system should continuously transform distributed runtime signals into contextual, explainable, testable, and actionable security decisions—while preserving privacy, minimizing false positives, and keeping high-impact response under strong authorization and human governance.
Top comments (0)