How should security teams govern AI agents and human users under zero trust in generative AI environments?

Security teams should treat both people and AI agents as identities that must be authenticated, authorized, and continuously monitored. Apply least privilege to reduce blast radius, separate high-risk tasks from broad access, and review permissions as models and workflows change. This matters because compromised credentials, prompt manipulation, or overbroad access can turn an AI tool into a fast-moving insider risk.

Why This Matters for Security Teams

Generative AI environments collapse the old separation between user, application, and workflow. A human may approve a task, but an AI agent can execute it, call tools, retrieve data, and chain actions at machine speed. Under zero trust, that means both the human and the agent need explicit identity, strong authorization, and continuous verification. The practical risk is not just model misuse; it is overbroad access, weak session control, and unreviewed tool permissions creating an identity pathway for abuse. Guidance from the NIST Cybersecurity Framework 2.0 and NIST AI Risk Management Framework both support governance that treats AI behaviour as a managed risk surface, not a novelty feature.

Teams often get this wrong by focusing on prompt hygiene alone while leaving API keys, delegated tokens, and admin-approved tool scopes in place. That creates a false sense of control because the agent appears constrained while still holding meaningful access to data and systems. In practice, many security teams encounter this only after an AI workflow has already accessed sensitive systems through a trusted account rather than through intentional zero trust design.

How It Works in Practice

Zero trust for generative AI should be implemented as a layered identity and control model. First, distinguish the human operator from the AI agent and from the service accounts or tokens the agent uses. Each identity should have its own authentication method, policy boundary, and audit trail. Second, bind permissions to purpose and context instead of broad role membership, so the agent can complete only the specific workflow it was assigned. Third, log every high-risk action, including tool calls, data retrieval, approval steps, and escalation events, so security teams can reconstruct both intent and execution.

Operationally, this usually means combining conditional access, short-lived credentials, restricted tool catalogs, and human approval for sensitive actions. The zero trust principle in NIST SP 800-207 Zero Trust Architecture is especially relevant because AI agents should never inherit standing trust just because they are embedded in a business process. For agentic systems, current guidance also suggests modelling prompt injection, tool misuse, and data exfiltration as explicit attack paths, which is reflected in the OWASP Agentic AI Top 10 and MITRE ATLAS adversarial AI threat matrix.

• Use separate identities for humans, agents, and backend automation.
• Grant time-limited access for each workflow, not persistent platform-wide privilege.
• Require step-up approval for destructive, financial, or data-exfiltration-prone actions.
• Continuously review tool permissions as models, prompts, and integrations change.
• Correlate AI activity with SIEM and SOAR detections so misuse is observable.

Where agentic systems touch external data, memory stores, or privileged APIs, provenance matters as much as authorization. Security teams should validate which model version ran, which tools were available, which prompt context was supplied, and whether a human actually approved the action. These controls tend to break down when AI agents are chained across multiple SaaS platforms because identity propagation and audit consistency become uneven between systems.

Common Variations and Edge Cases

Tighter control often increases operational friction, requiring organisations to balance automation speed against governance overhead. That tradeoff is most visible when business teams want agents to act autonomously in workflows that were designed for human review. Best practice is evolving here, and there is no universal standard for full agent delegation yet. The safest pattern is to separate low-risk retrieval tasks from high-risk execution tasks, then expand autonomy only after monitoring proves the workflow is stable.

Edge cases appear when an agent must operate across sensitive domains such as finance, customer identity, or regulated communications. In those environments, zero trust should be paired with workflow-specific policy, immutable logs, and a clear human owner for every agent identity. The CSA MAESTRO agentic AI threat modeling framework and NIST AI 600-1 Generative AI Profile are useful when teams need to translate abstract governance into concrete agent controls. For deeper risk analysis, the Anthropic report on AI-orchestrated cyber espionage is a reminder that agents can be abused as operational accelerators, not just chat interfaces.

The main exception is research or sandbox environments, where broader permissions may be acceptable for experimentation if the data is synthetic and the network boundary is isolated. Even there, governance should still require inventory, ownership, and revocation paths, because experimental agents often move into production faster than expected.

Related resources from NHI Mgmt Group

• How should security teams govern browser-based AI agents in SaaS environments?
• How should security teams govern AI agents and non-human identities in IGA?
• How should security teams govern machine identities in zero trust environments?
• How should security teams implement zero trust for non-human identities in federal environments?