Contextual Agentic

From Assistance to Agency: Why Enterprise AI Creates a New Architectural Problem

Letting a service desk assistant reset MFA is not phase two of the same programme. Once an agent can change state, the question becomes what it may change, and on whose authority.

·Updated 31 August 2026·5 min read

Written as at 1 August 2026.

agentic-aienterprise-architectureidentityai-governanceletters

I have spent a good part of my career on identity programmes: sign-in platforms, multi-factor authentication, account recovery. It is the plumbing most people only notice on the day it locks them out. If those programmes taught me one thing, it is that the riskiest moment in identity is rarely the sign-in. It is the reset: the moment someone persuades the system, or a person, that they really are who they say they are and need to be let back in.

So a proposal I am hearing more often makes me sit up. A service desk assistant has been summarising tickets for six months. The analysts like it, first responses are quicker, and nobody can point to a summary that went badly wrong. The next step looks obvious: let it finish the job. Reset a user’s MFA factor when they are locked out, and add people to the access groups their managers have asked for.

It usually arrives as phase two of the same programme. I want to make the case that it is a different programme, with a different risk owner, and that the difference is architectural before it is anything else.

Look at what the assistant does today. It reads a ticket, writes a summary and suggests a category. A person reads that output before anything happens. If the summary is wrong, the analyst notices, or doesn’t, and the cost is a slower ticket. The model sits beside your control path rather than on it. Every existing check on who may change an account still applies, because a human with their own login still makes the change.

Now picture phase two. A ticket arrives at 11.40 pm: “Locked out, new phone, please reset my MFA, flying to Singapore in two hours.” The agent finds the user and calls the identity provider’s API to remove the old factor and enrol a new one. Nobody reads the output first, because the output is the change.

That shift has a consequence your programme plan probably doesn’t show. To reset factors and edit group membership for anyone who raises a ticket, the agent needs a credential that can do those things for everyone. View that service account the way your auditors will. It can take over any identity in the organisation by replacing its second factor. It can place anyone, itself included, in any group, including the ones guarding finance systems and production. It never takes leave, it sits outside your joiner-mover-leaver process, and it takes its instructions from free text written by anyone who can open a ticket.

Without a single design decision that looked dangerous, that credential has become one of the most privileged identities you run.

Your human analysts already face this pressure. In 2023 the FBI and CISA warned that one criminal group was using social engineering to talk IT help-desk staff into resetting passwords and MFA tokens, then walking through the door the reset opened. Your analysts have call-back procedures, an instinct for a story that is too urgent, and a manager to ask. The agent has its instructions, and instructions are just more text, weighed alongside the attacker’s.

This is what I mean by the move from assistance to agency. An assistant produces information that a person then acts on. An agent acts, and in acting it joins the path your organisation uses to change what is true: who a user is, what they can reach, where money goes. OWASP now ranks ‘excessive agency’ third among the risks it lists for applications built on language models. Once an agent is on that path, the useful question is no longer how good its answers are. It is what the agent can change, on whose authority, and what stops it when it is wrong. A better model helps less than you would hope, because a very good model that can be talked into a reset still holds the credential.

A probabilistic core proposes actions and every proposal crosses a deterministic validation boundary before anything happens. The boundary checks schema, the policy decision, budget and loop limits, and an approval bound to the exact payload. Three proposals land differently: a factor reset is admitted to the systems of record, an invoice payment is deferred to a person because no approval is bound to its payload, and a request to join a production administrator group is refused because no grant covers it. All three are written to the evidence record.
Figure 3.1. Deterministic shell around a probabilistic reasoning core. Animated for the web edition; shown as a still image if your device is set to reduce motion. The print edition carries the same figure in black and white.
Five rungs of commitment rising left to right: suggest, draft, recommend, act reversibly and commit irreversibly, with a marked boundary between the fourth and the fifth. A disputed invoice climbs the ladder, and the meter beneath reports what being wrong costs at each rung: a wasted read, a wasted review, someone's time, a correction, and finally a contract.
Figure 8.3. The commitment ladder and the irreversibility boundary. Animated for the web edition; shown as a still image if your device is set to reduce motion. The print edition carries the same figure in black and white.

None of this is an argument to stop. An agent that clears lockouts at 3 am is worth having, and your analysts have better uses for their evenings than adding people to distribution lists. It is an argument to fund phase two as what it really is: a new privileged actor in your identity estate, which needs an owner, limits and a control it cannot talk its way around.

Here is what I would do on Monday. First, ask for a one-page list of every agent initiative in flight, each marked ‘reads’ or ‘changes’, with the name of the person who owns the authority of every one that changes something; expect blanks, and treat the blanks as the finding. Second, ask your architects which of those agents will touch a system of record, and through which credential; your identity provider counts. Third, ask an engineer to take the service desk agent’s credential into a test tenant and try to reset a test user’s MFA by calling the API directly, with no model involved. If that works, the only thing standing between a persuasive ticket and an account takeover is the model’s judgement.

Animated diagram. Two requests arrive at a service desk. The first, a summarise-this-ticket request from the assistant era, needs no authority and produces a suggestion that a human analyst acts on. The second, a reset-MFA request at 11.40pm claiming an urgent flight, is checked for identity, a call-back record, authority and policy; the call-back evidence is missing, so it is escalated to a human analyst rather than performed. A third request, from the same ticket, asks to add the user to a finance group and is refused because no grant covers it. Each outcome writes a row to the evidence record.
Figure 3. The same ticket queue, once the assistant can change things. Animated; shown as a still image if your device is set to reduce motion.

Sources

This article is part of Letters from the Contextual Agentic Enterprise, a series accompanying the forthcoming book, The Contextual Agentic Enterprise.

Share

← All articles

Related

ArticlePublished 30 August 2026Updated 31 August 2026

Six Frameworks Answer the Question. None of Them Ask Yours.

TOGAF, COBIT, ITIL, SAFe, programme management and enterprise risk each answer a real question about the enterprise. So do the AI management standards, and so do the vendor agent platforms. None of them answers the one that decides whether an agent should have acted.