Skip to content

Connect Lumos to ChatGPT: Manage app access, users, and permissions

Learn how to connect Lumos to ChatGPT using a managed MCP server. Automate access reviews, user provisioning, and vendor agreements with AI agents.

Uday Gajavalli Uday Gajavalli · · 9 min read
Connect Lumos to ChatGPT: Manage app access, users, and permissions

If you want to connect Lumos to ChatGPT so your AI agents can provision software, audit vendor agreements, and conduct access reviews, you need an integration layer that speaks the Model Context Protocol (MCP). If your team uses Claude, check out our guide on connecting Lumos to Claude or explore our broader architectural overview on connecting Lumos to AI Agents.

IT and security teams are drowning in access requests, compliance audits, and vendor renewals. A February 2026 Gartner survey revealed that 91% of IT leaders are under intense executive pressure to implement AI. The mandate is clear: automate routine provisioning, speed up access reviews, and handle Helpdesk tickets with AI agents. But giving a Large Language Model (LLM) read and write access to your central identity and app governance platform is a serious engineering challenge.

You either spend weeks building, hosting, and maintaining a custom MCP server, or you use a managed infrastructure layer that handles the boilerplate for you. This guide breaks down exactly how to use Truto to generate a secure, managed MCP server for Lumos, connect it natively to ChatGPT, and execute complex IT governance workflows using natural language.

The Engineering Reality of the Lumos API

A custom MCP server is a self-hosted integration layer that translates an LLM's tool calls into REST API requests. While Anthropic's open standard provides a predictable way for models to discover tools, the reality of implementing it against complex identity APIs is painful. If you decide to build a custom MCP server for Lumos, you are responsible for the entire API lifecycle.

Integrating Lumos is not just basic CRUD. You are navigating an ecosystem built for enterprise governance, which introduces specific architectural hurdles:

Asynchronous Job Polling

Lumos handles heavy operations - like taking snapshots of entitlements for access reviews or uploading large account batches - asynchronously. When an LLM calls an endpoint to initiate an access review or post activity records, it does not get a completed result back. It receives a job_id. Your AI agent must be instructed to poll the get_single_lumos_activity_records_job_by_id or equivalent endpoint to determine when the state transitions to completed. If your MCP server does not expose these job state endpoints, the LLM will hallucinate that the job finished successfully, proceeding with workflows based on false assumptions.

Domain Apps vs. AppStore Taxonomies

Lumos splits application management into two distinct domains: the global AppStore catalog and your company-specific domain apps. There is a fundamental difference between list_all_lumos_apps (apps in your company catalog) and list_all_lumos_appstore_apps (the global store). If your LLM tries to update an app setting using the wrong identifier, the request will fail. Your tool descriptions must meticulously define which endpoint takes a domain_app_uuid versus an app_id.

Hard Rate Limits and Backoff Logic

Like all identity providers protecting sensitive data, Lumos enforces strict rate limits. When your AI agent tries to iterate over 10,000 user accounts or pull every activity log from the last quarter, it will hit an HTTP 429 Too Many Requests error.

Note on how Truto handles this: Truto does not automatically retry, throttle, or apply backoff on rate limit errors. When the upstream Lumos API returns a 429, Truto passes that error directly to the caller. However, Truto normalizes the upstream rate limit information into standardized headers (ratelimit-limit, ratelimit-remaining, ratelimit-reset) per the IETF specification. The caller (the LLM client or your orchestrator) is responsible for reading these headers and executing exponential backoff.

Deprecated Endpoints and Schema Maintenance

APIs evolve. Lumos has several v2 endpoints and deprecated V1 paths (like lumos_app_settings_list_2 or older task completion routes). If you hardcode a custom MCP server against older schemas, your integration will break when those endpoints are sunset. Maintaining massive JSON schemas for every endpoint, tracking query parameters versus body payloads, and keeping descriptions updated for the LLM is a full-time maintenance burden.

Building the Lumos MCP Server with Truto

Instead of forcing your engineering team to build and maintain this infrastructure, Truto dynamically generates an MCP server directly from your connected Lumos account.

Truto derives these tools dynamically from the integration's resource definitions and documentation records. A tool only appears if it has a corresponding documentation entry, acting as a quality gate so your LLM only sees well-defined endpoints.

You can create this server in two ways: via the Truto UI for internal testing, or programmatically via the API for multi-tenant SaaS deployments.

Method 1: Via the Truto UI

  1. Navigate to your Truto dashboard and go to the Integrated Accounts page for your Lumos connection.
  2. Click the MCP Servers tab.
  3. Click Create MCP Server.
  4. Select your desired configuration (e.g., restrict to read-only methods or specific tags).
  5. Copy the generated MCP server URL (e.g., https://api.truto.one/mcp/a1b2c3d4...).

Method 2: Via the Truto API

For teams building agentic software, you can generate MCP servers programmatically. This endpoint creates a secure token stored in Cloudflare KV, meaning the URL alone is enough to authenticate requests.

curl -X POST https://api.truto.one/integrated-account/{integrated_account_id}/mcp \
  -H "Authorization: Bearer YOUR_TRUTO_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Lumos IT Admin Agent",
    "config": {
      "methods": ["read", "write", "custom"]
    }
  }'

The API returns a database record and the live URL.

Connecting the MCP Server to ChatGPT

Once you have the URL, connecting it to ChatGPT takes seconds. You do not need to deal with OAuth flows, token refreshes, or pagination logic - Truto's proxy API layer handles the heavy lifting.

Method A: Via the ChatGPT UI

  1. Open ChatGPT and navigate to Settings -> Apps -> Advanced settings.
  2. Enable Developer mode.
  3. Under MCP servers / Custom connectors, click to add a new server.
  4. Enter a name (e.g., "Lumos IT Admin").
  5. Paste the Truto MCP URL into the Server URL field and save.

Method B: Via Config File (For Local Clients & Custom Orchestrators)

If you are using Claude Desktop, Cursor, or a local agent framework that relies on an MCP JSON config file, you can connect using the official Server-Sent Events (SSE) transport wrapper:

{
  "mcpServers": {
    "lumos-it-ops": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-sse",
        "https://api.truto.one/mcp/YOUR_TRUTO_TOKEN"
      ]
    }
  }
}

High-Leverage Lumos MCP Tools

Truto exposes the full surface area of the Lumos API, but certain operations provide outsized value for AI agents acting as IT operators. Here are the core hero tools your agent will use.

1. List All Lumos Users (list_all_lumos_users)

Before an AI agent can assign software or perform an access review, it needs to find the exact identity record. This tool fetches user IDs, email addresses, and statuses. Using the search_term parameter with exact_match ensures the LLM does not accidentally pull the wrong employee.

"Find the Lumos user record for sarah.connor@company.com. Use an exact match search and return her user ID and current status."

2. Create an Access Request (create_a_lumos_appstore_access_request)

This is the engine for automated provisioning. When an employee asks for software in Slack or Microsoft Teams, the agent uses this tool to immediately open a structured access request in Lumos, mapping the requester ID to the target app ID.

"Create an AppStore access request for the user ID 8f7b-4a3d to get access to Figma (App ID 9a2b). Add a note saying this is required for the upcoming Q3 marketing campaign."

3. List All Tasks (list_all_lumos_tasks)

Lumos relies heavily on task objects for approvals and manual provisioning steps. An AI agent can use this tool to poll for pending tasks assigned to IT, filtering by task_category=APPROVAL to see what needs immediate attention.

"Fetch all pending approval tasks assigned to IT. Expand the assignees and actions fields so I can see who needs to sign off."

4. Complete a Task (lumos_tasks_complete)

Once the agent has identified a task and verified the request against company policy (e.g., checking if the user is in the correct department), it can programmatically execute the approval on behalf of the admin.

"Complete the Lumos task with ID task-88392. Mark it as approved."

5. List Vendor Agreements (list_all_lumos_vendor_agreements)

For FinOps and IT procurement workflows, this tool provides a panoramic view of software spend. It returns contract lengths, annualized costs, and renewal dates. Agents can use this to identify shadow IT or flag upcoming renewals.

"Pull a list of all active vendor agreements. Identify any contracts with a projected annualized cost over $50,000 that are renewing in the next 90 days."

6. List Access Reviews (list_all_lumos_access_reviews)

SOC 2 and ISO 27001 compliance depend on routine Access Review and Deprovisioning Audits (ARDAs). This tool allows the agent to check the status of ongoing review campaigns, ensuring that managers are actually completing their required sign-offs.

"List all active access reviews for our organization. Tell me which campaigns are currently in the IN_PROGRESS state."

To see the complete inventory of available endpoints, parameter schemas, and V2 paths, consult the Lumos integration page.

Workflows in Action

Exposing individual endpoints to an LLM is useful, but the real power of MCP lies in multi-step orchestration. By giving ChatGPT a sequence of tools, you can automate workflows that usually take an IT analyst an hour of context switching.

Scenario 1: Autonomous Just-in-Time Access

When a developer requests temporary production access during an incident, speed is critical. An AI agent can parse the request, verify the user, trigger the Lumos access request, and instantly approve it if policies allow.

"An engineer (david.lee@company.com) just reported a Sev-1 incident and requested temporary write access to the AWS Production app. Find his user ID, submit an access request for the app, locate the resulting approval task, and approve it automatically based on the active incident protocol."

Step-by-step execution:

  1. list_all_lumos_users: The agent searches for david.lee@company.com to retrieve his user ID.
  2. list_all_lumos_apps: The agent searches for the "AWS Production" app to grab the correct app_id.
  3. create_a_lumos_appstore_access_request: The agent submits the request on David's behalf, specifying the business justification.
  4. list_all_lumos_tasks: The agent polls for the newly generated approval task linked to that access request.
  5. lumos_tasks_complete: The agent transitions the task to COMPLETED, provisioning the access.
sequenceDiagram
    participant User as "Engineer"
    participant GPT as "ChatGPT (Agent)"
    participant Truto as "Truto MCP"
    participant Lumos as "Lumos API"

    User->>GPT: "I need prod AWS access for Sev-1"
    GPT->>Truto: call list_all_lumos_users(email)
    Truto->>Lumos: GET /users?search_term=...
    Lumos-->>Truto: User ID: 12345
    Truto-->>GPT: User ID: 12345
    
    GPT->>Truto: call create_a_lumos_appstore_access_request
    Truto->>Lumos: POST /access_requests
    Lumos-->>Truto: Request ID: req-999
    Truto-->>GPT: Request ID: req-999
    
    GPT->>Truto: call list_all_lumos_tasks
    Truto->>Lumos: GET /tasks?access_request_id=req-999
    Lumos-->>Truto: Task ID: task-555
    Truto-->>GPT: Task ID: task-555
    
    GPT->>Truto: call lumos_tasks_complete(task-555)
    Truto->>Lumos: POST /tasks/task-555/complete
    Lumos-->>Truto: 204 No Content
    Truto-->>GPT: Success
    GPT-->>User: "Access granted. Stay safe in Prod."

Scenario 2: The Automated SOC 2 Auditor

Auditors constantly ask for evidence of active software contracts and proof that access reviews are being conducted. Instead of manually exporting CSVs, an IT manager can ask ChatGPT to compile a comprehensive readiness report.

"I need an audit report for our upcoming SOC 2 review. First, pull all active access review campaigns and identify any that are overdue. Then, retrieve all vendor agreements to ensure we have contracts recorded for all major infrastructure providers."

Step-by-step execution:

  1. list_all_lumos_access_reviews: The agent fetches all campaigns and filters the returned JSON for any where the deadline_at is in the past but the status is not COMPLETED.
  2. list_all_lumos_vendor_agreements: The agent pulls the contract database, extracting the vendor, total_contract_cost, and renewal_stage.
  3. The agent synthesizes this data into a clean markdown table, highlighting gaps in compliance directly in the chat interface.
flowchart TD
    A["Trigger Audit<br>Workflow"] --> B["Call MCP:<br>list_all_lumos_access_reviews"]
    B --> C{"Are any reviews<br>overdue?"}
    C -->|Yes| D["Flag overdue campaigns<br>for manager"]
    C -->|No| E["Mark reviews<br>compliant"]
    D --> F["Call MCP:<br>list_all_lumos_vendor_agreements"]
    E --> F
    F --> G["Generate final<br>Markdown Report"]

Security and Access Control

Giving an LLM access to your identity governance platform is inherently risky. A hallucinating model could accidentally delete a pre-approval rule or approve malicious access. Truto provides four distinct layers of access control at the MCP server level to minimize this blast radius.

  • Method Filtering: You can restrict an MCP server to strictly read-only operations by passing config: { methods: ["read"] } during creation. This allows the AI to fetch users and tasks, but prevents it from mutating any state.
  • Tag Filtering: Lumos endpoints are mapped to resource tags. You can restrict an MCP server to only interact with tasks and access_reviews, completely walling off vendor agreements or webhook configurations.
  • Require API Token Auth: By default, possessing the MCP URL grants access. For production zero-trust environments, setting require_api_token_auth: true forces the client to pass a valid Truto API token in the Authorization header on every JSON-RPC request.
  • Ephemeral Servers: If you are providing AI tools to an external contractor or a temporary audit team, you can specify an expires_at timestamp. Once the time is reached, Cloudflare KV purges the token and a Durable Object alarm permanently deletes the database record.

By leveraging these controls, you can deploy AI agents into your IT workflows confidently, knowing the underlying API connectivity is managed, secure, and fully typed.

FAQ

Does Truto automatically retry when the Lumos API hits a rate limit?
No. Truto passes HTTP 429 Too Many Requests errors directly back to the caller, along with standardized IETF rate limit headers. Your LLM or orchestration framework must handle the exponential backoff logic.
Can I restrict the AI agent to only read data from Lumos?
Yes. When generating the MCP server via Truto, you can configure method filtering by setting the allowed methods to `["read"]`. This ensures the AI can list users and tasks but cannot create, update, or delete records.
How does the MCP server authenticate with Lumos?
The MCP server is scoped to a specific integrated account in Truto. Truto securely manages the OAuth tokens and credentials for that Lumos connection, automatically injecting them into the proxy API requests initiated by the AI agent.
Can I expire the MCP server URL automatically?
Yes. You can pass an `expires_at` ISO datetime when creating the MCP server. Truto uses Cloudflare KV expiration and a Durable Object alarm to guarantee the server is completely destroyed at the specified time.

More from our Blog