Meet Guardian: An AI Agent Assigned to Every User We Support

Most AI in IT support looks the same: a chat box bolted to the side of a ticketing system that can summarize what a technician already typed. It is a nice demo. It does not know anything about your laptop, your sign-ins, or the inbox rule that appeared on your mailbox last Tuesday.

So we built something different inside Impact, the platform we run our managed services business on. It is called the Guardian agent, and there is one of them for every single user we support.

Guardian does two jobs. It watches one person's attack surface continuously, on its own schedule, without anyone asking. And when that person opens a ticket, it is already investigating before a technician has finished reading the subject line.

What Guardian Actually Watches

Guardian's view spans both halves of a modern user's world: the Windows machines they physically sit at, and the Microsoft 365 identity they carry everywhere else.

Under the hood, Guardian delegates to specialists that run in parallel: an identity and security analyst, an endpoint log analyst, a mailbox analyst, a workspace analyst, and a summarizer that draws the conclusion. Each one gets only the tools its job requires. The mailbox analyst physically cannot read sign-in history. That is not a policy written into a prompt — it is the tool list it was handed at construction, and asking for a tool it does not have fails the agent at startup rather than silently at runtime.

Job One: The Ticket Arrives, and Guardian Is Already Working

By the time a technician opens the ticket, the boring part of the investigation is done. Not the judgment — the legwork. Which machine is hers. Whether it is even online. What the System log said at the time she reported the crash. Whether her licence quietly failed to apply overnight because the tenant ran out of seats.

That last one is worth sitting with. A licence can be assigned and still not be in force. To the user, an application simply stopped working. To a technician who has not checked assignment errors specifically, it looks like a mystery. Guardian checks it every time, because it never gets bored.

Job Two: The Daily Check Nobody Asked For

Once a day, on its own reminder, each Guardian runs a health check on the person it watches. Account still enabled. No risky sign-ins in the last 24 hours. No new security alerts. No forwarding rule that was not there yesterday. No licence assignment errors. Devices checking in, agents healthy, OneDrive not full.

Then it compares all of that against a stored baseline — and here is the part we care most about:

Most monitoring products get this backwards. They measure their own value in notifications delivered. We measure ours in notifications withheld. Guardian only speaks when the answer to “what changed?” is something a human should act on.

Both jobs — the ticket investigation and the daily check — run through exactly the same reasoning path. The daily check is just a prompt the agent sends itself on a schedule. There is no second code path quietly rotting in the corner, which is how the unattended half of most monitoring systems dies.

The Hardest Thing We Got Right: “I Could Not Check”

There is a distinction that sounds pedantic until it burns you, and it is the single idea this entire agent was designed around:

“I checked and found nothing” and “I could not check” are completely different statements. An all-clear you cannot support is worse than admitting the gap.

Here is the real scenario. Microsoft's sign-in and audit logs require an Entra ID P1 licence. Plenty of small tenants do not have one. Ask an ordinary AI assistant to check a user for suspicious sign-ins in such a tenant and it will get back one error, six other tool results that succeeded, and then write you a confident paragraph that reads: “No unusual sign-in activity was detected.”

That sentence is false, and a technician will act on it.

So every tool Guardian can call returns an explicit UNAVAILABLE marker when a check could not be performed — distinct from returning an empty result — and every instruction in the system reinforces that the two must never be flattened together. Guardian's conclusions always carry a second list: what could not be checked, and why.

Same principle for hardware. If a machine does not answer within 90 seconds, Guardian does not report a failed query. It reports that the machine is almost certainly offline and gives you the last time it was seen. An offline endpoint is a finding, not an error.

Guardian Runs on FabrCore — Our Own Agent Runtime

Guardian is built on FabrCore, the open-source .NET agent framework our team develops. FabrCore agents are not request handlers that spin up and vanish. They are long-lived, individually addressable actors with durable state, built on Microsoft Orleans.

That distinction is what makes a per-user guardian possible at all:

Why running the runtime ourselves matters

We could have rented an agent platform. We deliberately did not, and the reasons are the same ones our clients care about.

There is one more thing worth naming, because defence in depth is not a slogan here. The pin bounds what the agent may ask for. The platform's access guard checks the agent's own role on every call. The monitoring server refuses a device query that is not scoped to a customer. And a Microsoft Graph token minted for one tenant physically cannot read another. Four independent layers, any one of which would stop a mistake on its own.

In-Process Plugins vs. MCP Servers

Guardian's tools are in-process FabrCore plugins — ordinary .NET classes whose methods become tools the model can call, running inside the same process as the agent. The popular alternative right now is the Model Context Protocol (MCP), where tools live in a separate server the agent talks to over standard input/output or HTTP.

FabrCore supports both. It has been an MCP client since early this year, and we use MCP servers where they earn their place. But for Guardian, in-process plugins were the only defensible choice. Here is the honest comparison.

The row that decided it for us is tenancy scoping. An MCP server is a general-purpose tool provider by design — that generality is the entire point of the standard. A hypothetical get_user_signins MCP tool takes a tenant and a user address as arguments, because it has to work for anybody. That means the scope arrives as a string the model chose.

In an MSP, that is unacceptable. Two customers legitimately have identically named accounts; in a book of business, that is a certainty rather than a curiosity. Getting the boundary wrong does not produce an error — it produces a confident, detailed, internally consistent answer about the wrong company's employee, and nothing in the output would tell you.

There is a second, quieter benefit. Because the plugins run inside our application, they can return something better than raw data: they return judgment. A device that does not answer comes back as “probably offline, last seen at this time — this is a fact about the device, not a failure of the query.” A serial number that matches two machines comes back as both matches plus a warning that the serial is probably not unique on that hardware, rather than an arbitrary pick. A generic tool server returns a result or an error code. A plugin that lives inside the domain can hand the model the same context an experienced technician would have.

None of which is an argument against MCP. It is a genuinely good standard that solved a real problem — before it existed, every external integration meant writing yet another bespoke connector with its own authentication and error handling. When we want a third-party service or somebody else's product inside an agent, MCP is exactly the right tool and FabrCore connects to it in a few lines of configuration. It is the right answer for tools you did not write. It is the wrong answer for the boundary that separates one client's data from another's.

What This Means If We Support Your Business

Guardian is read-only. It cannot change an account, a device, a licence, a mailbox or a ticket. When something needs changing it says precisely what and who should do it, and a human does it. We think that is the correct place for the line right now, and we would rather explain a conservative boundary than a surprise.

This is the same philosophy behind everything we build: put practical AI where the work actually happens, keep it inside systems we own and operate, and be honest about its limits. Guardian watches one person at a time because that is the only scope at which the question “is anything wrong here?” has a real answer.