Meet Sia, the Ultimate AI Agent for Workspace Automation

Today we are shipping the Microsoft 365 integration for Sia. SIA, Scogo's IT-operations agent, now runs Microsoft 365 administration from a single instruction, through the Sia CLI and the Sia Desktop App: onboarding and offboarding, licenses, mailboxes, groups, and access policy, executed against Microsoft's own admin APIs, verified at the end, and written to a signed audit trail. You ask in plain English, from the terminal or the desktop app. Sia does the work, confirms the result, and leaves a record. No portal clicking. No ticket queue.

This is a big one, and not because Microsoft 365 is one more logo.

Microsoft 365 is not a device. It is a stack of consoles: the Microsoft 365 admin center, the Exchange admin center, the Entra ID portal, the Teams admin center, the SharePoint and Purview hubs. Every one of them is a separate place your team logs into to do a small, repetitive thing to one user. That is the work we are taking off your team's hands.

We ship integrations the same way every time. Prove the concrete, high-volume workflow first, put our name on it, then roll out the rest of the surface through the same connection. For Microsoft 365 the proven anchor is identity lifecycle: onboarding and offboarding a user end to end, conversationally, with the result verified and logged. The broader admin surface runs on the same plumbing and is rolling out behind it.

This post is for the people who live in these portals: the service-desk techs onboarding hires and resetting passwords, the admins reclaiming licenses and chasing shared-mailbox permissions, the security and compliance owners who have to prove who changed what. Here is what just changed for you.

Why Microsoft 365 admin work resisted automation this long

Microsoft 365 administration is repetitive, spread across a dozen consoles, and unforgiving on the tasks that touch access.

Every org has the same shape. A new hire needs an account, a license, group memberships, and first-login policy. A departing employee needs the account disabled, sessions revoked, the mailbox converted to shared, and the license reclaimed before it keeps draining the bill. A contractor's access window closes. A password gets forgotten. Multiply each by every person in the company and you have a full-time queue that never empties.

None of these tasks is hard. A human in IT can do any one of them in a few minutes. The problem is that they have to do all of them, for everyone, all day. The bottleneck was never capability. It was availability, and the friction of clicking the same screens over and over.

Teams that tried to automate their way out ran into the usual wall. PowerShell and the Graph SDK can do almost anything in Microsoft 365, but someone has to write, test, and maintain the scripts, and hold the credentials they run under. Power Automate covers the no-code cases until the flow you need isn't in a template. Point-and-click portals don't script at all. So most of the work stayed manual, and the parts that got automated turned into a pile of scripts only one person understands.

How Sia drives Microsoft 365

One engine, reached however your team already works: the Sia CLI in the terminal, the Sia Desktop App, or as tools exposed to any MCP-compatible orchestrator.

Underneath, Sia talks to Microsoft 365 through Microsoft's own admin APIs. Entra ID for accounts, groups, and conditional access. Exchange Online for mailboxes and delegation. The licensing and usage endpoints for assignment and reclamation. Where an admin task has no clean API, Sia falls back to driving the admin center's web UI directly, the same way it drives any console. Either way, you don't touch the portal.

The interaction is conversational, but the execution is not a guess.

"Onboard sachin.tendulkar@company.com. Assign an E5 license, add to the Sales group, enforce password reset on first login."

Sia creates the account in Entra ID, assigns the license, adds the group, applies the first-login policy, then returns verified state: account active, license assigned, groups confirmed. If any step fails, it stops, reports exactly what it saw, and changes nothing further. It does not half-onboard a user and move on.

Built for people who have to prove what happened

Identity work is exactly where "an AI did something to my tenant" gets nerve-wracking. Disabling an account, reclaiming a license, revoking sessions, editing conditional access. These are the changes an auditor asks about later.

So the same governance that lets Sia act on production networks applies here. Every action Sia can take runs through a mutation gate with three verdicts: allow, require approval, or block. Sensitive changes queue for a human to approve before they run. Destructive operations are blocked outright. And every action, approved or automatic, is written to an append-only, HMAC-signed audit log that exports with its signatures intact.

That last part matters more for Microsoft 365 than for almost anything else. When compliance asks who deprovisioned a departing employee, when their access was revoked, and whether the license was reclaimed, the answer is a query against a signed record, not an afternoon of stitching together portal audit logs.

This is automation with a seatbelt, not click-and-pray. It is the difference between a demo and something you let touch your production tenant.

What you can automate

The integration targets the full Microsoft 365 admin surface. Because Sia maps natively to the core Microsoft 365 APIs, the entire administrative matrix below, from mailbox governance to license reclamation, is driven by the same engine today. Identity lifecycle is generally available now; the rest is staging across customer tenants.

Identity and access

Mailboxes and collaboration

Licensing, compliance, and reporting

Identity lifecycle is what we hardened and proved out first, so it is generally available now. Everything else in the matrix runs on the same native API mapping and the same governed engine, fully supported today and deploying across our tenant cohorts.

The flagship: a full user lifecycle, end to end

Here is the workflow that anchors the integration, exactly as it runs. A user onboarded from nothing to fully provisioned, then, months later, offboarded cleanly, with both ends of the lifecycle verified and on the record. No admin opening a single portal.

The full lifecycle, onboarding to offboarding, with no admin touching a portal. The step-by-step below annotates what you are seeing.

Onboarding. One instruction:

"Onboard sarah.chen@company.com. E5 license, add to the Sales and All-Staff groups, enforce password reset on first login."

Sia creates the account in Entra ID, assigns the E5 license, adds both group memberships, applies the first-login password policy, and returns verified state: account active, license assigned, groups confirmed, policy applied. Elapsed time is seconds, not a three-day ticket.

Offboarding. Months later, one instruction:

"Sarah is leaving Friday. Disable the account end of day, revoke all access, move the mailbox to shared, reclaim the license."

Sia disables the account on schedule, revokes every active session and token, converts the mailbox to a shared mailbox so the team keeps the history, reclaims the E5 license back into your pool, and returns an audit confirmation: account status, access revoked, mailbox converted, license reclaimed, timestamp on each.

The operator's whole job was to state intent twice. Credentials never appeared in the prompt or the logs. And the entire lifecycle, both ends, sits in the signed audit trail if anyone ever asks.

The work moves up a level

The work does not disappear. It moves up a level, and it moves off IT's desk where it should.

Instead of a service-desk tech clicking through onboarding screens per hire, an agent runs the checklist and an engineer reviews exceptions.

Instead of a license nobody remembered to reclaim quietly draining the budget for months, the license comes back the moment the offboarding instruction runs.

Instead of compliance treating an access audit as a project, the record is a query.

And because identity work becomes a sentence anyone authorized can say, it stops being locked behind admin availability. A manager can onboard their own report. HR can trigger an offboarding. Not because access control disappeared, but because Sia runs inside role-based scope, so the permission model moves from "a human clicking with admin rights" to "an agent acting within a policy you set." IT stops being the queue and goes back to owning security posture and the hard cases.

Why we ship integrations this way

Microsoft 365 is one large surface. The estate is everything else: the firewalls, the switches, the servers, the cloud accounts, the storage, the endpoints, the service desk. Scogo already reaches across that estate through Agent Fabric. What we do with each integration is go surface by surface, prove Sia can drive it to production standard, then put our name on it.

That is the whole strategy, stated plainly. Every named integration takes a class of admin work off your team's hands and makes Sia the place that work runs. Microsoft 365 is one of the biggest of those surfaces, which is exactly why we anchored it on the workflow that has to be right every time before claiming the rest.

Availability

The Microsoft 365 integration is in Sia now, across the Sia CLI and the Sia Desktop App, with identity lifecycle generally available and the full admin matrix engine-supported and deploying across customer tenants. We deliver Sia as part of the Scogo platform to enterprise customers, so there is no public download.

If you run Microsoft 365 across a real org and your team is spending its days in the admin center, we want to put Sia in front of your tenant. Start with a pilot at scogo.ai/request-demo.

Autonomous where it is safe, governed where it matters, on the record everywhere.