Microsoft Azure
The cloud most Microsoft-centred enterprises are already standardised on — and usually the same place identity, files and line-of-business apps live.
The cloud most Microsoft-centred enterprises are already standardised on — and usually the same place identity, files and line-of-business apps live.
What Microsoft Azure holds, and why that matters here
In organisations built around Microsoft, Azure tends to be where more than the infrastructure sits: identity, storage and a good deal of the internal application estate are in the same tenant. That concentration is an advantage here, because one connection reaches a lot.
It also means the identity question is already answered. Where Entra ID governs who is who, an assistant can inherit that instead of maintaining a second idea of who may see what — which is the arrangement that ages badly everywhere it is used.
The questions are the same as any cloud: is it healthy, did it finish, what is it costing, which environment is this. The value is that they can be asked without a portal.
- Resource health — what is running and what is degraded.
- Deployment state — what shipped, when, and whether it succeeded.
- Storage — file presence and metadata within named containers.
- Cost management — spend by resource group or tag.
- Identity context — who the asker is, from the same tenant.
Questions Elbi can answer from your Azure subscriptions
Is this resource healthy?
Current state, in a sentence rather than a blade.
Did the deployment succeed?
Outcome and time, as recorded.
What is this resource group costing?
Spend for those entitled to see it.
Which environment is this?
The tags as recorded.
Where is that file?
Presence and metadata within allowed containers.
Is there an incident open?
What is declared, to stop duplicate tickets.
How Elbi reads from Azure
- A service principal in your tenantYour administrators register an application in Entra ID and create its service principal for the assistant. It authenticates with a certificate or client secret that you issue — Microsoft recommends certificates — and no other system or person uses it.
- Role assignments at the narrowest scopeAccess comes through Azure RBAC: the built-in Reader role on the resource groups that matter, Cost Management Reader where spend questions are in scope, and Storage Blob Data Reader on individual containers for file questions. Each role is assigned at the smallest scope that answers the question, not across the subscription by default.
- Control plane and data plane kept apartReader shows that a storage account and its containers exist, but not what is in them; reading blobs needs a separate data role. That split is useful here: the connection can report deployment and health state across a resource group while file access stays limited to the containers you name.
- The asker's groups narrow the answerWhere staff reach the assistant with the same Entra ID accounts they use for everything else, their group membership decides which answers they receive. The service principal sets the outer boundary for everyone; the groups narrow it per person.
- Three sources of health, kept distinctResource Health says whether an individual resource is available, Service Health reports Azure platform incidents affecting your subscriptions, and your Azure Monitor alerts cover your own applications. Keeping the three apart in an answer matters, because each points to a different owner.
- Anything that changes Azure stays with peopleRestarting an app, redeploying or scaling happens in the portal, the CLI or your pipeline, done by people entitled to do it. The read-only roles above cannot do any of those things, even by mistake.
Scope and control through Azure RBAC
| Direction of access | Read-only role assignments. Reader and Cost Management Reader cannot create, change or delete resources, and Storage Blob Data Reader cannot write or delete blobs. Any write capability would be a separate, deliberate decision with a role of its own. |
|---|---|
| Who can see what | The service principal's role assignments set the outer boundary. Within it, the asker's Entra ID identity and group membership decide what they are told. |
| Credentials | A certificate or client secret on an app registration you own. You set its expiry, rotate it, or disable the service principal from your side, and the connection stops without involving us or touching anyone's user account. |
| Where data goes | Values read from Azure answer the question that prompted them and nothing else. Message content is destroyed within 24 hours, usually once the conversation ends, and is never passed to an external AI service. |
| Audit | Azure's Activity Log records changes to resources rather than reads, so it shows little for a read-only connection. The service principal's sign-in logs in Entra ID show when it authenticated, and storage resource logs, if you enable them, record blob reads. |
| If it is unavailable | If Azure refuses a request, throttles it or cannot be reached, the assistant says so and offers a person rather than guessing. An expired certificate or secret is a common reason a connection that worked yesterday fails today, so its expiry date belongs in someone's calendar. |
What the Azure connection replaces
What this replaces is portal access as a prerequisite for asking a question. Giving everyone a portal login to look up a deployment status is the wrong answer — it widens access far beyond what the question needs, and it is the kind of thing that surfaces awkwardly in a review.
The usual alternative is worse in a different way: the question routes to whoever does have access, and the same handful of people spend their day reading screens aloud.
A scoped read sits between those two. The question gets answered, the access does not widen, and the audit trail shows exactly what was read and by whom.
Where the Azure connection earns its place
Microsoft-centred estates
One tenant, one identity model, one connection.
Engineering
Deployment and resource state without portal logins.
Operations
Health during an incident, in plain language.
Finance
Spend by resource group, on demand.
Internal IT
Fewer standing portal accounts to review.
Compliance
A scoped read is easier to defend than a broad role.
Getting value from the Azure connection
Start where Azure questions already pile up. In Microsoft-centred organisations they tend to arrive as Teams messages to whoever administers the portal: did the release go out, is the app down or is it just me, how much is this resource group costing. Counting those messages over a few weeks gives you the list to connect for.
Resource group design decides how clean the answers are. Where resource groups follow applications or environments, one role assignment covers one clear question — "is the HR portal healthy?" — and cost can be reported per group. Where everything shares a few large groups, tags have to carry that meaning instead, and tags on a resource group are not copied to the resources inside it unless something such as an Azure Policy rule does so.
Decide early whether health answers come from alerts or from raw metrics. Alerts defined in Azure Monitor already encode what your team considers a problem, so answering from them keeps the assistant's idea of "unhealthy" the same as your on-call engineer's. Reading metrics directly would mean the assistant applying thresholds that nobody agreed.
What connecting Azure involves
- Choose the subscriptions and resource groupsWrite each question against the subscription and resource group — or the single storage container — that holds its answer. Begin with one subscription; the rest can follow once it has been used.
- Register the applicationAn administrator creates the app registration and service principal in Entra ID, adds a certificate and records who owns it. Ownership matters: an app registration with no named owner is the one nobody notices when it should have been retired.
- Assign roles at the smallest scopeReader on the resource groups in scope, Cost Management Reader where spend is on the list, Storage Blob Data Reader on specific containers. The Access control (IAM) page of each scope shows the assignments, so the result can be checked where it was made.
- Map groups to kinds of answerDecide which Entra ID groups may hear which kinds of answer — cost only for finance and budget owners, for instance — so the rules are expressed in groups your administrators already manage.
- Test the edges before launchAsk about a resource group outside scope, a container that was never granted, a cost figure from someone outside finance. Each should be refused plainly, and the service principal's sign-ins should appear in Entra ID as expected.
- Widen by adding assignmentsExtending the connection later means adding a role assignment at a new scope, which your administrators review in the same place as the first ones.
Personal data, tenants and regions in Azure
Most of what this connection reads is metadata about resources — names, states, costs — rather than personal data. Two places deserve care: blob containers that hold customer documents, and resource or tag names that include an individual's name. Under the Saudi Personal Data Protection Law, containers holding personal data need a stated purpose before access is granted, and they are best granted one at a time.
Where data sits in Azure is set by the region you chose for each resource, and many organisations enforce that with Azure Policy's allowed-locations rules. The connection reads resources where they are; it does not change their region or copy them into another subscription. List the in-scope subscriptions and regions next to the role assignments so a reviewer sees both in one place.
Because the service principal lives in your tenant, the evidence a reviewer needs — its role assignments, its sign-ins, the storage logs — is held in your own Entra ID and Azure Monitor, not in a report from us.
What organisations typically see
How Azure questions are handled elsewhere
Microsoft's own route is the Copilot built into the Azure portal, which answers questions about resources and costs for people who are already signed in, within their own RBAC permissions. Azure Monitor can also send alerts through action groups to email, SMS or a webhook, which is how many teams get them into Microsoft Teams channels. Both suit people who already work in the portal.
Organisations building their own conversational layer on Microsoft's stack often use Copilot Studio or Azure AI Bot Service. That works, and it carries the same obligations as any in-house build: someone designs the permissions, handles Arabic and maintains it.
The in-house shortcut is to give more people the Reader role in the portal. It does answer the question, but Reader at subscription scope reveals the inventory of every resource in that subscription, and each extra person is another standing assignment to review.
The failure that recurs is scope creep through convenience: a role assigned at subscription or management-group level because it was quicker than choosing resource groups. Everything below that scope inherits the assignment, including subscriptions created later.
Common questions about the Azure connection
That is the right arrangement, and it is simpler here because the tenant already governs identity. The assistant inherits it rather than keeping a second list.
Yes, by default and by preference. Any write capability is a separate decision taken after the read has proved useful.
Yes, and we recommend starting there. Narrow scope makes the security review short.
Visible only to those already entitled to it. The assistant does not widen who can see spend.
No. Read at the moment of the question; no second copy to keep current or defend.
A single service principal, removed independently of anyone's user account.
No user account is involved. The service principal is created in your tenant by your administrators, holds only the role assignments you give it, appears in your own sign-in logs, and can be disabled without going through us.
Not with the roles described here. Reader cannot list storage account keys or read secret values, and no Key Vault access is granted at all. If a question seems to need a secret, it is the wrong question for an assistant.
Not by itself. Azure DevOps has its own permission model, separate from Azure role assignments, so pipeline status needs its own scoped access. Deployment history recorded in a resource group is readable with the Reader role.
Connect it to your own systems
A working assistant against your own records, in both languages.