CSPM focuses on infrastructure settings and DSPM focuses on data visibility, but AI agents change behaviour through prompts, tools, and memory. That means the risk can appear at runtime even when cloud and data posture look clean. Organisations need controls that govern how the agent acts, not just where it runs or what data it stores.
Why This Matters for Security Teams
CSPM and DSPM are essential, but they describe posture rather than behaviour. That distinction matters because AI agents can make new decisions at runtime, call tools, chain prompts, and retain context in ways that alter risk after deployment. The control gap is not only about misconfiguration or exposed data; it is about whether the agent is authorised to act as intended under pressure, deception, or malformed input.
Security teams that rely on cloud settings and data classification alone often miss abuse paths such as tool injection, excessive autonomy, unsafe retrieval, and uncontrolled action propagation. Current guidance from the NIST AI Risk Management Framework and the OWASP Agentic AI Top 10 treats these as governance and lifecycle risks, not just infrastructure hygiene. That is a useful shift: the agent itself becomes part of the attack surface.
In practice, many security teams encounter agent abuse only after a workflow has already approved, exfiltrated, or modified something it should never have touched, rather than through intentional design of the agent’s operating boundaries.
How It Works in Practice
AI agents introduce a control plane that CSPM and DSPM do not inspect deeply enough. CSPM can tell you whether the cloud account, network, or storage layer is configured correctly. DSPM can tell you whether sensitive data exists, where it is stored, and sometimes how it is shared. Neither tool fully answers whether an agent can be manipulated into taking an unsafe action using allowed credentials, reachable tools, or trusted memory.
Operationally, the main risk channels are prompts, tool use, retrieval, memory, and execution scope. A malicious instruction can be embedded in user input, retrieved content, an email, a ticket, or a web page. If the agent has excessive tool permissions, it may perform actions that look legitimate at the platform layer but are unsafe in context. That is why agent controls need policy, approval, and traceability, not only posture checks.
- Restrict tool access to the minimum set needed for the use case.
- Separate read-only from write-capable actions and require step-up approval for sensitive changes.
- Log prompts, tool calls, retrieved sources, and final actions so investigations can reconstruct intent and execution.
- Validate outputs before they are used to send messages, change records, move money, or trigger downstream workflows.
- Test for prompt injection, indirect prompt injection, and unsafe tool chaining as part of assurance.
Frameworks such as the MITRE ATLAS adversarial AI threat matrix and the CSA MAESTRO agentic AI threat modeling framework are useful because they focus on how adversaries actually influence model-driven systems, including manipulation of inputs, dependencies, and decision paths. They complement CSPM and DSPM by covering runtime behaviour, not just asset state. These controls tend to break down in highly interconnected environments where one agent can invoke many downstream services because permission sprawl and ambiguous ownership make safe boundaries hard to enforce.
Common Variations and Edge Cases
Tighter agent controls often increase operational overhead, requiring organisations to balance automation speed against approval friction, monitoring cost, and user experience. That tradeoff is real, especially in customer support, developer tooling, and security operations where agent speed is part of the value proposition.
Best practice is evolving for agent memory, long-running tasks, and multi-agent coordination. There is no universal standard for this yet, so organisations should treat these areas as higher uncertainty until policies, logging, and rollback controls are mature. A common edge case is an agent that appears harmless in a single session but becomes risky when memory persists across sessions or when tool outputs are reused by another system without review.
Another gap appears when identity and privilege are handled as if the agent were a normal application account. In reality, agentic systems often need explicit governance over non-human identity, delegated authority, and just-in-time access boundaries. That is where the identity bridge becomes important: the agent may be running in a clean cloud environment with well-classified data, yet still operate with excessive authority because its action rights are wider than its infrastructure footprint suggests. For more on that governance layer, the NIST Cybersecurity Framework 2.0 remains useful for accountability, while CSPM and DSPM should be treated as supporting controls rather than complete coverage.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10, MITRE ATLAS and CSA MAESTRO address the attack and risk surface, while NIST AI RMF and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST AI RMF | AI RMF addresses governance and lifecycle risk beyond cloud and data posture. | |
| OWASP Agentic AI Top 10 | Agentic AI threats include prompt injection, tool abuse, and unsafe autonomy. | |
| MITRE ATLAS | ATLAS models adversarial techniques that influence AI system behaviour. | |
| NIST CSF 2.0 | PR.AA-05 | Agent authority and access governance fit CSF accountability and access controls. |
| CSA MAESTRO | MAESTRO targets threat modeling for agentic AI workflows and execution paths. |
Limit agent privilege, track delegated actions, and verify approvals for sensitive operations.
