Theo works the identity alert queue your Microsoft 365 and Entra tenants already produce. It gathers the evidence, writes what it found, and proposes the containment. Containment is approval-gated by default.
The security incidents that land on an MSP are not exotic. They are a credential that got phished, a session that got stolen, an MFA prompt that somebody approved at the fourteenth attempt because they wanted the noise to stop.
The tenant usually tells you. Entra raises a risky sign-in, an impossible-travel detection fires, a mailbox rule appears at 2am. The alert exists. What is missing is somebody to work it in the twenty minutes that matter.
Theo works it. The evidence is gathered before anyone reads the alert.
An account authenticating from two continents inside an hour, or from a client app and location it has never used.
Entra has already scored it. The question is what the sign-in history around it looks like, and whether anything changed in the mailbox afterwards.
Repeated push denials followed by one approval. That pattern is a compromise, and it looks like nothing in a dashboard of counts.
Rules that move anything matching "invoice" or "payment" into a folder nobody opens. This is the step between access and fraud.
Mailbox-level or transport-level forwarding to an address outside the tenant, set quietly, often weeks before anything else happens.
Reading a sign-in log changes nothing, so investigation does not wait for anybody. Containment changes a client's tenant and locks a real person out of their work, so it does.
Identity alerts from Microsoft 365 and Entra, device alerts from Datto RMM and NinjaOne. Each one becomes a ticket in your PSA.
Sign-in logs, risk state, inbox rules, forwarding changes, session and MFA method inventory, and what the account can reach.
read-only · autonomousThe action Theo recommends, the scope, what it will do to the user, and the evidence behind it. Approve, change the scope, or decline.
approval-gatedWhat fired, what the evidence showed, what was contained, who approved it, and what is still open — in the PSA.
Most identity alerts are noise. Working them anyway is how you find the one that isn't — and a dismissed alert with the evidence attached is a decision you can defend later.
Revoke the sessions. Disable sign-in. Remove the malicious forwarding rule. Revoke the MFA methods that were registered by whoever is not the user. Done in the right order, that is the incident over.
Each one is staged with its scope and its evidence, and each one waits for a named approver. Revoking MFA methods is not reversible, and it keeps its gate in every configuration.
| Containment action | Reversible | Default |
|---|---|---|
| Revoke active sessions and tokens | Yes | Approval |
| Remove a malicious inbox rule | Yes | Approval |
| Remove external mail forwarding | Yes | Approval |
| Force a password reset | Yes | Approval |
| Disable sign-in for the account | Yes | Approval |
| Revoke registered MFA methods | No | Approval, always |
Reversible means a technician can restore the previous state. It does not mean the containment was free — a session revocation still signs somebody out of their day, which is exactly why a human decides.
A contained account with no written record is a problem you will have again, and an answer you will not have when the client, their insurer or their auditor asks.
Every read and every write, in order, with its arguments and its result. 100% of actions are logged, including the investigation steps that found nothing.
Containment carries the name of the person who authorised it. "The tool did it" is not an answer anybody accepts after an incident, and it is not one you have to give.
Per client, per date range, per incident. Attach it to a client report, an insurer's questionnaire or your own compliance file without rebuilding the timeline by hand.
Your client data is not used to train models. SOC 2 Type II — Trust Center. Data residency, retention window and the subprocessor list are in the trust pack we send before any pilot. Theo acts through the same delegated permissions your technicians use, scoped per client, and you can revoke access from your side at any time.
It is not a replacement for your security stack. If we are not clear about that now, you find out six weeks in, and that is a worse conversation.
Keep your SIEM, your EDR and your security partners. Theo works the queue they generate, on the identity side, where most MSP incidents actually start.
Not by default, on any client or any alert type. Containment is approval-gated, and revoking MFA methods is gated permanently because it cannot be undone.
Some MSPs eventually grant autonomy on session revocation for specific clients, because it is reversible and the cost of waiting is high. That is a decision you make deliberately, per client, after watching it work.
Investigation is read-only, so the cost of a wrong target is a wasted read rather than an incident. Theo resolves the alert to a real identity in the tenant before it starts, and the resolution is on the ticket for you to check.
Containment names the exact target and its scope at the approval gate, so a mismatch is visible before anything executes.
Yes. Theo does not ingest or retain log volume and does not do correlation or detection engineering. It consumes the alerts your stack produces. If you turned the stack off, Theo would have nothing to work.
Microsoft 365 and Entra for identity, Google Workspace for identity where that is the tenant, and Datto RMM and NinjaOne for device alerts. ConnectWise Automate and N-able are on the roadmap.
If your source isn't on that list, say so on the call and we'll be straight with you about timing rather than about intent.
The named approver. That is the point of the gate. Theo's job is to make the decision a ten-second one by putting the evidence and the recommendation in front of the right person; the judgement stays with your team.
Book 30 minutes. We'll look at the identity alerts your tenants generate in a typical week and which of them Theo should be working end to end.