Microsoft Entra ID
Identity is not a source of answers — it is the thing that makes every other answer safe to give. Without it, an assistant is guessing who it is talking to.
Identity is not a source of answers — it is the thing that makes every other answer safe to give. Without it, an assistant is guessing who it is talking to.
What Microsoft Entra ID holds, and why that matters here
Entra ID is where most large organisations keep their directory: who works here, which groups they belong to, and what they are entitled to reach. It is the foundation an assistant needs before it can answer anything personal.
The distinction matters. Connecting a system of record lets the assistant retrieve a fact. Connecting identity lets it know whether the person asking is entitled to that fact — and those are entirely different problems.
- Users — who exists and their attributes.
- Groups — the membership that usually drives entitlement.
- Sign-in — the authentication your organisation already uses.
- Roles — administrative and application permissions.
- Conditional access — the policies that govern when access is allowed.
Questions Entra ID lets Elbi answer
Who is asking?
Established from your existing sign-in rather than from questions in a conversation.
What may they see?
Group and role membership, which determines what the assistant may disclose.
Is this person in this team?
Directory questions employees currently ask a colleague.
Who is my manager?
Directory relationships, asked constantly in large organisations.
Who owns this?
Ownership attributes for internal routing.
Is this person still with us?
Account state, which prevents disclosure to departed staff.
How Elbi works with Microsoft Entra ID
- An app registration in your own tenantYour Entra administrator registers Elbi as an application in your tenant. Everything about the connection lives on that registration: the redirect address for sign-in, the permissions granted, and the credential the application authenticates with.
- Sign-in through Entra, with your policies appliedStaff sign in on the standard Microsoft sign-in page, over OpenID Connect or SAML. Multi-factor authentication, Conditional Access and any other policy you attach to the application run exactly as they do for your other applications, and Elbi never handles a password.
- Group or role claims decide entitlementThe token Entra issues can carry the person's group memberships, or app roles you define on the registration. App roles are often the cleaner choice: you assign them to users or groups in Entra, and Elbi reads a short, meaningful list instead of every group someone happens to be in.
- Directory questions through Microsoft Graph"Who is my manager" or "who sits in the finance team" is answered from Microsoft Graph. The read permissions involved are granted by an administrator through admin consent and limited to what the agreed questions need.
- Account state follows the tenantWhen an account is disabled or its sessions are revoked in Entra, new sign-ins fail and no new tokens are issued. Keeping Elbi's own sessions short means that change reaches the assistant promptly rather than at the end of a long session.
- Nothing is written back to the tenantElbi does not create users, change group membership or reset passwords. Those stay with your administrators and with Entra's own self-service tools.
Scope and control in your Entra tenant
| Direction of access | Read-only against the tenant: sign-in tokens plus a narrow set of directory reads. No user, group or policy is modified. |
|---|---|
| Who can see what | Entitlement comes from the group or role claims Entra issues for the signed-in person. Requiring user assignment on the enterprise application also limits who can sign in to Elbi at all. |
| Credentials | The registration authenticates with a client secret or certificate you create in the Entra admin centre. Both carry expiry dates; you rotate them on your schedule, and deleting the credential or disabling sign-in for the enterprise application cuts the connection at once. |
| Where data goes | Claims and directory attributes are used for the question in front of Elbi. Message content is destroyed within 24 hours — normally when the conversation closes — and is never passed to an external AI service. |
| Audit | Entra's sign-in logs already show every sign-in to the application and the policies applied to it. Elbi's own lookup records can add which directory details were read, and for which conversation. |
| If Entra is unreachable | Elbi answers only what needs no identity and says why. It does not treat an earlier token or a remembered group list as current. |
What this replaces
The security value here is the important part. An assistant that establishes identity through your own authentication cannot be talked into disclosing something by a persuasive message, because entitlement is determined before the conversation rather than during it.
This is the control that makes everything else defensible. Connect a payroll system without identity and you have built a disclosure risk. Connect it with identity and the assistant simply cannot show someone another person's record, regardless of what they claim.
The maintenance benefit matters too. Entitlement is managed where it already is — in the directory — rather than in a second permission model inside the assistant that would inevitably drift out of step with the first.
Who connects Entra ID first
Any large enterprise
The foundation for every internal assistant use case.
Microsoft-centred organisations
Identity already exists; nothing new to maintain.
Regulated sectors
Entitlement established outside the conversation, which is the auditable position.
Multi-entity groups
Group membership driving what each population may see.
Getting value from Entra ID
Entra ID answers "who is this, and what may they see" for everything else Elbi connects to, so the first value usually shows up on another system's page: HR, IT service management, finance. Choose the one internal question that currently needs a person to check who is asking — a leave balance, the status of a ticket, a purchase approval — and make Entra the gate for it.
The next step is deciding what entitlement means in your tenant. Most tenants hold a large number of groups, many created automatically whenever a team or Microsoft 365 group is set up. Tying Elbi's rules to those makes the rules unreadable. A handful of app roles — employee, line manager, HR, finance — assigned to a few well-owned groups keeps the logic legible to whoever audits it.
Only then is the directory itself worth asking. Manager, department and office location are among the attributes staff query most, and they are only as reliable as the process that feeds them. If Entra is populated from an HR system, check that the sync covers those fields before promising answers from them.
What connecting Microsoft Entra ID involves
- Register the applicationAn administrator with the appropriate Entra role creates the app registration, enters the redirect address Elbi provides, and chooses OpenID Connect or SAML for sign-in.
- Grant the minimum Graph permissionsRead access to users and group membership is usually enough. Each permission is listed on the registration and needs admin consent, which gives your security team a concrete list to review.
- Decide who may use itTurn on assignment required for the enterprise application and assign the pilot group. Everyone else is refused at sign-in by Entra itself, before Elbi is involved.
- Define roles and check the tokenCreate the app roles Elbi's rules will use, assign them, and confirm the token carries them. Where someone belongs to a very large number of groups, Entra leaves the group list out of the token and points to Graph instead — another reason to prefer app roles.
- Bring it under Conditional AccessInclude the application in the policies that should govern it — multi-factor authentication, compliant devices, blocked locations — and test that a sign-in outside those conditions is refused.
- Rehearse the leaver pathDisable a test account and revoke its sessions, then confirm Elbi stops answering personal questions for it. It is the scenario auditors ask about first.
Entra ID data and the PDPL
Entra ID holds personal data on every member of staff: names, sign-in names, email addresses, job titles, managers, phone numbers registered for multi-factor authentication, and sign-in logs that record IP addresses and approximate locations. Under the Personal Data Protection Law, reading any of it is processing, and the purpose needs to be stated.
The practical control is the permission list on the app registration. Elbi needs the signed-in person's identifier, display name and entitlement, and for directory questions a few organisational attributes. It has no reason to read authentication methods, sign-in logs or guest invitations, and those permissions should simply not be granted.
Guest accounts need a separate decision. Contractors and partners invited into the tenant appear alongside staff, and whether they may use an internal assistant — and what it may tell them — is a policy question to settle before the pilot, not after the first guest asks.
What organisations typically see
How Microsoft's own assistants and others use Entra ID
Microsoft 365 Copilot and agents built in Copilot Studio use Entra ID natively: they sign people in with the same identity and respect Microsoft 365 permissions. For content and workflows that live inside Microsoft 365, that is a natural fit and a sensible default.
An assistant such as Elbi tends to be considered where the answers come from systems outside Microsoft 365 — an HR platform, an ERP, a service desk, a line-of-business database — or where the same assistant serves staff and the public. Entra's role does not change in that case: it remains the identity provider, and Elbi is one more application that trusts it.
What no option should do is keep its own list of who may see what. Chat tools that store user roles separately from the directory reproduce the drift Entra exists to prevent, so the useful comparison between options is how completely each one defers to the tenant.
Common questions
No — it answers within the permissions the person already has. Someone who cannot see something in your systems cannot see it through the assistant.
No, and you should not. Entitlement stays in the directory, which is the only place it can be maintained reliably.
Entra ID covers your workforce. Customer identity is handled by whichever system you use for it.
No. An administrator consents once to a short list of read permissions; the application itself holds no administrative role.
Yes. Sign-in happens in Entra, so the policies assigned to the application are enforced there, before Elbi receives anything.
Disable sign-in for the enterprise application or delete its credential. Either takes effect in your tenant without going through us.
Let Entra ID decide what Elbi may say
One sign-in for staff, and answers in Arabic and English within the roles your tenant already assigns.