MCP Auth/Security - For IAM

TL;DR

The Lumos Remote MCP Server lets your users do request access and soon configure the App Store from inside the AI assistants they already use (Claude, Glean, and others) while every action still runs through Lumos's normal authentication, policy, and audit pipeline.

• It is an OAuth-protected MCP endpoint your team's approved AI clients can connect to.
• Every call runs as the authenticated user. No shared service accounts, no agent-owned identity.
• Users sign in through your IdP, see a consent screen, and can revoke access at any time.
• You control which clients connect, which users see the feature, and you get a full audit trail you can ship to your SIEM.

What is Lumos MCP?

Lumos MCP is a remote server that speaks the Model Context Protocol, the standard the major AI assistant vendors are converging on. When an end user connects their AI client to Lumos, the assistant gains a small, well-defined set of tools it can run on the user's behalf, after the user has signed in and granted consent.

Why integrate

Four reasons this matters to an IAM team:

• Meet users where they work. End users are already talking to AI assistants all day. Letting them request access from that surface cuts down on context switching.
• Real identity on every action. OAuth means the user signs in through your IdP. Audit logs show a real person, not a bot account. If someone leaves the company, their MCP access disappears with their Lumos user.
• Familiar governance posture. This works the same way as any other OAuth-connected enterprise app you have in your environment today. Same consent model, same revocation pattern, same audit shape.
• You stay in control. Per-domain enablement, allowlistable clients, full audit logging, and admin-side revocation. Nothing turns on without a deliberate decision.

What your users will experience

First time they use it

1. User asks their AI assistant to do something in Lumos.
2. The assistant pauses and opens a Lumos sign-in page in the user's browser.
3. The user signs in through your IdP, the same way they sign into Lumos today.
4. Lumos shows a consent screen listing the assistant's name, the redirect URL, and what the assistant is asking to do.
5. User clicks Approve.
6. They return to their assistant and the action completes.

Every time after

The assistant keeps a refresh token and renews access in the background. The user does not see a sign-in screen on each call. They will be prompted again only if:

• The client asks for an additional scope.
• The user (or an admin) revokes the grant.
• The refresh window has fully expired.

Revoking access

• Users can view their active grants in Lumos and revoke any of them. Revocation is immediate.
• Admins can revoke grants for a specific user or for a specific client across the org.
• A revoked grant invalidates both the access token and the refresh token, so the assistant will be forced to reconnect.

---

How to connect (for admins)

1. Decide which AI clients you'll allow. Lumos validates registered clients against host profiles for known assistants (Claude, Glean, and others). Share your allowlist with Lumos so unknown registrations are rejected by default.
2. Share the connection details with users. The endpoint is https://api.lumos.com/mcp/appstore. Most AI clients ask for this URL once and remember it.
3. (Optional) Set up audit export. Configure your SIEM to ingest the audit events listed below.
4. Tell your users. A short note covering what they can do, what they will see on the consent screen, and how to revoke access goes a long way.

---

Getting started (for end users)

1. In your AI assistant, add a new MCP connection and paste https://api.lumos.com/mcp/appstore.
2. The first time you ask the assistant to do something in Lumos, it will open a browser tab. Sign in.
3. Review the consent screen. Approve if everything looks right.
4. Return to the assistant and continue working. You can ask things like "find apps related to billing" or "request access to Snowflake for one week."

To revoke access later, open Lumos and visit your connected agents page.

---

Technical overview

For security leads who want to verify the implmentation.

Protocol and standards

• MCP over HTTPS.
• OAuth 2.1 Authorization Code grant with PKCE (RFC 7636).
• Authorization Server metadata at /.well-known/oauth-authorization-server (RFC 8414).
• Protected Resource metadata at /.well-known/oauth-protected-resource/... (RFC 9728).
• Dynamic Client Registration (RFC 7591).
• Token revocation (RFC 7009).

Endpoints

Tokens

Refresh tokens rotate on every use. If a previously rotated refresh token is presented after a short grace period, Lumos treats it as a theft signal and revokes the entire token family.

Resource binding. Each access token is bound to a single MCP resource. A token issued for /mcp/appstore cannot be used against any other Lumos MCP endpoint.

Two-layer authorization. OAuth scopes are the public, client-facing contract and are coarse on purpose. Lumos permissions, derived from the user's role, are the fine-grained server-side check. A token's effective rights are the intersection: the scopes the user consented to, narrowed by the permissions their role actually grants. Asking for a scope the user's role cannot satisfy results in a deny at tool-call time, not a misleading approve at consent.

Initial App Store scopes

Dynamic Client Registration. Supported. Redirect URIs must be HTTPS (loopback allowed only for approved client types), must match exactly, and may not contain wildcards or fragments. Unknown clients are rejected unless your organization has explicitly allowed them.

Rate limits. Enforced per user (separate buckets for read and write tools) and per domain. Responses include Retry-After and X-RateLimit-* headers. Over-limit calls return 429 Too Many Requests at the HTTP layer and a corresponding JSON-RPC error.

---

Audit and monitoring (To remove)

Lumos records the events you need to investigate how AI clients are being used in your environment.

Events logged

• Client registration and updates
• Consent granted, consent denied
• Token issuance, refresh, and revocation
• Tool discovery (what the client asked Lumos to list)
• Tool invocation (what the client actually called)
• Write outcome: created, updated, deduped, denied, or failed validation
• Rate-limit hits
• Authorization failures, with reason

Fields on each event

• event_name, timestamp
• domain_id, user_id, user_email
• client_id, client_name
• resource (the MCP endpoint), tool_name
• scopes granted, effective permissions for the call
• request_id for correlation
• target_resource_id for the app, request, or object affected
• write_outcome for write actions
• telemetry.intent (optional, supplied by the agent so you can see the stated reason for the call)
• error_code when applicable

Never logged

• Access tokens, refresh tokens, authorization codes
• Client secrets
• Full sensitive payloads

Worth watching

• Sessions per client and per user
• Tool calls broken down by tool, user, and domain
• Write outcomes, especially denials and dedupes
• Authorization failures by reason
• Rate-limit events
• Revocations and any refresh-token reuse detections

These signals tell you who is adopting the integration, where agents are misconfigured, and whether anything is acting outside expected patterns.

---

Admin controls

Available today

• Enable or disable MCP for your domain
• View registered clients
• Revoke a user's grants

Support

To request enablement, report an issue, or escalate a security concern, contact your Lumos representative or file a ticket through your usual support channel.