What breaks is the control model around access. Security teams may focus on hallucinations or model choice while missing the real exposure in SaaS identities, connected APIs, and data sharing paths. The result is unmanaged reach, weak accountability, and AI actions that look authorised but were never formally reviewed.
Why This Matters for Security Teams
When organisations treat AI risk as a model-quality problem, they miss the control plane where the real exposure lives: identities, authorisation, connected SaaS tools, and data-sharing paths. A safer model can still trigger unsafe actions if it has broad access, weak segregation, or persistent credentials. That is why the issue shows up as an identity and access problem first, and a model problem second.
The pattern is visible in non-human identity research: NHIMG’s 2024 ESG Report: Managing Non-Human Identities found that 72% of organisations have experienced or suspect a breach of NHIs, which underlines how often machine access becomes the attack path. For AI governance, NIST’s NIST AI Risk Management Framework is useful precisely because it pushes teams beyond model accuracy into govern, map, measure, and manage activities that include deployment context and operational controls.
In practice, many security teams encounter AI misuse only after an agent has already reached an API, exported data, or chained tools in ways no one reviewed.
How It Works in Practice
The right response is to model AI systems as autonomous workloads with identity, privilege, and runtime behaviour, not as isolated models. That means starting with workload identity, then constraining what the agent can do at request time. Best practice is evolving, but current guidance suggests using short-lived credentials, explicit policy checks, and tight tool-level boundaries rather than static roles that assume predictable human workflows.
Practically, this often looks like:
- Issuing ephemeral credentials per task or session, then revoking them automatically when the job completes.
- Binding access to workload identity, such as OIDC-based assertions or SPIFFE/SPIRE-style identities, so the platform can verify what the agent is rather than only what secret it holds.
- Evaluating authorisation at runtime with policy-as-code, using context such as request purpose, target data class, destination system, and recent behaviour.
- Separating read, write, and delegation permissions so an agent cannot silently promote itself through chained tools.
- Logging every tool call and data movement as an identity event, not just as an application event.
NHIMG’s OWASP NHI Top 10 is useful here because it frames these failures as exposure in credentials and execution paths, while Top 10 NHI Issues shows how often standing access and secret sprawl become the enabling condition. NIST’s NIST Cybersecurity Framework 2.0 supports the same operational view by tying identity, monitoring, and response into one control system.
These controls tend to break down when an organisation lets an agent inherit broad SaaS permissions across multiple tenants, because runtime policy can no longer reliably distinguish intended automation from lateral movement.
Common Variations and Edge Cases
Tighter control often increases integration overhead, requiring organisations to balance faster automation against stronger approval and revocation logic. That tradeoff becomes sharper in environments where agents are embedded in business workflows, because the more useful the agent is, the more systems it touches.
There is no universal standard for this yet, but current guidance suggests treating three situations as especially risky. First, agents that can call external APIs or execute code need stronger runtime checks than chat-only assistants. Second, systems that share long-lived service accounts across teams need redesign, not just better monitoring, because access cannot be cleanly attributed. Third, multi-agent pipelines need separate identity and privilege boundaries for each step, otherwise one compromised agent can amplify trust across the chain.
This is also where model-centric thinking fails operationally: a hallucination may create a bad answer, but a mis-scoped agent identity can create an actual breach. NHIMG’s Ultimate Guide to NHIs — Why NHI Security Matters Now and the DeepSeek breach both reinforce the same lesson: exposed secrets and excessive access are the real accelerants, not the model family itself.
In practice, the hardest failures appear in highly integrated SaaS environments where the agent’s access is inherited from human workflows, because those permissions are broad by design and rarely reviewed at machine speed.
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, CSA MAESTRO 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 | A2 | Agentic systems fail when runtime access is broader than intended. |
| CSA MAESTRO | MAESTRO-2 | Covers identity, privilege, and orchestration risks in agentic systems. |
| NIST AI RMF | GOVERN | Requires governance beyond model quality, including deployment context. |
| OWASP Non-Human Identity Top 10 | NHI-03 | Addresses secret sprawl and weak credential lifecycle for machine identities. |
| NIST CSF 2.0 | PR.AC-4 | Least privilege and access management are central to AI system containment. |
Assign ownership for agent behaviour, access, and downstream impact under the GOVERN function.
