How should security teams govern AI agents that can reset accounts or change credentials?

Why This Matters for Security Teams

When an AI agent can reset accounts or change credentials, the risk is no longer limited to stolen secrets. The more important issue is whether the agent is allowed to trigger identity changes without a separate control point. That is an authorization design problem, not a chatbot problem. Current guidance from the OWASP Agentic AI Top 10 and NIST’s NIST AI Risk Management Framework points toward runtime controls, explicit policy, and human accountability for high-impact actions.

NHIMG research on the AI Agents: The New Attack Surface report shows why this matters operationally: 80% of organisations report their AI agents have already performed actions beyond intended scope, including revealing access credentials. In practice, many security teams discover this only after an agent has already been persuaded to overreach, rather than through intentional control design.

How It Works in Practice

The safest model is to treat the agent as a request origin, not as an authority over identity changes. The agent can propose a reset, credential rotation, or account recovery, but the actual privileged action should be enforced by an external policy layer that checks live identity, task context, and the specific target principal before approval. That usually means binding the request to a workload identity, a user session, or a verified service principal, then evaluating policy at request time rather than relying on static role grants.

For autonomous workflows, static IAM is too coarse. An agent does not have one stable access pattern. It may chain tools, escalate from one system to another, or attempt a credential change as part of a broader workflow. That is why best practice is evolving toward intent-based authorization, just-in-time credential issuance, and short-lived secrets that expire once the task completes. The OWASP Non-Human Identity Top 10 is useful here because it frames the agent as a non-human workload that still needs lifecycle control, rotation discipline, and bounded privilege.

In implementation terms, teams should require:

• External policy enforcement for any credential reset or account modification.
• Explicit principal binding so the agent can only act on the exact subject in scope.
• Just-in-time access with short TTLs and automatic revocation after completion.
• Audit logs that capture the agent prompt, policy decision, target account, and approver path.
• Separation between the model’s recommendation and the identity system’s final action.

This approach aligns with the CSA MAESTRO agentic AI threat modeling framework, which emphasises control points around agent planning, tool use, and delegated action. It also matches NHIMG guidance in the Ultimate Guide to NHIs — Static vs Dynamic Secrets, where static credentials are a poor fit for autonomous workloads that can make unpredictable requests. These controls tend to break down when the agent is embedded directly into the IAM or helpdesk workflow because the request and the approval collapse into the same trust boundary.

Common Variations and Edge Cases

Tighter identity controls often increase workflow friction, so organisations must balance speed against the blast radius of a mistaken or coerced agent action. That tradeoff becomes visible in account recovery, privileged helpdesk automation, and self-service password reset flows, where the business wants convenience but the security model demands separation of duties.

There is no universal standard for this yet, but current guidance suggests a few practical exceptions and edge cases. If the agent only drafts a reset request for a human approver, the required controls are lighter than if it can execute the reset directly. If the agent operates in a break-glass scenario, approval policy should become stricter, not looser, because the action is inherently high risk. If the target account is another machine identity, the team should use workload identity and short-lived credentials rather than human-style account recovery procedures.

Teams should also be cautious about conversational approval patterns. An agent that can be talked into changing credentials is still relying on social engineering resistance, not enforceable authorization. That is why NIST’s framework and the OWASP agentic guidance both favour context-aware decisions, not trust in the model’s intent. The NHIMG LLMjacking: How Attackers Hijack AI Using Compromised NHIs research is a reminder that compromised non-human identities can be abused quickly once control is lost. For teams that need a broader governance baseline, the OWASP NHI Top 10 is a useful companion reference for setting those boundaries.

Related resources from NHI Mgmt Group

• How should security teams govern machine identity credentials in agentic AI environments?
• How should security teams govern AI agents that use OAuth access?
• How should security teams govern AI agents that can access enterprise systems?
• How should security teams govern semiautonomous AI agents before they go live?