Because many controls stop at the boundary of the model, the cluster, or the policy engine. AI agents can accept a prompt, choose a tool, and act inside the workload at runtime, so teams need both declared access control and observed behaviour monitoring to understand what the agent actually did.
Why This Matters for Security Teams
AI agents change the control problem because they do not just generate content, they can execute actions through tools, APIs, and workflows. That means classic cloud controls can still be “correct” while the agent’s runtime behaviour remains opaque. The gap is not usually a missing firewall or a weak IAM policy in isolation; it is the absence of continuous visibility into intent, tool selection, and post-prompt execution.
Security teams often assume the model boundary is the main risk boundary. Current guidance from the OWASP Agentic AI Top 10 and the NIST AI Risk Management Framework points to a broader view: agentic systems need governance, observability, and abuse-resistant execution paths, not just model safety controls. If a cloud platform only validates service identity at deployment time, it will miss prompt-influenced actions that occur later, inside live sessions or chained workflows.
In practice, many security teams encounter agent risk only after an unexpected data access event or an automated workflow has already chained through trusted services.
How It Works in Practice
Agentic AI creates gaps because the agent often sits between policy and action. A prompt can trigger a plan, the plan can invoke a tool, and the tool can touch data or services that the original cloud control never considered user-facing. That breaks the assumption that every privileged action maps neatly to a human session, a static role, or a pre-approved CI/CD path.
In practice, defenders need to look at four layers together:
- who or what is allowed to invoke the agent
- which tools, connectors, and secrets the agent can reach
- what the agent actually did at runtime
- how those actions are logged, reviewed, and revoked
That is why frameworks such as the MITRE ATLAS adversarial AI threat matrix and the CSA MAESTRO agentic AI threat modeling framework are useful. They help teams reason about prompt injection, tool misuse, memory poisoning, indirect instruction capture, and downstream abuse of credentials. The practical control pattern is to combine least privilege, scoped tokens, tool allowlisting, runtime policy checks, and detailed telemetry that can distinguish a legitimate agent action from an attacker-influenced one.
This also means secrets management matters more than many teams expect. If an agent can retrieve credentials, tokens, or certificates on demand, then a cloud security review has to include token lifetime, audience restriction, and session-level auditability. Controls mapped only to workload identity or container admission do not fully address the risk.
These controls tend to break down when agents are allowed to chain across SaaS apps, internal APIs, and data stores because each hop inherits trust without re-evaluating the original prompt context.
Common Variations and Edge Cases
Tighter agent controls often increase friction for product and operations teams, requiring organisations to balance autonomy against containment. That tradeoff is real: every added approval step or tool restriction can reduce agility, but it can also stop an agent from taking irreversible actions based on a manipulated prompt.
Best practice is evolving for multi-agent workflows, shared memory stores, and long-running agents. There is no universal standard for this yet, so teams should treat these as higher-risk patterns and validate them more aggressively than single-turn assistants. The OWASP Top 10 for Agentic Applications 2026 is especially relevant where an agent can self-select tools or persist state across sessions, while the NIST SP 800-53 Rev 5 Security and Privacy Controls remains useful for mapping classical control families to access, logging, and accountability requirements.
Edge cases appear when the agent operates inside regulated data flows, uses third-party plugins, or makes decisions based on retrieved content that may not be trustworthy. In those environments, the safest design is often to constrain the agent to recommendations, require explicit human approval for high-impact actions, and continuously compare declared permissions against observed behaviour. Where that comparison is missing, cloud controls can look complete on paper while the agent silently expands the effective attack surface.
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 and MITRE ATLAS address the attack and risk surface, while NIST AI RMF, NIST CSF 2.0 and NIST AI 600-1 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | Agentic risks like tool misuse and prompt injection are central to the question. | |
| NIST AI RMF | AI RMF frames governance, mapping, measurement, and management for agent risk. | |
| MITRE ATLAS | ATLAS covers adversarial techniques against models and agent workflows. | |
| NIST CSF 2.0 | PR.AA-01 | Identity and access controls must extend to agent tool use and runtime actions. |
| NIST AI 600-1 | GenAI profiles help translate AI-specific risks into operational controls. |
Use AI RMF to define ownership, assess agent harms, and measure control effectiveness continuously.
