How should security teams implement AI-driven human risk analytics in compliance programs with both human and AI agent activity?

Why This Matters for Security Teams

AI-driven human risk analytics can turn scattered signals into a compliance-grade picture of how people and AI agents actually behave across identity, access, and sensitive workflows. That matters because most control failures are not caused by a single missed approval, but by patterns such as repeated privilege elevation, unusual data access, or unmanaged agent activity that gradually erode policy intent. A sound program should align with governance expectations in the NIST AI Risk Management Framework and related internal control objectives.

The main mistake is treating the analytics layer as a reporting dashboard rather than a decision support control. Compliance teams need evidence that risk scores are explainable, reviewable, and tied to specific outcomes such as access restriction, training, investigation, or exception handling. For AI agents, the same discipline applies: the analytics should show which agent actions were authorised, which were abnormal, and which humans retained accountability for the outcome. In practice, many security teams encounter risky activity only after an audit finding or incident review, rather than through intentional continuous monitoring.

How It Works in Practice

Effective implementation starts with defining the behaviours that matter to compliance, then mapping those behaviours to identity, endpoint, cloud, and application telemetry. For humans, that usually includes privileged access use, policy exceptions, dormant account reactivation, unusual geolocation, data exfiltration indicators, and repeated failed controls. For AI agents, it includes prompt sources, tool use, delegation chains, token scope, action frequency, and whether the agent is operating within an approved policy boundary. The analytics model should enrich raw events with business context, role context, and asset sensitivity so that “risk” means something operationally useful.

Security teams should separate detection logic from decision authority. The analytics engine can prioritise cases, but high impact actions still require human review, especially where employment, access, or regulatory findings could be affected. That control separation becomes more important as agentic systems are introduced, because the risk signal may involve both a human sponsor and an autonomous process acting on that sponsor’s behalf. Guidance from the OWASP Agentic AI Top 10 and the MITRE ATLAS adversarial AI threat matrix is useful when designing controls around prompt injection, tool abuse, and indirect manipulation.

• Define a risk taxonomy that covers human behaviour, privileged activity, and AI agent actions.
• Use identity, access, and telemetry correlation to produce case-level evidence, not just aggregate scores.
• Set thresholds for escalation, but require analyst approval for sanctions, access changes, or compliance disclosures.
• Record why a risk score changed, which data sources influenced it, and which control was triggered.
• Review model outputs for drift, bias, and over-reliance on weak signals before they drive policy decisions.

Teams should also establish retention, auditability, and model governance rules so the analytics output can stand up to internal audit and regulatory scrutiny. These controls tend to break down in fragmented environments where identity data, SaaS logs, and agent telemetry are owned by different teams and cannot be correlated at the same event granularity.

Common Variations and Edge Cases

Tighter risk scoring often increases process overhead, requiring organisations to balance faster detection against analyst workload and employee experience. Best practice is evolving for AI agents because there is no universal standard for how to score autonomous activity alongside human conduct, especially when the agent is semi-autonomous, shared across teams, or operating with delegated secrets. In those cases, the compliance program should treat the agent as a governed entity with clear ownership, scoped permissions, and explicit purpose limits.

One edge case is when a human initiates a legitimate workflow that later triggers a suspicious agent action. Another is when an agent inherits broad access through a service account and the resulting behaviour looks indistinguishable from human misuse unless the logs capture provenance, tool invocation, and approval context. This is where CSA MAESTRO agentic AI threat modeling framework and NIST Cybersecurity Framework 2.0 help translate abstract risk into control ownership, detection, and response.

For regulated environments, current guidance suggests keeping the compliance model conservative where decisions affect employment, finance, or customer trust. If the organisation cannot explain a score in terms of source data and control logic, it should not be used as the sole basis for enforcement. That caution becomes especially important when the same analytics stack is used to monitor both people and autonomous systems, because mixed accountability can obscure who approved the action, who executed it, and who must remediate it.

Related resources from NHI Mgmt Group

• How should security teams implement DLP for human error, insider risk, and AI-driven data movement?
• How should security teams implement compliance automation when SaaS data protection and AI agent access need to be governed together?
• How should security teams unify human and AI agent risk management across the workforce?
• What breaks when security teams track human and AI agent risk separately?