ChatAdmin writes to your cloud. Here is everything that means, enumerated.
Most tools that look at Microsoft Azure estates are read-only, and their permission pages are short because there is little to declare. ChatAdmin creates and changes real resources, so this page has to work harder: for every capability, the resource type it touches, the operations it performs, whether it reads or writes, and why the permission exists at all. It is written from the code that ships, not from intentions.
It also states the two things a careful reviewer would find anyway: the automation identity currently holds a broader role than this list requires, and the audit trail does not yet record which human approved a change. Both are below, undressed.
The capability list
Every operation ChatAdmin can perform against Azure today. Reads run without interruption; every write goes through the approval gate first, no exceptions. Nothing on this page deletes anything — the current implementation contains no delete operation of any kind.
| Capability | Azure resource type | Operations performed | Read / write | Why it needs this |
|---|---|---|---|---|
| List resource groups | Resource groups Microsoft.Resources/resourceGroups |
List all resource groups in the subscription | Read | A conversation about an estate has to start from what actually exists, not from memory. |
| List resources in a group | Resources within a resource group Microsoft.Resources (list by group) |
List name and type of each resource in a named group | Read | “What is inside rg-x?” is the most common question before any change is proposed. |
| Resource group | Resource groups Microsoft.Resources/resourceGroups |
Create or update a resource group (name, region) | Write | Every other resource below must live in a resource group; this is the container everything else depends on. |
| Storage account | Storage accounts Microsoft.Storage/storageAccounts |
Create or update an account (name, SKU, kind, access tier). Does not read or write the data inside an account, and does not fetch access keys. | Write | Provisioning storage is a baseline task of building an environment; touching the data inside it is not, so that part is absent. |
| Key vault | Key vaults Microsoft.KeyVault/vaults |
Create or update the vault resource itself, with RBAC authorization on by default and an empty access-policy list. Does not read, write, or list secrets, keys, or certificates inside any vault. | Write | Environments need somewhere for their secrets to live. ChatAdmin builds the vault and stops at its door. |
| Virtual network | Virtual networks and subnets Microsoft.Network/virtualNetworks |
Create or update a virtual network with its address space and subnets. Caution it declares to the user: this is a whole-network update, so a subnet omitted from the request is removed by Azure — the tool documents this instead of hiding it. | Write | Compute cannot exist without a network to attach to. |
| Virtual machine | Virtual machines (Linux) Microsoft.Compute/virtualMachines |
Create or update a Linux virtual machine (size, image, admin user, SSH key or password). Requires a pre-existing network interface and does not create network interfaces or public IP addresses. Credentials supplied for the machine are never logged, audited, or returned. | Write (billable) | Standing up compute is the point of an environment; creating its network entry points is deliberately left as a separate, visible step. |
| Log Analytics workspace | Log Analytics workspaces Microsoft.OperationalInsights/workspaces |
Create or update a workspace (retention, pricing tier). Deliberately does not fetch the workspace's shared keys — that is secret material and the code refuses to retrieve it. | Write | Container environments need a log destination; the workspace ID it returns is a non-secret identifier. |
| Container Apps environment | Container Apps managed environments Microsoft.App/managedEnvironments |
Create or update a managed environment, optionally wired to a Log Analytics workspace. A workspace key supplied by the user is masked on the approval card, excluded from the audit log, and never echoed back. | Write | A container app must run inside a managed environment; this is its host. |
| Container app | Container apps Microsoft.App/containerApps |
Create or update a container app (image, port, ingress, CPU, memory, replica bounds) and return its public URL. Defaults to scale-to-zero so an idle app costs nothing. | Write (billable running compute) | Deploying a running service is the end-to-end deliverable the rest of the list builds toward. |
Declared but not implemented, and refused outright
The codebase names further actions that have no live implementation: deploying ARM or Bicep templates, validating template parameters, tag-compliance checks, compliance reports, diagnostics, dependency analysis, and a backend-environment orchestration. Invoked, they return a clearly marked “not implemented” result and make no Azure call; they are also not offered as tools in the conversation. One governance check — naming-convention validation — is real but purely local: a pattern match that never contacts Azure. When any of these becomes live, this page changes first.
Separately, four things are refused by guardrails before any Azure call is attempted, regardless of how the request is phrased:
- Calling the commercial marketplace API or touching marketplace data — out of this agent’s authority entirely.
- Creating or modifying identity credentials: app registrations, service principals, client secrets, certificates.
- Outputting private key, certificate, or token contents, in any form.
- Contacting any endpoint that is not an Azure or Microsoft Entra host.
The approval gate: the compensating control for a tool that writes
Before any write in the table above runs, ChatAdmin stops and shows a person an Approve / Reject card: the action name, every parameter (with passwords, SSH keys and workspace keys masked), and the target subscription. Then it waits. If nobody answers within five minutes, the action is declined automatically — the gate fails closed, never open, and in the browser interface there is no auto-approve of any kind. Stated for completeness: the terminal interface used by whoever operates the agent from its own console has an explicit --yes flag that skips the gate — its own help text marks it dangerous, and the browser flow has no equivalent. A declined or timed-out action is final for that request; the agent is instructed not to retry unless asked. Read-only listing does not pass through the gate, so looking around never generates approval fatigue.
The identity it runs as
ChatAdmin has two sign-in modes, selected by deployment configuration. The default is a certificate-based service principal: authentication uses a certificate whose private key is held on the runtime host, in the machine’s certificate store or a key file — no passwords and no client secrets exist anywhere, but key material does exist on that host and must be protected there. The second mode, built for deployments hosted inside Azure, is managed identity: the platform issues the tokens and no credential is stored in the container image, in configuration, or on disk. In either mode, tokens are short-lived, cached only in memory, and never logged, printed, or included in errors. Whatever the conversation asks for, the agent can only ever do what Azure’s role-based access control grants the identity in use — which is exactly where the honest part comes next.
The part we are not yet happy with, stated before you find it
The identity currently holds Owner, and that is too broad
ChatAdmin’s automation identity holds the Owner role on the subscription it runs against. That is far more than the table above requires — Owner can do things this agent will never be asked to do. The least-privilege design intends a narrower role, and which role that should be is an open, undecided question: the operation list above is the input to that decision, and we would rather publish the list and the open question than a tidy answer we have not actually implemented. Two mitigating facts, for what they are worth: ChatAdmin has only ever run against Neopiq’s own subscription, and every write still passes the approval gate.
The audit trail does not record who approved
Every action is logged as structured JSON — timestamp, operation, target resource, result, with secret material redacted before writing. What the log does not contain is which human clicked Approve. Today, with no sign-up, no login and a single operating team, the answer is knowable outside the log; in any multi-user deployment it must be in the log, and that is a known gap to close before one exists.
If you review tools like this for a living and want to argue with any of it — the scope, the gate, the role question — that argument is welcome: write to us.
The rest of the security story
Permissions are one chapter. Architecture, data handling, vulnerability reporting and the certifications we do not hold are on the security page.