Simple Admins
Tenant administration from a Teams chat, with a seam before every write.
For Microsoft 365 tenant administrators and the IT leads who sign off on what an agent is allowed to change.
Tenant admins run the same thirty Graph tasks every week. Invite a user, license a seat, reset MFA, run a quarterly attestation. Simple Admins is being built as five Copilot Studio agents, Simple Identity Admin, Simple Access Admin, Simple Scripting Admin, Simple Network Admin, and Simple Security Admin, invoked in plain language from a Teams chat, with a human-approval seam before any write touches the tenant.
When you can get Simple Admins
Coming soonNot open yet. Tell us where to send word when it is.
What you can do now
Get product updatesNone of these creates an account, a trial, or access. Each one records what you asked for so a person can answer it.
Where this stands
- Availability
- Coming soon
What it costs
No published price yet. Pricing is set before this product opens.
Routes that are not open
- Direct trial with Simple Intelligence Not open yet
- Direct subscription from Simple Intelligence Not open yet
- Microsoft Marketplace Not published yet
- Sponsored subscription for member companies Not open yet
Two bad options, and they fail the same audit question.
A provider administering Microsoft 365 for dozens of customers either gives technicians standing privileged access across every tenant, and accepts that one compromised technician is every customer at once, or routes every routine change through a ticket queue, and accepts that offboarding a departed employee takes a day. The question an auditor eventually asks is not whether the change was correct. It is who authorised it, and neither option answers that well.
The approval goes before the write, and it is bound to the plan.
Simple Admins is being built so that no action executes until a named person approves the exact set of changes, with the approval bound to a hash of the plan rather than to the request that produced it. Changing the plan invalidates the approval. There is no configuration that expresses an ungated write, which is a deliberate absence rather than a setting nobody has turned on.
The rules are compiled, so the conversation cannot argue with them.
A declarative agent is a manifest and an instruction string interpreted by a model Microsoft hosts, so anything stated only in that instruction string can be talked out of it. The split here is that the agent owns understanding the request and phrasing the answer, and TypeScript with tests behind it owns deciding whether an action is permitted, what exactly it would change, and what evidence it emits. When somebody asks for a new rule, the question is which module enforces it.
What is built, and what is missing.
Simple Admins is code with tests, not a product anybody can install. The governed core is complete and covered, and the distance between it and a customer is now made of an application registration, a consent, a running endpoint, and a database, none of which exist. Nothing here has run against a live tenant.
Working today
- Ten administrative actions, each defined with its operation level, its Microsoft Graph calls, its preconditions, and its refusals, under a unit suite and a separate behaviour suite
- Five hard blocks the product ships no setting to relax, covering privileged role membership, tenant-wide authentication policy, audit records, unsigned scripts, and acting outside the authenticated delegated scope
- An approval state machine where a named person approves a plan bound to its own hash, with a second human gate in the customer's own Azure portal for the irreversible level
- A hash-chained evidence ledger with an append-only Postgres schema, a driver, and a migration runner behind it
- A multi-tenant fan-out that reads the provider's delegated administration relationships and dispatches a client per customer tenant
- Token validation that reads the caller's identity from a signed Entra token, with risk, revocation, and privileged-role activation state read from Identity Protection, the directory, and Privileged Identity Management
- A remote MCP server over HTTP, a health probe, a drain on shutdown, and a container that CI builds and starts on every run
- Marketplace fulfilment and metering clients, a landing page that signs a buyer in against their own tenant over OpenID Connect, and a webhook that verifies every notification against the service before it changes anything
Not yet
- There is no Entra application registration, so there is nothing for a customer's Global Administrator to consent to, and therefore no tenant any of this has run against. This is the single item everything else waits behind.
- No endpoint is deployed. The host process composes Microsoft Graph when it is given an application id, a provider tenant, a credential, and an authentication context, and refuses to start when it is given some of them. The only configuration it has ever run under serves a fixture directory and identifies nobody.
- No database is provisioned. A process started without one keeps approvals and evidence chains in memory and loses them on a restart, which is a development host rather than a deployment.
- Release of a quarantined email refuses at its transport, and it is the one action that will keep refusing. Microsoft publishes no API that releases a quarantined message: not Graph, not the Exchange Online Admin API, only a PowerShell cmdlet, which is a component this product does not have. That action points the technician at the Defender portal instead.
- The token validation is written and tested and answers nothing until four permissions are consented in the provider's own tenant. An unconsented deployment refuses every call, which is the correct behaviour and is not a running system.
- Nothing is published. No plan exists in Partner Center, the Copilot Agent Store and AppSource listings are planned rather than submitted, and nothing here can be bought.
- Agent 365 registration and Simple Council policy enforcement are the design target. Nothing connects this product to either today, and there are no calls to enforce against.
- Microsoft Foundry Agent Service and the Agent 365 SDK are a direction, not the build. No code here calls either.
Verified against the product on 2026-08-22.
Who this is being built for.
The twenty minutes after a mailbox is reported compromised
Block sign-in, revoke sessions, remove mailbox forwarding, remove a group member, restore sign-in once the account is clean. That is the second half of the action set, and it exists because those twenty minutes are when a governed agent is worth the most and an ungoverned one does the most damage.
The same change across every customer tenant you hold
One request planned across every tenant the provider has a delegated administration relationship with, presented as one approval card with the full impact summary before anything runs. Access is through those existing relationships rather than a private credential path, so a lapsed relationship stops the action rather than being noticed later.
Administering your own directory without standing privilege
One organisation governing its own tenant, where the point is not fan-out but that every write pauses on a named approval and produces an evidence record. The technician does not need a role assignment that outlives the task.
Answering the auditor without reconstructing anything
Every terminal outcome writes exactly one evidence event: refused, crashed, rejected, expired, blocked at the gate, failed partway, and executed. An approved plan still sitting on a card is not an outcome and writes nothing, which is what stops the ledger filling with intentions.
The flow the built core implements.
Ask in the place the conversation already happens
The surface is Microsoft 365 Copilot Chat and Teams. A technician describes what they need in plain language, and there is no separate portal to log into and no console to learn, because a portal is a losing shape against the tools these teams already have open.
The agent routes, the compiled code decides
Copilot works out which action is being asked for. The remote MCP server behind it works out whether that action is permitted, against the caller's validated token, the delegated scope, the preconditions on the action, and the five hard blocks. A refusal here is a code path with a test, not a sentence in a prompt.
A plan is built before anything is changed
The planned calls are assembled and shown as an impact summary: which tenant, which subject, which directory objects, and what each call would do. Nothing has been written at this point, and the plan is hashed so the approval can be bound to it.
A named person decides, on a card, with a way back
The approval card goes to a channel with a verified path back for the decision. Reversible writes take one approval. Irreversible or high-impact ones take a second human gate in the customer's own Azure portal, started manually, which is deliberately outside anything this product can trigger.
The outcome is recorded once, whatever it was
Execution, refusal, rejection, expiry, and partial failure each write exactly one event into a hash-chained ledger. Ids and the clock are injected rather than taken from the runtime, because an event id sits inside the hash and a session has to replay to the byte for the chain to be worth anything.
What the governed core actually does.
Nothing on this list is available today. This is the product we intend to build, written down so you can tell us whether it is the right one, and it will change.
Five refusals with no setting that relaxes them
Simple Admins never changes Global Administrator or Privileged Role Administrator membership. It never writes to a Conditional Access policy, an authentication methods policy, an authentication strength policy, or the security defaults policy, so tenant-wide multi-factor enforcement cannot be turned off or weakened by any configuration of this product. It never deletes or alters audit records, never executes an unsigned script, and never acts on a tenant outside the authenticated delegated scope. These are five compiled rules with a test each, not a policy document.
Four operation levels, and nothing sitting at level one
The levels run from a reversible write approved on a single card, through a hard-to-reverse write that carries an impact summary, to an irreversible one that additionally needs a second human in the customer's own portal. There is no read-only tier in the shipped set, because every action here is a write and the rule that every write is gated has no exception path to take.
Approval bound to the plan, not to the request
The approver sees the exact set of changes and the approval carries the hash of that set. A plan that changes after approval no longer matches, so the older and quieter failure, where a request is approved and something slightly different runs, does not have a path here.
Fail closed on every missing fact
A token with no authentication-methods claim has not proven multi-factor authentication. A revocation check that never ran is not a fresh one. Missing information refuses, because the forgiving reading is how an integration bug silently disables the security posture rather than announcing itself.
Application permissions, and the cost of that choice stated
Access to customer tenants uses application permissions rather than a delegated partner user, because writes execute long after the approver's session ends and the alternative credential is a standing refresh token with the same reach. The cost is real: Entra would stop issuing a delegated token when a relationship lapses, and here that property has to come from the relationship resolver running and being right. The permission argument is written out in the form a security reviewer reads, generated from source rather than restated.
Where it would run, and what it is allowed to touch.
The agent
A Microsoft 365 Copilot declarative agent, on the current manifest schemas, distributed to the Copilot Agent Store and AppSource when it is submitted. Its one action is a remote MCP server rather than an OpenAPI facade, which is the shape the portfolio rule requires when customer tenant data flows through an agent: tenant scoping is enforced inside the server rather than delegated to whatever is calling it.
The runtime
An MCP host on Azure Container Apps, reached through the Copilot plugin runtime with Entra single sign-on. The caller's identity is read from a signed token rather than trusted from the request, and the host refuses to start when it is given an incomplete configuration instead of starting in a weaker one.
The store
An append-only Postgres schema for approvals and the evidence chain. The posture is deliberately not zero-retention: an auditor is handed an export of that chain, so a retention floor is the thing being sold rather than a compromise. No server has been provisioned, and a process without one keeps its chains in memory.
The tenant boundary
Every action is scoped to a customer tenant reached through an existing delegated administration relationship, resolved at run time rather than configured. A tenant outside that scope is one of the five hard blocks, so the boundary is enforced in the same place as the rest of the refusals.
Microsoft surfaces, and nothing else.
A name here is a system this product is built to work with, not a promise that the connection is live in your tenant. Where a connector carries a status label, that label is the current state. Anything that needs its own vendor registration, its own consent, or its own approval says so, and nothing on this page can be taken as available until it is confirmed for your tenant.
Microsoft, and this is the whole list
Planned, not published
Needs your consent before anything happens
Reading data from an external system is not a way to sign in. Customer identity stays with Microsoft Entra ID, and no data source on this list authenticates a person.
Where each claim on this page comes from.
How ICM informs Simple Admins
Simple Admins answers Microsoft 365 administration requests inside Copilot Chat and Teams. Every one of its actions is a write to a live directory, so the plan a person approves is the artifact the whole design is built around.
Built, and verified against the product code
-
Context in
A request, and who is making it
The plan carries the requesting administrator's own identity and the tenant it applies to. The current time is passed in rather than read, so the same request produces the same plan when it is replayed in a test.
Gated
-
Retained or discarded
The plan, and the facts it relied on
A plan records the calls it would make, the impact in plain language, and how to undo it or why it cannot be undone. It also records the directory facts it was built against, which is what makes the recheck at the end of this list possible.
Gated
-
What the agent proposes
A plan, never an action
The ten verbs are all writes: offboarding, licence reclamation, MFA resets, temporary access passes, sign-in blocks, session revocation, mailbox forwarding removal, group membership. Nothing in the set is a read, and there is no configuration that expresses an exception to the approval rule.
Gated
-
Human review a person decides
Approval on a card, by a second person
The plan is rendered as an approval card showing the impact and the rollback. Self-targeting is refused: the person who asked for an action is not the person who authorises it.
Gated
-
Permitted effect
Preconditions are read again at release
The facts captured when the plan was built are reread and compared at the moment of execution. A directory that changed while the card was waiting causes a refusal rather than an action nobody approved against the state that now exists.
Gated
-
Evidence recorded
One evidence event per terminal outcome
Every path that ends, including refusals and failures, writes exactly one event into the chain. The chain answers which verbs ran, who approved them, and which refusals fired. The product also states, in the same place, which questions the chain cannot answer and where those answers live instead.
Gated
-
Failure and refusal
Hard blocks match on the call, not the intent
A frozen set of rules refuses certain actions outright, Global Administrator and Privileged Role Administrator membership among them. There is no register, no unregister, and no options argument, and the rules match on the Microsoft Graph surface a call touches rather than on what the model said it was doing, so a mis-described or injected instruction still trips them. The criteria start unmet and are only lifted by evidence: a count nobody took is not a count of zero.
Gated
These labels describe each step of this workflow on its own. They are not the availability of the product, which is the status shown at the top of this page.
This describes how the workflow is built. It is not a statement about availability, which is the status shown at the top of this page. ICM informs how context, review and evidence are designed here. It does not replace this product's database, its tenant isolation, its Entra identity, its audit tables, or its authorisation checks.
Methodology note
ICM was developed by Jake Van Clief and David McDermott. Simple Intelligence Group did not originate the methodology.
Simple Intelligence Group applies relevant ICM principles to context, provenance, traceability, human review, and workflow design.
Participation does not imply certification, endorsement, partnership, or an official ICM Architect designation.
What a security reviewer asks first.
Can we install this today?
No. There is no Entra application registration, so there is nothing for your Global Administrator to consent to, no endpoint deployed to receive a call, and no database provisioned to hold a decision record. Nothing here has run against a live tenant. The governed core is built and tested, which is a real position and is not the same as being installable, and this page is written to keep those two apart.
Where is the sign-in link?
There is not one, and there is not going to be one. Simple Admins is a Microsoft 365 Copilot declarative agent. The surface is Copilot Chat and Teams, so administration happens where the conversation already happens rather than in a portal a technician has to keep open. That is a design decision taken against the tools these teams already use, not a piece of the product that has yet to be built.
What stops somebody talking the agent into doing something it should not?
The agent does not hold the decision. It understands the request and phrases the answer, and the compiled server behind it decides whether an action is permitted, using the caller's validated token, the delegated scope, the preconditions on the action, and five refusals that ship with no setting to relax them. Prompt injection has nothing to talk out of a policy it cannot reach. The trade is that a rule can only be added by changing a module, which is deliberate.
Can it turn off multi-factor authentication?
It cannot write to a Conditional Access policy, an authentication methods policy, an authentication strength policy, or the security defaults policy, under any configuration. One narrower case is worth knowing about: resetting a user's authentication methods in a tenant that has no Conditional Access and no security defaults leaves that account on a password. That case is raised to the highest operation level and stated on the approval card rather than refused, so lockout recovery still works in small tenants, and the refusal above is worded to what the code actually enforces.
What does it cost?
The plan structure is settled internally and none of it is published, so there is no price on this page. No plan exists in Partner Center and nothing can be bought yet. When there is an offer, the intent is that a provider subscription transacts through the Azure Marketplace and counts toward the customer's Azure commitment, and that reading a customer directory to build a plan draws Copilot Credits from that customer's own pool, billed by Microsoft rather than by us.
Is this governed by Simple Council?
Not today. Council is running as its own product, and nothing connects this one to it, which is worth saying plainly because an earlier version of this page claimed otherwise. The design target is that policy decisions from Council sit in the path of an action here. There are no calls to govern yet, so that remains intent.
How do we hear when it is ready?
Ask for product updates through the form on this site, which records the request against Simple Admins specifically rather than a general list. There is no waiting list with a position in it, and there is no early access programme to apply to, because neither of those exists yet and inventing one would be the same defect this page was rewritten to remove.
What it sits next to in the portfolio.
Simple Admins sits beside SimpleOS rather than inside it. Where the suite runs a business, this one governs the Microsoft 365 tenant that business runs on, which is why its surface is Copilot rather than another application to sign into.
There is nothing to install yet, and we would rather say so here than in a demo.
The governed core is built and tested and the next thing to happen is an application registration, a consent, and a first tenant. If administering Microsoft 365 across customers is your problem, the useful thing right now is to tell us what your twenty-minute incident actually looks like, because that shapes which action lands next.