"Claude can handle IT support" — as whom, exactly?
It sounds good on its own: an employee needs their password reset, or wants to know whether their licence covers a particular app, and instead of waiting on an IT ticket, they ask an AI assistant and get an answer right away.
But the interesting question isn't whether Claude can do this. It's as whom it does it, and what access it actually has while doing it. That's where most solutions we see get vague — and it's exactly where we put the most work when we built our own IT support assistant.
What we built
The solution connects Claude to Microsoft 365 through Azure Bot Service, and uses the Microsoft Graph API to give Claude access to carry out concrete support actions: resetting passwords, checking and managing licences, looking up group membership, and other routine tasks that would normally land in an IT support queue.
This isn't a concept or a demo. It's something we use ourselves internally, every day, alongside building it for clients.
The bot has its own identity — not yours, not a shared admin account
Here's the point that separates this from most "AI + Graph API" setups we see thrown together in a hurry: the bot has its own identity in Entra ID. Not a shared service account every action routes through with no traceability. Not a configuration where the bot impersonates an administrator to get the access it needs.
Why does this matter? Because it makes the bot a real actor in your access model — not a loophole outside it. Role-based access control (RBAC), which we build into every delivery regardless, applies to the bot exactly the way it applies to an employee. The bot gets the roles and access it actually needs for its job, no more and no less — and everything it does traces back to that specific identity, not hidden behind a generic service account.
Conditional Access applies to the bot too
Most people think of Conditional Access — rules that grant or deny access based on things like location, device, and risk score — as something that applies to humans logging in. It's less well known, but just as relevant, that the same rules can be applied to a bot's identity.
In practice, that means the bot doesn't get a free pass just because it's an AI. It's subject to exactly the same conditions you already apply to everything else that touches your systems. If something unusual happens — an action from an unexpected context, for example — the same safeguards that would stop or flag a human user apply here too.
In our experience, this is the thing most businesses don't think about when they first consider AI agents in M365: the question isn't just "what access do we give the bot," but "what conditions apply to that access, the same as for everyone else."
Read actions happen on their own. Write actions ask first.
The last piece is arguably the most important in practice: the bot distinguishes between reading and writing.
Checking a licence status, looking up group membership, or retrieving information — the bot does that autonomously, because it doesn't change anything. But the moment an action is actually going to do something — reset a password, change an access grant, remove someone from a group — the bot stops and asks for explicit approval before carrying it out.
This is the same principle we've written about before with Claude Live: a human at the wheel. Not because we don't trust the model, but because that's how responsible AI use is supposed to work in a business — the more consequential an action, the more clearly a human needs to be part of the decision.
We use it ourselves
This isn't just something we sell. We run part of our own IT support through this exact setup internally. That's one of the reasons we're comfortable recommending it further — we've tested it on our own operations first, not only on a client's.
Want something similar?
An IT support assistant built this way — its own Entra identity, Conditional Access, and a clear split between read and write actions — is exactly the kind of delivery we build under Enterprise Solutions: tenant preparation, Claude-based agent blueprints in M365, and automation set up with the same governance thinking the rest of your business is already held to.
The point that keeps repeating
An AI assistant that can do something in your systems isn't automatically a security problem. But it isn't automatically safe just because it's useful, either. The difference lies in whether it's built with its own, traceable identity, subject to the same rules as everything else — or whether it just got the access it asked for, because that was fastest.
AI starts not with technology. It starts with structure.
Get in touch for a free AI Ready assessment →
Read also: Claude in the Browser Is Not an AI Strategy · MCP: The Bridge Between Claude and Your Systems