Only for some locks, and the lock reason decides. If an account locked itself after too many wrong passwords, an AI agent can guide the verified customer through re-authentication so the customer reopens it. If a person or a control placed the lock for fraud, financial crime, a legal order or a dispute, the agent must not lift it.
Why does the lock reason matter so much?
A lock is a decision someone or something made to stop access. Lifting it reverses that decision. When the lock came from the customer's own failed attempts, reversing it is routine: prove you are you, and carry on. When it came from a fraud rule, a financial crime review, a court order or a bereavement notification, reversing it undoes a protective control that the agent knows nothing about.
So the agent's first task is not unblocking. It is reading the lock code from the system of record and classifying it. If the code is missing or ambiguous, the agent treats the lock as one it cannot lift.
Which locks can the agent handle?
| Lock reason | What the agent may do | What stays with a person |
|---|---|---|
| Too many failed passwords or codes | Verify the customer, then send them through the standard reset or re-authentication flow | Customers who fail verification |
| Customer froze their own account or card | Unfreeze on the customer's authenticated request | Nothing routine |
| Inactivity or dormancy | Explain the reactivation steps and collect what is needed | Final reactivation where identity checks are required |
| Suspected fraud or account takeover | Confirm there is a restriction and route to the fraud team | Lifting the lock, contacting the customer about the case |
| Financial crime review | Say only that the account is restricted and a team will be in touch | Everything else |
| Legal order, bereavement, dispute | Route to the right team | Everything |
The financial crime row is the one most often got wrong. An agent that explains "your account is under review for unusual transactions" may be disclosing more than the business is allowed to. The agent says the account is restricted, that it cannot change that, and who will be in touch. A person decides what more, if anything, can be said.
Is the agent unblocking the account, or is the customer?
For self-service locks, the customer is. That distinction is worth keeping. The agent should not hold a "force unblock" capability that bypasses authentication; it should route the customer into the same reset flow they would use on their own, with the same strong authentication. The record then shows the customer proved their identity, not that an agent decided they had.
This also closes a gap attackers use. An account locked by password guessing is being targeted. A chat agent that unblocks on a few answered questions is a softer door than the login page. Recovery when the customer has lost their phone or email access is harder again and belongs to account recovery requests, not to an unblock script.
An illustrative example
Take a subscription service's support agent. A customer writes that they are locked out after mistyping their password five times.
The agent reads the lock code: failed attempts, placed automatically. It verifies the customer through a code sent to the email already on file, then sends the reset link to that same address. The customer resets and is back in. The agent filed the lock reason, the verification result and the reset it triggered.
A second customer says the same thing, but the lock code reads "security review". The agent does not attempt verification to lift it. It tells the customer the account has a restriction it cannot remove, that the security team will contact them, and gives the expected timescale from policy. It does not say why. The case goes to the team with the conversation attached.
What controls make it safe?
- Lock code first. The capability reads the reason before anything else. Unknown codes are treated as non-self-service.
- No bypass. The agent triggers the customer's own authentication; it holds no override.
- Contact details on file only. Codes and links go to details already held, never to a new address given in the conversation. Changing them is a separate request with its own checks, like deleting a customer's account.
- Minimal disclosure. For restrictions the agent cannot lift, it uses fixed wording that says nothing about the cause.
- Repeat-lock limits. Several unblocks on one account in a short period are held for a person, because the pattern itself suggests an attack.
How much account data the agent may see to do any of this is a separate question, answered in whether an AI support agent can access customer account data.
Where Pryme fits
In Pryme, "trigger customer re-authentication" and "remove a restriction" are separate capabilities. The first can be certified on your own past lockout contacts; the second is not granted to support agents. Each attempt gets a verdict naming the bound that decided it. The wider rules are in the AI support agent that knows when to say no.
Questions people ask
Can the agent tell the customer how long a security lock will last?
Only where policy gives a standard timescale for that lock type. It should not estimate from the case.
What if the customer is locked out and abroad?
The same rules apply, but the case is often urgent. The agent routes it to a person with the urgency flagged rather than relaxing verification.
Should the agent unblock a business account for one of its users?
Business accounts usually have an administrator who manages user access. The agent points the user to their administrator rather than unblocking them directly.