They often treat AI as a single category and then count tool coverage as governance. That creates a false sense of control because identity, cloud, data, and endpoint layers are only inputs. Real governance requires knowing which systems can act, what they can access, and whether their behaviour stays inside intended bounds.
Why This Matters for Security Teams
Most organisations miss the real risk because they measure AI security by tool count, policy count, or whether a platform sits behind a gateway. That creates an illusion of coverage while leaving the hard part untouched: whether the system can act, what it can reach, and how quickly it can be abused once credentials, tokens, or API keys are exposed. The problem is visible in incidents like the DeepSeek breach, where exposed secrets turned configuration weakness into broad data exposure.
Agentic systems make this gap worse because they are not static workloads. They can chain tools, request more access, and pursue a goal in ways a traditional IAM model does not predict. That is why current guidance increasingly points toward runtime evaluation and explicit workload identity rather than relying only on perimeter controls or RBAC. The Anthropic Project Glasswing and the CSA MAESTRO agentic AI threat modeling framework both reflect this shift toward modelling behaviour, not just inventory.
In practice, many security teams discover AI abuse only after an agent has already chained privileges or exfiltrated data, rather than through intentional governance design.
How It Works in Practice
Strong AI security coverage starts by separating three layers that are often blurred together: the application, the identity that runs it, and the secrets it uses. Static RBAC is usually too coarse for autonomous workloads because an agent does not follow a fixed human job description. Its access needs change by task, tool, context, and time. For that reason, best practice is evolving toward intent-based authorisation, where a policy decision is made at request time based on what the agent is trying to do, the data it is asking for, and the environment it is operating in.
That usually means combining workload identity with JIT credentials and short-lived secrets. Instead of issuing long-lived tokens that can be replayed later, the platform mints ephemeral credentials per task and revokes them when the task ends. This reduces the blast radius when something goes wrong. Implementation guidance commonly references workload identity primitives such as SPIFFE/SPIRE or OIDC-backed service tokens, because they prove what the agent is, not just what secret it possesses. Policy engines can then evaluate requests against current context using approaches such as policy-as-code, OPA, or Cedar. The key point is that authorisation should happen at runtime, not as a one-time setup step.
This matters because secret exposure remains a fast path to compromise. Entro Security’s research on DeepSeek breach and the DeepSeek breach case study both show how quickly exposed credentials and sensitive records can become operational risk. These controls tend to break down in highly integrated environments where agents can call multiple tools across cloud, SaaS, and internal systems because the policy context is fragmented and the real trust chain is not visible end to end.
- Use workload identity for the agent before issuing any tool access.
- Issue JIT credentials with the shortest workable TTL.
- Authorize at runtime against intent, context, and data sensitivity.
- Revoke access automatically when the task completes or the context changes.
Common Variations and Edge Cases
Tighter runtime authorisation often increases integration overhead, requiring organisations to balance speed of deployment against control depth. That tradeoff is real, especially where multiple vendors, legacy systems, and human-operated service accounts already coexist. There is no universal standard for this yet, so current guidance suggests documenting which workloads are agentic, which are merely automated, and which are still human-triggered before applying the same controls everywhere.
One common failure mode is treating third-party connectors as low-risk because they are “just integrations.” In practice, they can become high-value NHI paths if OAuth scopes are broad or vendor visibility is weak. The DeepSeek breach is a reminder that exposed secrets and overbroad access are often the real control failure, not the model itself. Another edge case is multi-agent orchestration: a single agent may look contained, but a chain of agents can pass context, escalate actions, and create lateral movement that perimeter-based assumptions miss.
Best practice is evolving toward combining NHI governance with agentic threat modelling, as reflected in Anthropic Project Glasswing and the CSA MAESTRO agentic AI threat modeling framework. The practical test is simple: if the organisation cannot answer what the agent can do right now, the security coverage is still incomplete.
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 CSA MAESTRO address the attack and risk surface, while NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A01 | Static IAM fails when agents act unpredictably and need runtime controls. |
| CSA MAESTRO | M1 | Threat modelling must cover autonomous tool use and chained actions. |
| NIST AI RMF | GOVERN | AI governance needs accountability for behaviour, not just inventory. |
Assign owners, define oversight, and review agent behaviour against policy on an ongoing basis.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 4, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
