Pillar 1 · ChatAdmin · built and running today · not open for sign-up
You say what you want. You do not go and find where it lives. Ask for a resource group, a storage account, a virtual network, a key vault, a Log Analytics workspace or a Container App and ChatAdmin works out the calls, chains the steps and feeds each result into the next. It looks things up without interrupting you. Before it changes anything it stops, shows you the exact call it is about to make, and waits for Approve or Reject. If nobody answers, it declines. Every action goes into an audit trail.
The model is that ChatAdmin executes inside your own Azure subscription — your tenant, your identity, your audit trail, nothing about your estate exported to us. What is demonstrable today is the same agent running against our subscription. Those are two different sentences and this page keeps them apart: the design is on this page under where it is designed to run, and everything that is not true yet is under what is deliberately not true yet.
The interface is the product decision, not a wrapper around one. This is a comparison of two interaction models, not a claim that one tool is better than another — the Azure and Microsoft 365 admin portals are comprehensive, and ChatAdmin is not.
If you administer Azure all day and know exactly where everything lives, a portal is a fast tool and we are not going to pretend otherwise.
The honest summary: a portal is better when you are exploring, and a chat is better when you already know what you want and would rather say it once than click it eleven times. What ChatAdmin cannot do yet is the other half of that sentence.
Everything in the first block has been executed against a live Azure subscription. The rest is listed because the agent advertises the action — and then refuses to do anything useful with it. Saying so here is cheaper than letting you find out.
| What you can ask for | Status | Notes |
|---|---|---|
| List resource groups and resources | Running today | Read-only, so it answers immediately — no approval card, because nothing changes |
| Create and manage resource groups | Running today | Behind the approval gate |
| Storage accounts | Running today | Behind the approval gate |
| Virtual networks and subnets | Running today | Behind the approval gate. Subnets you leave out of the request are removed — the tool description says so, and it is still a sharp edge |
| Key vaults | Running today | Behind the approval gate. It manages the vault; it does not read secrets out of it |
| Log Analytics workspaces | Running today | Behind the approval gate |
| Container Apps and their environments | Running today | Behind the approval gate. This is the one that shows what the chat buys you — a whole environment chained from one instruction |
| Virtual machines | Written, never run live | The code exists and is tested by construction, but no VM has been created by it. Until one has, we are not calling it a capability |
| ARM and Bicep template deployment | Not implemented — stub | The action name exists. There is no implementation behind it |
| Governance — tagging, naming, compliance reporting | Not implemented — stub | Same: named, not built |
| DevOps — environment build, diagnostics, dependency analysis | Not implemented — stub | Same: named, not built |
| Power Platform administration | Not started | No code at all. It is the next admin domain, not a feature |
An agent holding cloud credentials is only as good as what it does when nobody is watching. That is the question this design answers first, and everything else is downstream of it.
Every mutating call stops and raises an Approve / Reject card. The agent loop waits — it does not carry on and reconcile later. If the card is left unanswered for five minutes it is automatically declined and the change does not happen.
Nothing is ever auto-approved. There is no “trusted action” list that skips the card, and no confidence score that lets the model decide it is probably fine.
Verified rather than asserted: an approved change created a real resource group in a real subscription, driven from the browser over the public internet. The decline and time-out paths are covered by the approval-loop tests that ship with the agent.
Looking up what exists runs straight through — you are not clicking Approve to ask a question. The gate sits precisely where the risk is, so it stays meaningful instead of becoming a habit you click past.
The card shows the action and its parameters, so you are agreeing to a specific change to a specific resource. Password and key parameters are masked in the card, and capability results redact secrets before anything is returned or logged.
What was asked for, what was approved or declined, and what the platform did. What it does not yet record is which signed-in person approved it — because there is no sign-in yet. That is honestly a gap, and it is named again below.
This is the architectural model, and it is the reason ChatAdmin sits at Level 2 on our ladder. Administering a cloud means acting inside it, so the agent goes to where your resources already are rather than reaching across a boundary to manage them from outside.
Status: this is the design. No customer deployment exists, no installation mechanism exists, and the least-privilege role it would ask for has not been decided.
The same agent, the same approval gate, the same capabilities — running against our own Azure subscription. It authenticates by managed identity and drives real ARM calls, so the mechanism is real rather than mocked.
That demonstrates the mechanism. It does not deploy the model. No customer subscription has ever been connected to it, and there is nothing to connect one with: pointing ChatAdmin at your tenant needs sign-in, tenant separation and a role definition, and none of those exists.
We would rather you read that sentence here than infer the opposite from a page that only talked about the design.
[PLACEHOLDER: how ChatAdmin would actually be installed into a customer subscription — a container app the customer deploys, a Marketplace offer, a managed application, or something else. This is the decision that turns the model on this page into a product, and it has not been made.]
[PLACEHOLDER: which Azure scope a customer deployment would be offered at — a whole subscription, a single resource group, or a management group — and the exact role definition it would ask for. Undecided, so unstated.]
[PLACEHOLDER: where the LLM inference happens in the customer-subscription model, and what leaves the customer's environment to make the conversation work. It is the first question a security reviewer will ask about a chat that runs inside their tenant, and it has not been answered.]
There are none in the container. The hosted agent authenticates to Azure by managed identity — the platform hands it a token, so there is no certificate, no client secret and no key file baked into the image to leak, rotate or lose. An earlier design put a certificate inside the container; it was rejected for this one.
The running instance reports its own auth mode, subscription and tool list over an information endpoint, so the claim on this page is checkable rather than asserted.
We are not publishing that URL here. The deployment has no login yet, so an address on a public page would be the access control — which is exactly the sort of thing this page criticises.
The limits are enforced outside the model, in the dispatcher that every action has to pass through, not by asking the model nicely in a prompt. Out-of-scope actions are refused before any Azure call is made.
Concretely: it will not reach the commercial Marketplace API, it will not mint or hand back credentials, and it will not disclose secret material — not in a chat reply, not in a tool result, not in the audit log.
It also has a dry-run mode in which it does the whole conversation and the whole approval flow and performs no network calls at all.
This is the part most vendors leave out. Read it before you read anything else on this page a second time.
In the order it has to happen, not in the order that sounds best. Every item below is unbuilt.
Sign-in on the chat, then the audit trail recording which signed-in person approved which change. Those two are one piece of work, and they are what turns a running deployment into something a stranger could be allowed near.
Status: identified and pending. Not started.
Turning the design into something a customer can actually run: an installation route, tenant separation, and a least-privilege role instead of Owner. This is the difference between a demonstration and a product, and it is not crossed yet.
Status: the deployment route and the permission model are both open decisions.
The intended next domain after Azure: environments, connectors, policies and the ownership questions that go with them. It is named here as a direction so you can judge where this is heading. No part of it is implemented.
Status: not started.
[PLACEHOLDER: which further admin domains follow Azure and Power Platform, and in what order. The owner describes “further admin domains later” without naming them, so none are named here.]
[PLACEHOLDER: the commercial model for ChatAdmin — per subscription, per administrator, per approved change, or a flat subscription. It is undecided, and it is the decision that unblocks the pricing page.]
[PLACEHOLDER: whether to publish a target date for customer onboarding. There is none today, and a date here would be the first unverifiable statement on this site.]
In the meantime the thing you can actually run is on the other pillar: the free D365 check. It needs no account and transmits nothing, and it is the only part of Neopiq a stranger can use unaided today.
We would rather say that plainly than take a sign-up from you for something that has no login, no tenant separation and no way to reach your Azure. When that changes, this page changes first.
If you want to be told when it opens, or you would rather argue with the design before it ever comes near your subscription, contact@neopiq.ai reaches a person — and so does 0041 78 223 6716.