How should security teams govern AI agents that can make identity decisions through natural language prompts?

Why This Matters for Security Teams

Natural language makes AI agents easier to use, but it also makes authorization easier to bypass if prompt text is mistaken for policy. Security teams should treat the prompt as an instruction channel, not a trust boundary. The real risk is that an agent can translate a vague request into a privileged identity action unless the system forces deterministic checks, explicit approvals, and bounded workflows. That is why current guidance aligns with the OWASP Agentic AI Top 10 and NIST’s governance-first view in the NIST AI Risk Management Framework.

For NHI management, the issue is not whether the agent can “understand” identity language. The issue is whether it can cause access to be granted, extended, or revoked without a policy engine independently verifying scope, purpose, and approver intent. NHIMG research on the Ultimate Guide to NHIs shows how often excessive privileges and weak visibility amplify identity risk across enterprises. In practice, many security teams encounter the failure only after an agent has already triggered an overbroad identity change, rather than through intentional testing of the approval path.

How It Works in Practice

Governance starts by separating language interpretation from authorization. The agent may parse a request such as “approve temporary access for the on-call analyst,” but the system must convert that intent into a constrained workflow with fixed states, required evidence, and a policy decision that is evaluated at runtime. A prompt should never directly grant rights, update roles, or create credentials.

Practitioner controls usually combine four elements:

• Deterministic policy checks using policy-as-code, such as OPA or Cedar, evaluated against the request context.
• JIT identity actions, where the agent can only request a short-lived approval, session, or revocation task.
• Workload identity for the agent itself, so the system knows what the agent is cryptographically and not just what it claimed in text.
• Immutable logging of prompt, policy decision, approver, and resulting identity workflow for later audit.

That design is consistent with the control logic described in the CSA MAESTRO agentic AI threat modeling framework and the operational direction in NHIMG’s OWASP NHI Top 10. In mature environments, the agent should call a narrow identity API, not an admin console, and the API should enforce purpose limits, TTLs, and approval thresholds regardless of how persuasive the prompt appears. These controls tend to break down when identity tooling is fragmented across SaaS consoles and ad hoc scripts because policy can no longer be enforced at one decision point.

Common Variations and Edge Cases

Tighter identity control often increases workflow friction, requiring organisations to balance faster agent-assisted operations against stronger approval discipline. That tradeoff becomes more visible in incident response, access reviews, and support automation, where teams may want the agent to act quickly but still need a human or policy checkpoint for destructive changes.

Current guidance suggests treating high-risk identity actions differently from low-risk ones. For example, an agent may be allowed to draft a revocation request, summarize anomalous access, or prepare an approval packet, but not self-authorize emergency access unless a separate policy condition is met. There is no universal standard for this yet, so security teams should define their own risk tiers and document which identity outcomes are informational, advisory, or executable.

This matters most in environments with multiple agents, delegated admin paths, or legacy IAM systems that cannot express context-aware rules cleanly. NHIMG’s 52 NHI Breaches Analysis shows how identity compromise often spreads through weakly governed machine credentials, and agentic systems can magnify that pattern if prompts are allowed to steer privileged workflows. Security teams should assume the most dangerous case is not malicious wording alone, but a well-meaning prompt routed into an overly broad identity permission model.

Related resources from NHI Mgmt Group

• Why do AI-driven identity workflows require stronger controls around natural language prompts and execution scope?
• How should security teams govern AI-driven authorization when policy rules have to satisfy both business needs and machine-generated decisions?
• How should security teams govern API keys used for generative AI access?
• How should security teams govern AI agents that use multiple identity layers?