← Mitigation · m-identity-monitoring

EVIDENCE TRAIL

Identity behaviour monitoring — UEBA for agent identities

Verbatim excerpts from the upstream sources cited on the mitigation page, with what each source does and does not prove. The control's core claim — that behavioural baselining of agent identities detects T9 Identity Spoofing — is stated verbatim in OWASP Agentic AI v1.1 §T9 and Playbook 4. NIST 800-207 §5.7 frames the agent-impersonation risk; NIST 800-53 SI-4 / AU-12 supply the control-family basis; ATLAS AML.M0024 is the direct cross-reference.

Last cross-checked against upstream sources: · 7 sources

References

Each entry shows what the source supports and what it does not prove.

Reference 1
v1.1 · published December 2025

OWASP Agentic AI — Threats & Mitigations v1.1

§T9 Identity Spoofing & Impersonation — Mitigations column

"Develop comprehensive identity validation frameworks, enforce trust boundaries, least privilege access and deploy continuous monitoring to detect impersonation attempts. Use behavioral profiling, involving a second model, to detect deviations in AI agent activity that may indicate identity spoofing."

Supports: Verbatim naming of "continuous monitoring" and "behavioral profiling … to detect deviations in AI agent activity" as the primary mitigations for T9. This is the direct upstream citation for the control's scope and rationale.

Does not prove: Does not specify which behavioural signals to baseline (workload origin, resource-mix, time-of-day, auth-failure rate). Helmwart operationalises those four detection classes from the broader literature. "A second model" as the profiling mechanism is one implementation option; SIEM-based UEBA is equally valid.

Reference 2
v1.1 · published December 2025

OWASP Agentic AI — Playbook 4: Strengthening Authentication, Identity & Privilege Controls

Playbook 4 — §Step 3: Detect & Block AI Impersonation Attempts (Detective)

"Implement identity deviation monitoring, flagging cases where an AI agent's behavior does not match its historical activity. … Correlate AI identity validation with historical access trends. Compare authentication attempts against past access logs to detect suspicious deviations."

Supports: Names "identity deviation monitoring" against "historical activity" as a detective step — the exact UEBA-for-agents pattern this control implements. Confirms baseline-vs-current-behaviour comparison as the detection mechanism.

Does not prove: Playbook language is guidance, not a mandatory standard. Does not specify statistical thresholds or alert latency targets. "Historical access logs" as the baseline source is one path; cloud-native anomaly detection (GuardDuty, Entra ID Protection) is an equivalent.

Reference 3
Rev 5 · published September 2020; updated August 2025

NIST SP 800-53 Rev 5 — SI-4 System Monitoring

SI-4 — Supplemental Guidance (NIST SP 800-53 Rev 5 OSCAL catalog)

"System monitoring includes external and internal monitoring. … Organizations monitor systems by observing audit activities in real time or by observing other system aspects such as access patterns, characteristics of access, and other actions."

Supports: Establishes per-principal monitoring of "access patterns" and "characteristics of access" as a baseline security control. This is the direct control-family basis for agent identity behavioural monitoring; applying SI-4 to NHI/agent identities is a conforming extension.

Does not prove: SI-4 does not name agents, non-human identities, or UEBA by name. The control family is written for enterprise IT systems; Helmwart extends the pattern to AI agent identities.

Reference 4
Rev 5 · published September 2020; updated August 2025

NIST SP 800-53 Rev 5 — AU-12 Audit Record Generation

AU-12 — Control Statement (NIST SP 800-53 Rev 5 OSCAL catalog)

"Provide audit record generation capability for the event types the system is capable of auditing … Allow [designated personnel or roles] to select the event types that are to be logged by specific components of the system; and generate audit records for the event types defined in [AU-2c] that include the audit record content defined in [AU-3]."

Supports: Mandates per-component audit record generation — the telemetry foundation that UEBA-for-agents consumes. Without AU-12 compliance there is no signal stream to baseline.

Does not prove: AU-12 is a logging mandate, not a detection control. It does not specify baseline computation, deviation scoring, or alerting. The UEBA-layer sits on top of the telemetry AU-12 requires.

Reference 5
Published August 2020

NIST SP 800-207 — Zero Trust Architecture

§2 — Zero Trust Architecture Tenets, Tenet 5 (continuous monitoring and validation)

"An enterprise implementing a ZTA should establish a continuous diagnostics and mitigation (CDM) or similar system to monitor the state of devices and applications and should apply patches/fixes as needed. Assets that are discovered to be subverted, have known vulnerabilities, and/or are not managed by the enterprise may be treated differently (including denial of all connections to enterprise resources) than devices owned by or associated with the enterprise that are deemed to be in their most secure state."

Supports: Names continuous diagnostics and mitigation as a ZTA architectural requirement. Agent identities are enterprise assets; continuous state-monitoring of their behaviour is the ZTA-conforming implementation path.

Does not prove: The CDM tenet is framed around device and application state, not per-identity behavioural baselines. NIST 800-207 does not name UEBA or agent identity monitoring specifically. Section 5.7 (NPE) raises the identity-authentication problem for software agents but does not resolve it with UEBA.

Reference 6
Published August 2020

NIST SP 800-207 — Zero Trust Architecture §5.7 Non-person Entities

§5.7 Use of Non-person Entities (NPE) in ZTA Administration

"There is also a risk that an attacker could gain access to a software agent's credentials and impersonate the agent when performing tasks. … The associated risk is that an attacker will be able to induce or coerce an NPE to perform some task that the attacker is not privileged to perform. The software agent may have a lower bar for authentication (e.g., API key versus MFA) to perform administrative or security-related tasks compared with a human user."

Supports: Names credential-theft and agent impersonation as open risks in ZTA — the exact threat class (OWASP T9 / AML.T0012) that identity behaviour monitoring is designed to detect. Confirms that agent identities require dedicated monitoring beyond standard human-user controls.

Does not prove: Section 5.7 identifies the risk but does not mandate UEBA as the countermeasure. The document notes this is "an open issue." Helmwart resolves the gap with behavioural baselining.

Reference 7
ATLAS v5.6.0 (continuously updated)

MITRE ATLAS AML.M0024 — AI Telemetry Logging

No verbatim excerpt pulled yet — open the original to verify the cited section.

Supports: Names logging of AI model inputs, outputs, and reasoning steps as a mitigation so "anomalous behaviour can be detected and incidents reconstructed." This is the telemetry layer that feeds the UEBA baseline; AML.M0024 is the direct ATLAS cross-reference for this control.

Does not prove: AML.M0024 is a logging mitigation, not a detection mitigation. It does not specify baseline computation or deviation alerting. The UEBA layer sits above what AML.M0024 requires.