That depends on the AI footprint and the gap you are trying to close. If the issue is visibility for existing users and apps, an existing zero-trust or SSE stack may be enough. If the problem is shadow AI, runtime policy, and agentic actions, a dedicated AI governance layer is usually the cleaner fit.
Why This Matters for Security Teams
The decision is not really about tools, it is about control boundaries. zero trust and SSE are strong when the problem is access to known users, devices, and apps, but AI agents introduce autonomous, goal-driven behaviour that changes the risk model. Current guidance suggests treating agents as workload identities, not as enhanced users, because they can chain tools, request secrets, and act outside predictable human patterns. That is why NIST AI Risk Management Framework matters here, alongside NIST Cybersecurity Framework 2.0 and NHI guidance from Top 10 NHI Issues.
In practice, the wrong question is "Can existing zero trust cover AI?" The better question is "Does the current stack evaluate intent, short-lived credentials, and runtime policy for autonomous actions?" If the answer is no, the organisation may have visibility but still lack governable execution. In practice, many security teams encounter privilege creep only after an agent has already been allowed to act with human-like trust.
How It Works in Practice
For conventional applications, extending zero trust can be enough if the main requirement is authentication, segmentation, and inspection. For agents, the architecture usually needs an additional governance layer that can make decisions at runtime based on the task, the resource, and the current context. That means moving beyond static RBAC and long-lived secrets toward workload identity, JIT credential issuance, and policy-as-code. The agent should prove what it is with cryptographic identity, then receive only the minimum capability needed for a specific action, for a limited time. This is where Guide to SPIFFE and SPIRE is directly relevant, because workload identity is the primitive that makes per-task authorisation possible.
- Use ZTA to authenticate the calling workload, but use a dedicated ai governance layer to approve intent.
- Issue ephemeral secrets only when the action is approved, and revoke them when the task ends.
- Log tool use, prompt-to-action paths, and privilege changes so autonomous behaviour is auditable.
- Align controls to NIST AI Risk Management Framework and NIST AI 600-1 Generative AI Profile for governance, and use Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs to structure provisioning and revocation.
This model is reinforced by DeepSeek breach lessons: secret exposure and uncontrolled data paths are not theoretical, they become immediate operational risk once AI systems are allowed to reach production data and tools. These controls tend to break down when agents are granted broad shell, cloud, or SaaS permissions because the policy engine cannot reliably predict the next tool the agent will chain.
Common Variations and Edge Cases
Tighter AI governance often increases operational overhead, requiring organisations to balance faster automation against stronger runtime control. There is no universal standard for this yet, so the right answer depends on whether the environment is mostly human-led with a few AI features, or genuinely agentic with autonomous execution. If the use case is still limited to chat, retrieval, or advisory workflows, extending zero trust may be sufficient. If the system can change infrastructure, move data, or trigger business actions on its own, a dedicated AI governance platform becomes the safer control plane.
Edge cases include vendor-hosted copilots, multi-agent pipelines, and environments that still depend on static credentials. The Ultimate Guide to NHIs — Regulatory and Audit Perspectives helps frame what auditors will ask for: who approved the action, what identity was used, and whether access was time-bound. Organisations should also watch the gap between policy and behaviour, because agent approvals often look compliant at design time but drift in production. Best practice is evolving, but current guidance favours dedicated governance once the AI can act independently, especially for tool use, secrets access, and cross-system workflows.
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 | A1 | Agentic systems need runtime controls for autonomous tool use and privilege expansion. |
| CSA MAESTRO | MAESTRO-2 | MAESTRO addresses autonomous AI governance, including intent and policy enforcement. |
| NIST AI RMF | AI RMF governs accountability and risk decisions for AI systems, including agents. |
Treat agent actions as high-risk and require runtime approval before tool access or state changes.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 6, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
