How should security teams govern multi-agent AI systems that can query data and update downstream applications?

Why This Matters for Security Teams

Multi-agent AI changes the control problem because each agent can independently query data, chain tools, and trigger updates in downstream applications. That means the risk is no longer limited to model output quality; it includes unauthorized action, hidden escalation paths, and business process abuse. Static role-based permissions are too blunt when the system’s behaviour is goal-driven and runtime-dependent. Current guidance suggests governing these systems as a mix of identity, authorisation, and action control, not as an isolated model deployment.

That shift is reflected in OWASP Top 10 for Agentic Applications 2026 and the NIST AI Risk Management Framework, both of which emphasise context, accountability, and runtime controls. NHIMG research on OWASP Agentic Applications Top 10 also highlights why prompt-level trust is not enough when agents are allowed to act on live systems. In practice, many security teams encounter harmful agent behaviour only after a downstream record is changed or a tool call has already exposed sensitive data, rather than through intentional test coverage.

How It Works in Practice

Effective governance starts by treating each agent as a workload identity with narrowly scoped, short-lived authority. Instead of granting a broad role for the whole system, security teams should issue ephemeral credentials per task, evaluate policy at request time, and require approval for sensitive actions such as record changes, financial approvals, privilege grants, or data exports. This is where intent-based authorisation is emerging: the policy engine evaluates what the agent is trying to do, against which dataset or application, and under what business context.

In practical terms, that means combining real-time policy enforcement with auditable workflow steps. The strongest patterns usually include:

• Workload identity for each agent instance, rather than shared API keys or long-lived service accounts.
• JIT credential provisioning with automatic revocation when a task ends or the agent deviates from expected behaviour.
• Policy-as-code checks, using frameworks such as OPA or Cedar, before tool calls and before downstream writes.
• Approval gates for high-risk actions, especially when an agent can update production systems or customer-facing records.
• Immutable logs that tie every decision to the agent, the policy decision, the business purpose, and the resulting change.

This aligns with the threat modelling direction in the CSA MAESTRO agentic AI threat modelling framework and NHIMG analysis of the Amazon Q AI Coding Agent Compromised, where tool access became the real control surface. The same logic applies to data-query agents described in CoPhish OAuth Token Theft via Copilot Studio. These controls tend to break down when multiple agents share credentials or when downstream applications accept writes without separate authorization checks.

Common Variations and Edge Cases

Tighter agent controls often increase latency and operational overhead, requiring organisations to balance speed against assurance. That tradeoff is especially visible in high-volume environments where many low-risk actions happen per minute, and a human approval step would create unacceptable friction. Current guidance suggests using risk tiers: low-risk read actions can be auto-approved under strict policy, while write actions, cross-system joins, and privilege changes should trigger stronger controls.

There is no universal standard for this yet, but best practice is evolving around containment and context. For example, a research agent that only queries internal knowledge sources may need lighter controls than an operational agent that can update CRM records or open support cases. Teams should also assume that static perimeter thinking fails when agents can chain tools in unpredictable sequences; once one tool is compromised, the agent may be steered into lateral movement or unauthorized disclosure. The State of Non-Human Identity Security report shows how often organisations still lack visibility and confidence in NHI control, which is exactly the gap multi-agent systems amplify. Practitioner experience suggests that the hardest failures appear when an agent inherits access from a human workflow and then operates faster than the control owner can notice.

Related resources from NHI Mgmt Group

• How should security teams govern AI agents that can access enterprise systems?
• How should security teams govern machine identity credentials in agentic AI environments?
• How should security teams govern AI agents that use OAuth access?
• How should security teams limit the risk from AI agents that have access to production systems?