Jarvis Registry connects Microsoft Entra ID sign-in to two access checks. A role defines which Registry actions a person may perform. An access-control list (ACL) defines whether that person may access a particular server. Both checks must pass. The connected business system still needs its own rules for data and actions.
The buying decision is whether that chain works for your two users, your tool and your business data. Sign-in is the first check. The request must also pass the Registry and business-system checks that apply to that route.
What does Jarvis provide, and what must you configure?
Jarvis’s identity-provider guide names Microsoft Entra ID as a supported provider. The auth layer uses OpenID Connect (OIDC) and OAuth 2.0. It maps identity groups to Registry roles. Your existing Microsoft identity system remains part of the setup.
| Buyer requirement | Documented Jarvis capability | Implementation check |
|---|---|---|
| Company sign-in | Entra ID integration through the auth layer | Correct tenant, application configuration and supported client login flow |
| Separate operator responsibilities | Roles and endpoint-level scopes | Which people may register, change or share resources |
| Restricted resource access | Resource-level access-control lists, or ACLs | Which server or agent each identity can see or modify |
| Disable an individual tool on a server | Server-wide disabled-tools list for normal discovery and execute_tool | The same restriction applies to all consumers; the transparent proxy uses a different path |
| Restrict business operations and records | Depends on the downstream authorization design | Which identity the connector uses and which reads or writes that identity permits |
| Investigate a call | Platform metrics, agent traces and available operational logs | Whether the deployment records the identity, tool, access decision and business outcome needed for the investigation |
The Registry scope design separates permission to use an endpoint from permission to access a specific resource. Check both. A “Read-Only” Registry role does not make a connected database read-only. The database account’s rights still matter.
Bind Entra roles to the configured group Object IDs, following the Entra group setup runbook. A new group with the same display name does not get the old group’s rights. Microsoft’s ID token claims reference explains why: object identifiers are stable, while names and email addresses can change.
Access-control boundaries checked: November 3, 2026. The boundaries below follow the current Registry documentation; the pilot results still need to be demonstrated in the buyer’s deployment.
Which MCP gateways support per-user tool permissions?
For Jarvis, distinguish per-user server access from different permissions on individual tools within that server. Jarvis Registry’s resource ACLs can give two users different access to a server. Its disabled-tools control is server-wide, so it doesn’t create a separate tool list for each employee.
Suppose one service-desk server exposes both search_tickets and update_ticket. Granting server access doesn’t prove that a user can search while being blocked from updates. Disabling update_ticket through the documented control affects every consumer on its supported discovery and execution paths. The transparent proxy does not enforce that list.
Before choosing a gateway, identify where read and write rights are enforced and which identity the server uses. The business system may apply user-specific authorization, or the deployment may need separately scoped resources. Have the team demonstrate the chosen design. An Entra sign-in or a hidden tool in the client doesn’t prove the restriction. The two-user test below checks each boundary separately.
Keep discovery, execution and record access separate
The Registry Endpoint gives compatible clients a common entry point. It filters discovery using the caller’s permissions. This limits the tools shown to a user. It does not replace the test of an explicit call.
Discovery: Can the user find this approved resource?
Execution: Can this identity invoke this specific operation now?
Business data: Which records can the downstream system return or change under the configured credentials?
For example, a ticket-search tool may serve people with different access to tickets. Permission to call it should not expose every ticket. Record whether the connector acts for the user or through a service account. Then test which records that account can return.
For the wider architecture, see the enterprise MCP registry guide. This rollout focuses on one access decision rather than rebuilding that architecture discussion.
Test one service-desk server with two identities
Use this illustrative pilot, not a claimed customer result. A support lead owns one service-desk MCP server. A support user starts with no server grant. Give both users the application capabilities needed for gateway calls. The test can then isolate server access, rather than fail because one role cannot use the gateway.
Start with a harmless test tool. The two-user MCP access walkthrough supplies the example and setup steps. Then test ordinary and restricted service-desk records separately. Agree the connector’s identity and expected data access before that second test.
| Test | Expected result to demonstrate |
|---|---|
| Support user has no server grant | Discovery does not grant access, and an explicit call is denied even if the user knows the server ID and tool name |
| Owner grants the user server access | The harmless call succeeds with the required application capabilities and client consent |
| Owner removes that grant | Repeat the call in the existing session and after fresh sign-in; record the result and timing |
| Owner disables a tool while both users have server access | execute_tool rejects it for both users; repeat in the actual client mode rather than assuming the transparent proxy does the same |
| User attempts a business update or a restricted record | The downstream system’s configured authorization permits or denies the operation as specified; server access alone is not proof of this boundary |
The tool-enablement contract describes a server-wide switch. It is not a per-user tool allowlist. If one employee may search and another may update, ask the team to show how those rights are enforced. Test the client mode you will deploy.
Also try a direct connection outside the approved route. Closing that bypass may require network, device or application rules.
Check access changes and evidence before expanding
After an access change, test a fresh sign-in and an existing session. Groups, token lifetime, sessions and config reloads can affect the result. Record what happens and when. Do not promise that every session loses access at once. For example, Jarvis’s scope guide says scope-config changes require a service restart.
For an allowed and a denied request, find the caller, requested action and decision in the available records. Metrics and LLM traces alone do not prove that every access decision was logged. Use the MCP audit evidence checklist to find missing records or fields.
Decide who can read those records and how long to keep them. Debug payloads can contain sensitive data. The MCP governance checklist covers those ownership and retention decisions.
Logs help explain what happened. They do not prove that the model’s answer was right or the business action was appropriate. Test those outcomes too. A copilot instruction to avoid a tool also needs an enforced access rule. Keep that distinction when combining AI skills with MCP tools.
For the vendor-neutral policy design, use the MCP per-user access-control guide. The MCP OAuth guide covers client registration and the separate downstream credential, while the private registry guide records which server release and policy are approved. Keep reusable SKILL.md instructions under review without treating them as permission grants.
Bring the access decision to a Jarvis demo
Evaluate Jarvis if your team uses Entra ID and needs to share approved MCP resources across AI clients. Bring one MCP server, two test users, allowed and denied actions, and one restricted record.
Request a Jarvis demo around that scenario. Ask ASCENDING to show the supplied controls. Record the tenant, connector and business-system setup still needed before rollout.
References
- Jarvis MCP Gateway
- Jarvis identity-provider integration
- Jarvis roles, scopes and resource permissions
- Jarvis Registry Endpoint
- Jarvis Entra scope-group setup
- Jarvis tool-enablement boundaries
- Two-user MCP access walkthrough
- Microsoft Entra ID token claims
MCP Access Control Questions
Does Jarvis Registry support Microsoft Entra ID?
Yes. Jarvis supports Entra ID sign-in through its auth layer. Group mappings assign Registry roles and scopes. Test the actual tenant, application and client setup before rollout.
Does signing in allow someone to use every MCP tool?
No. The user's role must allow the application action, and the server's resource permissions must grant access. Restrictions on individual business operations and records also depend on the downstream service and the credentials used.
Is a Registry read-only role the same as read-only database access?
No. Registry roles govern Registry operations. Database or application permissions must be checked separately, including the identity used by the connector.
What should an MCP access-control demo prove?
Use two identities to show permitted discovery, an allowed call, a blocked call, a restricted business record and behavior after access changes. Inspect the corresponding logs.
Does disabling a tool create a different tool policy for each user?
No. The disabled-tools list applies to all users of a server through normal discovery and execute_tool. The transparent proxy does not enforce it. Different read and write rights need a separate access design. Test that design through the route your client actually uses.
