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.

Hanif Karimi··5 min read

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.

Deterministic shell around a probabilistic reasoning core.
Figure 3.1. Deterministic shell around a probabilistic reasoning core. From Chapter 3 of the book.

Most programmes answer that question with material that lives in the wrong place: a line in the system prompt saying never to reset an executive’s factor without verification, a confidence threshold, a log for later. The first two sit inside the component they are meant to control. The third arrives after the fact. A log will tell you on Tuesday that the CFO’s factor was replaced on Saturday.

Across those programmes, I watched promising technology meet an auditor or an incident review many times. It rarely failed for being weak. It failed because nobody could say, afterwards, who had allowed it to do what it did. Agents will face the same test, sooner and at greater scale.

My forthcoming book sets out an approach I call the Contextual Agentic Enterprise (CAE): a vendor-neutral architecture and operating model in which people, models, agents and systems act together on enterprise context, under explicitly delegated authority, leaving evidence and producing outcomes that can be measured. It is my proposed framework, not an established standard, and I will write about its parts in the weeks ahead.

One idea from it is worth taking into that steering committee now. Every agent reaches a moment where its proposal would turn into a change that others can observe: the factor is removed, the membership is written, the message is sent. The book calls that moment the Commit Boundary. Before it, the reasoning can be tentative, generous, even wrong. At it, something outside the model has to decide, every single time, whether this action, for this person, on this authority, may go ahead. Your assistant never came near that point. Phase two lives there.

The commitment ladder and the irreversibility boundary.
Figure 8.3. The commitment ladder and the irreversibility boundary. From Chapter 8 of the book.

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.

Sources

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

Share on LinkedIn

Related