# AI Detection & Response (AIDR) Requirements — 10 Workforce AI Security Controls > Detect risky AI behavior, investigate incidents and respond with full context. 10 vendor evaluation requirements with acceptance criteria, verification tests and framework mappings. Source: Harmonic Security, updated October 2026. 10 requirements. Disclaimer: Mappings indicate relevant contributions, not complete compliance, certification, assurance, a conformity assessment or legal advice. Read each explanation and its scope conditions. Legal applicability depends on jurisdiction, role, use and effective dates. Reference summaries are selective; consult current official sources and full licensed standards before relying on them. ## GRD-016: Explain each decision to the employee and the analyst - Area: Runtime Guardrails - Verification: Live test - OWASP adoption tier: AT0–AT4 - Formerly: DAT-020 - URL: /r/GRD-016 **Acceptance criteria:** Show which detection or policy triggered and highlight the content that caused it, both in the employee's coaching message and in the analyst's alert, so the employee can fix the prompt and the analyst can confirm the decision without opening another tool. **Why it matters:** Explaining the trigger lets the employee fix the prompt and the analyst confirm the decision, which cuts tickets on both sides. **How to verify:** The coaching message and the alert both show the detection that fired and highlight the content. **OWASP adoption context:** Employees and analysts meet these decisions in every listed context, so explanations should appear wherever the intervention does. **Mappings:** - NIST CSF 2.0: DE.AE-02, PR.AT-01; SOC 2: CC2.2, CC7.3; ISO 27001: A.5.25, A.6.3 — Naming the trigger and the content behind it gives analysts what they need to evaluate an event and gives employees specific, in-context awareness of the policy. Explanations must not expose more sensitive content than the viewer is entitled to see. - NIST AI RMF: MEASURE 2.9; ISO 42001: A.8.2 — Showing why a detection fired explains the control's output to the people it affects and documents how the decision was reached. It explains the decision, not the internal workings of the detection model. ## IDR-001: Generate actionable alerts - Area: AI Detection & Response - Verification: Live test - OWASP adoption tier: AT0–AT4 - Formerly: DAT-006 - URL: /r/IDR-001 **Acceptance criteria:** Include tool, account type, detection type, policy, action, timestamp, and user or team context. **Why it matters:** An alert the SOC cannot act on is noise. The fields decide whether triage takes seconds or a ticket. **How to verify:** Pilot alerts carry every listed field and can be triaged without opening another console. **OWASP adoption context:** Alerts need enough context to identify the originating employee AI workflow across the listed adoption settings, without unnecessarily reproducing sensitive content. **Mappings:** - NIST CSF 2.0: DE.AE-02, DE.AE-06 — Tool, account, policy, action, time and user context provide adverse-event analysis evidence and information suitable for authorized responders. An alert must actually reach the appropriate staff or tools; generation alone does not perform analysis. - ISO 42001: A.6.2.8 — The contextual alert supplies an AI event record describing what was detected and what action occurred. Wider logging arrangements, including retention and protection, remain necessary. - SOC 2: CC7.2, CC7.3; ISO 27001: A.8.15, A.5.25 — Context-rich alerts create an event trail and evidence for anomaly monitoring and incident triage. Determining incident significance, assigning ownership and responding require an operated review process. ISO/IEC 27001: A.8.15: Keep attributable event records with appropriate retention, protection and analysis; a live view alone is insufficient. ## IDR-002: Detect direct and indirect prompt injection attempts. - Area: AI Detection & Response - Verification: Live test - OWASP adoption tier: AT0–AT4 - Formerly: DAT-014 - URL: /r/IDR-002 **Acceptance criteria:** Identify, block, and flag prompt injection attempts, whether directly entered into the AI tool or read via connections to third-party tools. **Why it matters:** Successful prompt injection can lead to sensitive data exfiltration or irreversible destructive agent actions. **How to verify:** Prompt injection attempts via user input or connected tools are detected and logged with evidence. **OWASP adoption context:** Jailbreak and misuse attempts can occur in any of the listed employee AI contexts; the tiers do not imply identical detection coverage. **Mappings:** - NIST CSF 2.0: DE.AE-02, DE.CM-09; SOC 2: CC7.2; ISO 27001: A.8.16, A.5.25 — Evidence of jailbreak, bypass and misuse attempts supports adverse-event analysis, security monitoring and event triage. A prompt attack is not automatically malware, and detection does not guarantee blocking. ISO/IEC 27001: A.8.16: Demonstrate analysis of anomalous or risky behavior beyond usage collection. Validate surface coverage, known gaps and false positives, with an event-assessment and response process. - NIST AI RMF: MEASURE 3.1; ISO 42001: A.6.2.6 — Detection evidence, tested coverage and known gaps support continuing identification of AI risks and operational monitoring. Findings must feed an ongoing tracking and review process; a detector alone does not establish that process. ## IDR-003: Identify use cases leading to elevated risk behavior. - Area: AI Detection & Response - Verification: Proof of value - OWASP adoption tier: AT0–AT4 - Formerly: VAL-005 - URL: /r/IDR-003 **Acceptance criteria:** Surface the use cases and teams that require additional training on safe usage principles. **Why it matters:** Repeat exposure and under-use point to where risk reduction or enablement will pay off. **How to verify:** High-risk use cases and the associated users are identified in a pilot. **OWASP adoption context:** Risky use and repeat exposure patterns can appear across the listed employee AI settings; low use is not itself proof of risk or failure. **Mappings:** - NIST CSF 2.0: DE.CM-03; NIST AI RMF: MEASURE 3.1; SOC 2: CC7.2; ISO 27001: Cl. 9.1, A.8.16 — Team-level risky-use and recurring-exposure patterns provide findings for usage monitoring, AI-risk tracking and evaluation against responsible-use/security objectives. Under-use alone is an enablement signal rather than a security anomaly; assessment and intervention remain necessary beyond surfacing patterns. ISO/IEC 27001: Confirm the need for monitoring and choose the interventions to apply. - ISO 42001: A.6.2.6 — Observed risky-use and recurring-exposure patterns provide ongoing operational-monitoring findings for in-scope AI systems or controls. Under-use alone is an enablement signal; surfacing patterns does not establish responsible-use objectives or complete assessment and intervention. ## IDR-004: Integrate with SIEM, SOAR, ticketing, and identity systems - Area: AI Detection & Response - Verification: Live test - OWASP adoption tier: AT0–AT4 - Formerly: GOV-003 - URL: /r/IDR-004 **Acceptance criteria:** Use webhooks or APIs to consume relevant employee identity context and to push alerts into logging and response systems. **Why it matters:** Security alerts need relevant context and need to stream to centralized repositories. **How to verify:** Pilot events can be enriched with employee identity context and streamed to your SIEM. **OWASP adoption context:** Operational integration with security, identity and service-management systems is a cross-tier governance capability. **Mappings:** - NIST CSF 2.0: DE.AE-06; SOC 2: CC7.3, CC7.4 — Structured webhooks and APIs can route adverse-event evidence into authorized staff’s monitoring, triage and incident-response workflows. A connector contributes only when delivery, ingestion, successful processing and the associated operational workflow are configured and exercised; it does not itself establish incident decisions or response ownership. - NIST AI RMF: GOVERN 4.3 — Feeding AI events into enterprise incident, ticket and evidence workflows enables organizational information sharing about AI issues. The connected teams still need to operate the associated reporting and response practices. - ISO 27001: A.5.25, A.8.15 — Structured telemetry and incident-ticket integration supply logging, analysis and event-triage inputs. Demonstrate delivery, ingestion, successful processing, correlation and triage routing. An endpoint alone does not establish incident decisions, response ownership or completed response. ## AGT-002: Flag destructive, over-scoped or anomalous agent actions - Area: Agent & MCP Governance - Verification: Live test - OWASP adoption tier: AT3, AT4, AT6 - URL: /r/AGT-002 **Acceptance criteria:** Detect excessive permissions, unexpected tools, destructive operations, abnormal call sequences and policy bypass. **Why it matters:** Destructive or unusual agent actions are often the first sign of a hijacked or misconfigured agent. **How to verify:** A destructive or out-of-pattern tool call in the pilot is flagged with context. **OWASP adoption context:** The listed connected-agent contexts can produce abnormal tool sequences, excessive scope or destructive operations that ordinary prompt inspection may miss. **Mappings:** - NIST CSF 2.0: DE.AE-02, DE.CM-09; ISO 42001: A.6.2.6; SOC 2: CC7.2, CC6.3; ISO 27001: A.8.16, A.5.18 — Detecting destructive operations, unexpected tools, abnormal call sequences and policy bypass supplies adverse-event analysis and monitoring of agent behavior. Excess-permission findings also inform access-right review; detection does not prevent an operation or reduce its permissions. ISO/IEC 27001: A.8.16: Event assessment and response remain wider dependencies; test false-positive and response handling. - NIST AI RMF: MANAGE 4.1 — Runtime findings supply the monitoring and evaluation component of post-deployment risk management. A detection capability alone does not establish the wider plan for user input, incident response, recovery and change management. - OWASP ASI: ASI02, ASI03, ASI10 — Destructive calls and excessive permissions expose tool-misuse and identity-abuse patterns; abnormal sequences and policy bypass can also flag rogue-agent behavior. These are indicators for investigation, rather than proof that every anomalous agent is compromised or that the behavior is contained. ## AGT-004: Attribute every connector and tool call alert to a person - Area: Agent & MCP Governance - Verification: Live test - OWASP adoption tier: AT3, AT4, AT6 - URL: /r/AGT-004 **Acceptance criteria:** Answer which server and tool were called, by whom, using which identity, every time an alert or intervention fires. **Why it matters:** Without attribution, an agent action cannot be investigated or tied to accountability. **How to verify:** Every pilot tool call alert shows the tool used, the surface, the user identity, and the result. **OWASP adoption context:** The listed connected-agent contexts need an identity chain from the employee to the server and tool call, including the delegated identity actually used. **Mappings:** - SOC 2: CC2.1, CC7.2 — Linking the person, execution identity, server, tool, scope and result supplies usable information for correlating calls and reviewing identity use. It can reveal gaps between human and delegated identities; attribution alone does not authenticate the caller, manage the identity lifecycle or authorize the operation. - ISO 42001: A.6.2.8; ISO 27001: A.8.15 — The person-to-identity-to-tool chain supplies attribution needed for AI event records and an audit trail. Answering those questions does not by itself require persistent protected logs, and the chain must preserve the distinction between the person and any service or delegated identity. ISO/IEC 27001: Human attribution must not expose credential values. - OWASP ASI: ASI03 — Visible identity and scope relationships help investigate inherited-identity abuse, excessive delegation and confused-deputy behavior. Attribution exposes how authority was used; it does not itself stop an unauthorized call. - NIST CSF 2.0: DE.AE-03 — Joining the person, execution identity, server, tool, scope and result supports event correlation. Attribution does not authenticate the caller, manage identity lifecycles or authorize the operation. ## AGT-005: Provide targeted containment for a single connector or tool. - Area: Agent & MCP Governance - Verification: Live test - OWASP adoption tier: AT1, AT2, AT3, AT6 - URL: /r/AGT-005 **Acceptance criteria:** Disable or revoke one connector, tool, plugin, or integration for a user or group without switching off the whole AI tool. **Why it matters:** When one connector misbehaves, switching off the whole AI tool punishes everyone. **How to verify:** One connector is disabled for one pilot group while the AI tool keeps working. **OWASP adoption context:** The listed agent contexts may share an AI client across multiple connectors, making targeted revocation preferable to disabling the whole tool when feasible. **Mappings:** - NIST CSF 2.0: RS.MI-01, RS.MI-02; SOC 2: CC6.3, CC7.4; ISO 27001: A.5.26, A.5.18 — Disabling an affected connector or revoking its token removes a specific access path and supplies an incident-containment action. It contributes to eradication only where it removes the compromised access mechanism; containment alone does not establish complete eradication or incident response. ISO/IEC 27001: A.5.26: Integrate containment into the buyer’s incident process. A.5.18: Review effective access and adjust or revoke it where required; cached access and in-flight actions may survive revocation. - NIST AI RMF: MANAGE 2.4; ISO 42001: A.6.2.6 — A targeted disablement mechanism enables disengagement of an unsafe AI dependency while other functions remain available. It contributes to operational response, but the capability alone does not establish who has authority to invoke it or a complete operational-support process. - OWASP ASI: ASI08 — Isolating a connector, tool or token can interrupt propagation through an agent workflow, matching the isolation and circuit-breaker approach to cascading failures. The scope and timing of disablement determine which downstream actions it can contain. ## AGT-009: Detect indirect prompt injection in content agents read - Area: Agent & MCP Governance - Verification: Live test - OWASP adoption tier: AT3, AT4, AT6 - Formerly: DAT-014 - URL: /r/AGT-009 **Acceptance criteria:** Identify malicious instructions from the sources that AI systems are able to read from. Name the originating connector or source, respond before the agent acts where configured, and demonstrate tested coverage and known gaps. **Why it matters:** A poisoned tool response can turn a trusted agent into an attacker's tool while the user's prompt looks harmless. **How to verify:** Injected instructions in content returned to pilot users' agents are detected and attributed to their source. **OWASP adoption context:** Indirect injection enters through connected-agent workflows and retrieved content; the listed tiers do not imply identical detection coverage. **Mappings:** - NIST CSF 2.0: DE.AE-02, DE.CM-09; SOC 2: CC7.2; ISO 27001: A.8.16, A.5.25 — Evidence and source attribution for injection, jailbreak and bypass behavior support adverse-event analysis, security monitoring and event triage. Test connector responses, retrieved content and tool outputs even with benign user prompts; prompt injection is not automatically malware, and detection does not guarantee blocking or constitute malware prevention. ISO/IEC 27001: A.8.16: Demonstrate analysis of anomalous or risky behavior beyond usage collection. Validate surface coverage, known gaps and false positives, with an event-assessment and response process. - NIST AI RMF: MEASURE 3.1; ISO 42001: A.6.2.6 — Detection evidence, originating sources, tested coverage and known gaps support continuing identification of AI risks and operational monitoring. Findings must feed an ongoing tracking and review process; a detector alone does not establish that process. - OWASP ASI: ASI01, ASI06 — Direct and indirect malicious instructions can hijack agent goals under ASI01. ASI06 applies when content poisons retained or retrievable context; a malicious connector response is not automatically memory poisoning. Detection coverage must be demonstrated, and blocking is not guaranteed. ## AUD-001: Keep a configurable record of each conversation - Area: Audit & Evidence - Verification: Walkthrough - OWASP adoption tier: Tier-independent - Formerly: GOV-014 - URL: /r/AUD-001 **Acceptance criteria:** Record the prompts, responses, uploaded files and tool calls that make up each conversation, with content capture set per policy: full, partial, metadata-only or none, in line with privacy and retention rules. **Why it matters:** The conversation, not the single prompt, is the unit an investigator or auditor needs to see. **How to verify:** Show one pilot conversation's record at full, partial and metadata-only capture settings. **OWASP adoption context:** Logging-depth choices apply across adoption tiers, balancing needed evidence against data minimization and any applicable retention rule. **Mappings:** - NIST CSF 2.0: PR.PS-04; ISO 42001: A.6.2.8; SOC 2: CC7.2, P3.1, P4.2 — Selectable prompt/response capture provides AI/security logging evidence while letting privacy and retention policy constrain content depth. The buyer must test that each chosen mode preserves needed event metadata; capture configuration alone establishes neither log integrity nor an adequate monitoring and retention process. SOC 2: P3.1/P4.2 require the Privacy category and relevant information in scope. - NIST AI RMF: MEASURE 2.8 — Choosing and documenting content depth can supply evidence for evaluating transparency and accountability alongside privacy trade-offs. A configuration option alone does not establish the evaluation or its adequacy. - ISO 27001: A.8.15, A.5.34 — Configurable prompt and response capture supports logging design and privacy minimization. Preserve needed event metadata, usable attribution and appropriate retention, protection and analysis even when content capture is disabled. Capture-depth options alone establish neither log integrity, record protection nor lawful monitoring.