# Agent & MCP Governance (AGT) Requirements — 9 Workforce AI Security Controls > Govern agents, MCP servers and tool calls with identity, scope and runtime control. 9 vendor evaluation requirements with acceptance criteria, verification tests and framework mappings. Source: Harmonic Security, updated October 2026. 9 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. ## AGT-001: Govern tool calls at read, write and delete scope - Area: Agent & MCP Governance - Verification: Live test - OWASP adoption tier: AT1, AT3, AT4, AT6 - URL: /r/AGT-001 **Acceptance criteria:** Permit a read while refusing write, delete or other destructive actions, with every attempt logged and attributable. **Why it matters:** One agent can read, write and delete in the same workflow. Allow or deny per app is too blunt. **How to verify:** Reads to a connected system are allowed while attempts to change or delete information are blocked. **OWASP adoption context:** Citizen-built, code-executing and MCP-extended workflows can take consequential tool actions, making operation-level permissions relevant. **Mappings:** - NIST CSF 2.0: PR.AA-05; SOC 2: CC6.3; ISO 27001: A.8.3, A.8.15 — Allowing reads while refusing writes, deletes and destructive operations enforces least privilege at the tool-call boundary. Enforce restrictions before the operation and record every attempt with usable attribution, retention, protection and analysis. Warnings or a live view alone are insufficient; runtime refusal does not review or revoke the underlying connector grant. - ISO 42001: A.9.2 — A defined, enforced boundary between permitted reads and prohibited destructive actions implements a concrete responsible-use procedure for agents. It contributes to the wider AI-use process without implying that the standard prescribes these exact API scopes. - OWASP ASI: ASI02, ASI03 — Operation-level refusal limits destructive tool misuse and actions attempted through excessive or misapplied delegated identity. Attributable attempts help investigate those failures; the control covers the operations and tool paths where it is enforced. ## 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-003: Inspect sensitive data retrieved through connectors mid-workflow - Area: Agent & MCP Governance - Verification: Live test - OWASP adoption tier: AT3, AT4, AT6 - URL: /r/AGT-003 **Acceptance criteria:** Detect when an agent picks up sensitive content from one connnected tool and attemps to share it with a separate tool, even if the user prompt was benign. **Why it matters:** Connectors pull sensitive data into a conversation even when the user's question is harmless. **How to verify:** When an agent picks up sensitive information from one tool or dataset and attempts to share it with a different tool, the even is blocked if it violates policy. **OWASP adoption context:** Embedded assistants, integrated platforms, citizen workflows and MCP extensions can retrieve sensitive data after a benign prompt; inspect the returned payload. **Mappings:** - NIST CSF 2.0: PR.DS-02, DE.CM-09; SOC 2: CC6.7, C1.1; ISO 27001: A.8.12 — Inspecting connector payloads reveals sensitive information entering a workflow even when the prompt is benign, supplying runtime evidence for transfer, confidentiality and leakage controls. Detection alone does not restrict later disclosure; finding sensitive content also does not establish poisoned context. SOC 2: C1.1: The Confidentiality category and relevant information must be in scope. ISO/IEC 27001: A.8.12: Operate inspection within a leakage-protection workflow with defined alert triage, warnings, blocking or another protective response. - NIST AI RMF: MEASURE 2.10 — Where retrieved content includes personal data, the findings inform examination of privacy risk within the AI workflow. Recognizing sensitive content is one input to that examination, not a complete privacy-risk assessment. ## 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-006: Discover the MCP servers and connectors employees attach to their AI clients - Area: Agent & MCP Governance - Verification: Live test - OWASP adoption tier: AT3, AT4, AT6 - Formerly: DIS-007 - URL: /r/AGT-006 **Acceptance criteria:** Inventory local and remote MCP servers reached from desktop, IDE and CLI AI tools with owner, scope and exposure. **Why it matters:** MCP-capable clients now ship inside IDEs, terminals and desktop apps, and each connector is a new path to corporate data. **How to verify:** Local and remote MCP servers used by pilot users appear with client, owner, scope and exposure. **OWASP adoption context:** Citizen-built, code-executing and MCP-extended workflows can attach external servers, so connector discovery must reach those integration paths. **Mappings:** - NIST CSF 2.0: GV.SC-04, ID.AM-04; NIST AI RMF: MAP 4.1 — The MCP and connector inventory identifies third-party components and services, with owner, scope and exposure to inform supplier prioritization and component-risk mapping. Discovery alone does not assess their risks. - ISO 42001: A.4.2, A.10.3 — ISO/IEC 42001: The local and remote MCP/connector inventory documents resources relevant to AI activities, including their owner, scope and exposure, supporting A.4.2. External MCP servers and connectors also identify supplier relationships to govern under A.10.3; locally owned servers are not automatically suppliers. Inventory does not establish supplier due diligence or trustworthiness. - OWASP ASI: ASI04 — The inventory exposes external MCP servers and runtime-connected components relevant to agentic supply-chain compromise. It provides a review surface, not evidence that components are trustworthy. - SOC 2: CC2.1, CC9.2; ISO 27001: A.5.9, A.5.19 — Owned connector records supply usable inventory/control information and inputs to supplier-risk review. Keeping the register current does not itself approve a connector or reduce its permissions. ISO/IEC 27001: Maintain usable, owned inventory records. Internally owned servers are not automatically suppliers, and discovery does not assess supplier security. ## AGT-007: Map the actions available via each connector. - Area: Agent & MCP Governance - Verification: Walkthrough - OWASP adoption tier: AT3, AT4, AT6 - Formerly: DIS-008 - URL: /r/AGT-007 **Acceptance criteria:** Show, per connector/MCP server, what actions are available and which are currently enabled. **Why it matters:** Approving a connector without knowing which actions it exposes and which are enabled leaves the scope of available functionality unclear. **How to verify:** For three connectors you name, the console lists the actions each exposes and shows which are currently enabled. **Mappings:** - SOC 2: CC3.2, CC6.3; ISO 27001: Cl. 6.1.2, A.5.18 — An inventory of connector actions and their enabled status supports risk assessment and access-rights review. It provides review inputs; it does not demonstrate effective permissions or their enforcement. - NIST AI RMF: MAP 4.2 — Knowing which actions a connector exposes helps identify risks and control needs associated with third-party components. - OWASP ASI: ASI03 — Reviewing available and enabled actions helps identify unnecessarily broad functionality. Assessing identity and privilege abuse also requires evidence about agent identities, credentials and delegated permissions. These mappings concern action visibility and review, not reachable-file discovery or data-flow mapping. ## AGT-008: Support local and remote MCP gateway placement for employee AI clients - Area: Agent & MCP Governance - Verification: Walkthrough + Documentation - OWASP adoption tier: AT3, AT4, AT6 - Formerly: ARC-005 - URL: /r/AGT-008 **Acceptance criteria:** Support applicable Windows, macOS and Linux patterns, allow endpoint-integrated or remote placement, and define traffic coverage for each. **Why it matters:** Different MCP clients need different gateway placements to be covered. **How to verify:** The vendor shows local and remote MCP gateway placement and documents what each covers. **OWASP adoption context:** Citizen-built, code-executing and MCP-extended workflows motivate local or remote gateway placement; these contexts do not necessarily involve agent-to-agent communication. **Mappings:** - NIST AI RMF: MAP 4.2 — Documented MCP gateway placement identifies where component controls can operate and which traffic they cover. It supplies architecture evidence rather than proof of effective authentication or inspection. - ISO 42001: A.4.5 — Operating-system patterns, local or remote gateways and their dependencies provide computing-resource information for AI deployment. Availability of placement options does not establish secure operation. - OWASP ASI: ASI04 — An MCP gateway’s location and coverage can establish an inspection boundary for runtime-fetched servers and other agentic supply-chain components. Placement alone neither assesses their trustworthiness nor prevents malicious components. ## 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.