AI agents complicate security because they can make decisions, invoke tools, and move between systems without direct human intervention. That increases the chance of credential misuse, unintended reach, and lateral movement if guardrails are weak. The core issue is not whether the agent exists, but whether its permissions, isolation, and approvals are tight enough for the task at hand.
Why This Matters for Security Teams
AI agents are not just another automation layer. They can choose actions, chain tool calls, and operate across cloud, SaaS, and identity systems with enough autonomy to create a containment problem rather than a simple access problem. That shifts risk from a single compromised account to a wider trust boundary that includes prompts, tools, policies, approvals, and the data the agent can reach. Guidance from the NIST AI Risk Management Framework is useful here because it treats AI risk as a governance and lifecycle issue, not only a model issue.
The practical concern is that an agent often sits between human intent and machine execution. If its permissions are broader than the task, the agent can become a force multiplier for accidental exposure or deliberate abuse. In cloud and identity environments, that means secrets, tokens, delegated access, and approval workflows must be treated as attack surfaces, not implementation details. The same is true when agents call identity providers, ticketing systems, CI/CD pipelines, or data stores.
In practice, many security teams encounter agent risk only after an agent has already overreached into systems it was never meant to touch, rather than through intentional design review.
How It Works in Practice
Containment starts with limiting what the agent can see, decide, and execute. Best practice is evolving, but the baseline is clear: every agent should have a defined purpose, a narrow toolset, explicit approval thresholds, and short-lived credentials that are isolated from human admin accounts. The OWASP Agentic AI Top 10 is especially helpful for mapping failure modes such as excessive agency, prompt injection, insecure tool use, and over-trusted outputs.
In operational terms, teams should separate the agent identity from the operator identity and from service identities used by backend systems. That usually means:
- issuing a distinct non-human identity for each agent or agent function, not sharing a generic service account;
- scoping permissions to a single workflow, environment, or tenant boundary;
- requiring step-up approval for irreversible actions such as deleting resources, changing access, or moving secrets;
- logging every tool invocation, external retrieval, and policy override for later review;
- validating outputs before execution when the action could affect identity, money, or production systems.
Threat modeling should include both model-side and environment-side abuse. The MITRE ATLAS adversarial AI threat matrix helps teams think about prompt injection, data poisoning, and malicious instruction following, while the CSA MAESTRO agentic AI threat modeling framework is useful for reasoning about tool chains and orchestration paths. For cloud control alignment, the NIST Cybersecurity Framework 2.0 remains a strong anchor for asset visibility, protection, detection, and response.
These controls tend to break down when agents are embedded in shared production automation platforms because inherited permissions, hidden API paths, and overlapping service accounts make isolation difficult.
Common Variations and Edge Cases
Tighter containment often increases friction, requiring organisations to balance agent usefulness against approval latency and operational overhead. That tradeoff becomes sharper when an agent is expected to act in real time, such as triaging alerts, updating tickets, or handling customer support workflows.
There is no universal standard for this yet, especially for multi-agent systems and cross-domain orchestration. Current guidance suggests treating high-impact actions differently from low-risk retrieval or summarisation tasks. A read-only research agent can tolerate broader content access than an agent that can create users, rotate secrets, or trigger deployment jobs. Likewise, an agent that operates inside a sandbox is materially easier to contain than one with direct access to a production cloud control plane.
The biggest edge cases appear when identity and AI boundaries blur. If an agent can request its own credentials, refresh tokens, or delegated grants, the trust model starts to resemble privilege escalation. That is why many teams now combine AI governance with identity governance: approvals, just-in-time access, and periodic review of agent entitlements. The NIST AI Risk Management Framework and the NIST Cybersecurity Framework 2.0 are most effective when used together, because the first addresses AI risk governance and the second anchors control operations.
Where the agent touches regulated data, financial operations, or customer identity workflows, the acceptable blast radius is much smaller. In those environments, the right answer is often not more autonomy, but a narrower action set, stronger human approval, and explicit containment of every credential the agent can use.
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 OWASP Non-Human Identity Top 10 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 |
|---|---|---|
| OWASP Agentic AI Top 10 | Agentic app threats map directly to prompt, tool, and autonomy risks. | |
| NIST AI RMF | AI RMF frames governance for autonomy, trust, and operational risk. | |
| MITRE ATLAS | ATLAS covers adversarial attacks against models, prompts, and AI workflows. | |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access is central to containing agent reach. |
| OWASP Non-Human Identity Top 10 | Agent identities, tokens, and secrets behave like non-human identities. |
Use OWASP agentic controls to limit tool access, validate outputs, and constrain agent actions.
