Role-based AI with Microsoft Entra ID – how access works

Single sign-on (SSO) proves who the user is. It does not automatically determine what an AI solution is allowed to display or do. For corporate use, an authorization model is needed that links identity to function, data source, and action.

Microsoft Entra ID can be used for login, groups, roles, and life cycle. The platform then needs to translate the identity into concrete access decisions before each information retrieval and tool call.

What is RAG? How companies use their own data in a language model

Four levels of access

Platform level

Is the person allowed to log in and use the service?

Function level

Is the person allowed to use a specific assistant, agent, model, or administrative function?

Data level

Is the person allowed to retrieve information from the current source, folder, or document?

Action level

A fourth level becomes important for agents: action level. Is the user or service role allowed to create, modify, send, or delete information in a connected system?

Login shows who the user is. The authorization model determines what the solution is allowed to display and do.

Identity via Microsoft Entra ID

When the user logs in, Entra ID issues a token with information about identity and allowed claims. The application validates tokens and uses the identity for further decisions.

Single sign-on (SSO) reduces the need for separate passwords and makes it possible to apply the organization's authentication requirements, such as multi-factor and conditional access. It also simplifies de-registration when employment ends.

The platform should not rely on information that the user writes in a prompt. Identity and roles must come from trusted authentication and be checked on the server side.

Read more about security in the Violet AI Platform

Groups and roles

Entra groups can represent organizational affiliation, projects, or access packages. Application roles describe what the user is allowed to do in the platform. Microsoft documents how role-based access is used to assign permissions by task.[1]

Avoid a single broad "AI user" group. Instead, create roles that reflect responsibilities, such as user, assistant creator, reviewer, and administrator. Separate content administration from security administration where possible.

Group membership can become complex. Document owners, purpose, approval, and review intervals. Dynamic groups can reduce manual work but must be tested so that attributes do not grant unintended access.

Secure document analysis with AI in regulated industries

Document and source level

A secure knowledge chat should search only in material that the user is allowed to read. This can be done through separate indexes, metadata filters, or verification against the source system upon retrieval.

Permission information must follow the document through processing and indexing. If a document is moved or its access is changed, the index needs to be updated. Old text snippets must not remain with previous permissions.

Test with multiple profiles asking the same question. An HR employee, manager, and external consultant may need to receive different source materials or no response at all.

How to connect a secure chat to your business's own data

Principle of least privilege

Each user, service, and integration should have the minimum access needed for the task. An agent that is only supposed to create a draft does not need permission to send it. A connector that reads a document space does not need to write back.

Use separate technical identities for separate functions and avoid shared secrets with broad access. Rotate credentials and log privileged actions.

Role-based access is not always enough. Context such as document class, case ownership, or time may require attribute- or policy-based decisions. The architecture should be able to combine multiple signals without making the model itself responsible for authorization.

AI assistant or AI agent – what is the difference?

What happens when a user changes roles?

The joiner-mover-leaver process should include the AI solution. When a person changes departments, old groups should be removed and new ones assigned upon approval. When the person leaves, sessions, tokens, and local permissions should be revoked.

Also consider temporary projects, consultants, and guests. Set end dates and recurring attestation. A common security issue is not the initial assignment, but permissions that are never removed.

Logging and monitoring

Log access decisions at a level that enables troubleshooting and auditing: user identity, role, requested function, allowed source, and result. Avoid logging more sensitive content than the purpose requires.

Administrative changes should have higher traceability. Who added a data source, changed a role, or gave the agent a new tool? Alerts may be needed for unusual patterns, repeated denials, or large exports.

Perform periodic access reviews together with information owners. The security team can check the model, but the business knows which individuals actually need the content.

AI Act, NIS2, DORA & GDPR – which requirements affect the company's AI solution?

Example of an authorization model

A municipality-wide platform can have a shared login but separate assistants. All employees are allowed to use a general writing assistant. Only the HR group is allowed to use the HR assistant. Managers are allowed to read certain governing documents but not individual cases. The platform administrator can configure the model without automatically being allowed to read all documents.

This requires platform roles and information access to be kept separate. An administrator is not the same as an information owner.

What happens to the company's data when you use AI?

Checkpoints

• Federated login and multi-factor authentication where risk requires it.

• Named owners for groups and roles.

• Least privilege per function and integration.

• Authorization filters before information retrieval and model.

• Synchronization when documents or groups change.

• Separate privileges for administration and content.

• Lifecycle management for employees, consultants, and guests.

• Logging of denials and administrative changes.

• Regular attestation of access.

• Emergency process for immediate revocation.

Sources

1. Microsoft, Microsoft Entra role-based access control:
   https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/

2. Microsoft, Custom roles:
   https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/custom-overview

3. NIST, AI Risk Management Framework:
   https://www.nist.gov/itl/ai-risk-management-framework