Should Your AI Agent Be Allowed to Reset a Password? The Permission Model That Actually Matters.

The instinct that doesn't actually help

The common first move is to add a human approval step in front of anything sensitive. An agent wants to reset a password; a person has to click approve. It feels responsible. It's also treating the symptom, not the cause, because it does nothing to limit what the agent could do if the approval step were bypassed, misconfigured, or simply not looked at closely enough on a busy day. Approval workflows are a second line of defense. They're not the thing that makes an action safe in the first place.

The thing that actually makes an action safe is how much power the agent was given to begin with.

Two very different ways to grant an AI agent access

Most identity platforms offer two fundamentally different permission models, and the difference between them is the entire ballgame.

Application permissions give the agent its own identity, with standing power to act on anyone in the system. If the agent is manipulated through clever conversation, misidentifies who it's talking to, or has a bug in its logic, the blast radius is everyone. This is a real, known risk category for any AI system that takes real-world actions, not a hypothetical.

Delegated permissions mean the agent acts as the person who's currently signed in, through their own authenticated session. It can only do what that specific person is already allowed to do to themselves. There's no path to another account, because the permission model mechanically doesn't allow one, regardless of what the agent is told in conversation.

Read that difference again, because it's the whole answer to the original question. An agent with delegated permissions resetting a password isn't a security risk in the way the gut reaction assumes, it can only reset the password of the person talking to it, the same way a self-service portal already lets someone do today. An agent with application permissions doing the same thing is a completely different, much scarier proposition, because now it's not scoped to one person at all.

Don't rebuild what's already secured

Here's a mistake worth naming directly: having the agent call an admin-level API to force a password change itself. Most identity platforms already have a mature, hardened, MFA-gated self-service reset flow, built and battle-tested by the platform vendor, not by whoever built the agent last month. The right design orchestrates that existing flow. It doesn't reimplement identity verification from scratch inside an AI agent's own logic, which is exactly the kind of custom security code most prone to a subtle, expensive mistake.

Not every action deserves the same treatment

Once the permission model is right, the remaining design question is which actions are safe to let the agent handle fully on its own, and which should still involve a human, and the answer isn't uniform.

Purely informational requests, "how do I do X," carry no risk and need no gate at all. Self-scoped actions, the kind delegated permissions already confine to one person's own account, can run autonomously precisely because the blast radius is structurally limited. Anything that looks like it targets someone else's account, or where the agent genuinely can't confirm who it's acting for, should escalate to a person every time, not as a judgment call the agent makes in the moment, but as a rule that isn't up for interpretation.

That's a meaningfully different design than "approve everything" or "approve nothing." Most of the traffic moves fast because it's safe by construction. The narrow slice that isn't gets a human, every time, without exception.

The question worth asking before any of this

If you're designing what an AI agent is allowed to do, the test isn't "does this feel risky." It's: what is the actual worst thing this agent could do if it were manipulated, wrong, or simply confused about who it's talking to. If you can answer that question and the answer is small and contained, you've scoped it correctly. If the honest answer is "it could affect anyone in the organization," the fix isn't a better approval workflow sitting on top. It's giving the agent less power in the first place.

If you found this useful, hit the Subscribe button below to get more articles like this delivered straight to your inbox.

Want to see how we think about security architecture for AI agents that take real action? Start a free trial and see the guardrails in practice.

Where does your team draw the line on what an AI agent should be allowed to do on its own? Tell me in the comments