# Lutril: full content > Lutril is access governance for employees and AI agents: unified policy, access reviews that revoke, onboarding and offboarding automation, shadow IT and shadow AI discovery, and an MCP proxy that governs what AI agents can do in your SaaS tools. Source: https://www.lutril.com Index: https://www.lutril.com/llms.txt --- # Stop PII from leaking into prompts. > Inspect every prompt, detect PII and secrets, and redact them before they reach the model, with a full record of what was caught. Source: https://www.lutril.com/ai-governance/dlp --- Lutril inspects every prompt headed to an LLM, detects PII, secrets, and keys, and redacts them before the model ever sees them, without blocking the work. - PII & secret detection - Inline redaction - Per-model policy - **Detect** PII, secrets, API keys, and custom patterns. - **Redact inline** Replace sensitive spans before the model receives them. - **Per-model policy** Different rules for public models vs. your private endpoints. - **Immutable audit** Every redaction recorded, nothing stored in the clear. ## A checkpoint on the way to every model. DLP runs at the same layer that governs your agents, so it applies to chat, copilots, and MCP tool calls alike. - **Detection that fits your data** Built-in detectors for emails, cards, national IDs, and secrets, plus regex and keyword patterns for your own sensitive fields. - **Redact, mask, or block** Choose per policy: redact the span, mask to a token the model can reason about, or block the request outright. - **Works across every model** One policy covers ChatGPT, Claude, Gemini, and your self-hosted models, applied consistently everywhere. - **Provable compliance** An immutable log of what was detected and redacted gives auditors evidence without exposing the original data. --- # See every AI tool and agent your team really uses. > A Chrome extension, email scanning, sign-in logs, and code scanning surface every unsanctioned AI tool and agent in your company, before it becomes an incident. Source: https://www.lutril.com/ai-governance/shadow-ai --- A Chrome extension, mailbox scanning, sign-in logs, and code scanning surface every AI tool and agent your team runs, sanctioned or not, so nothing handles your data in the dark. - Browser extension - IdP sign-in signals - Agent discovery - **Chrome extension** Catches AI tools at the point of use, even when they skip SSO. - **Email scanning** Reads Google and Microsoft mail for sign-up and receipt emails from AI vendors. - **OAuth & SSO** Pulls grants and sign-in logs straight from your identity provider. - **Risk scoring** Ranks every tool by users, data exposure, and training policy. ## Where the signal comes from. Three independent sources. Each catches tools the others miss, so the picture stays complete even when people route around IT. - **Chrome extension** Deployed through your MDM. Flags the AI domains employees open in the browser, including tools that never sign in through SSO. - **Email scanning** Scans Google Workspace and Microsoft 365 mail for the sign-up confirmations, receipts, and trial notices AI vendors send. - **OAuth & SSO** Reads OAuth grants and SSO sign-in logs to show which AI apps hold standing access through a corporate Google or Microsoft account. - **Code scanning** Finds the agents living in your GitHub and GitLab repos, wired to API keys nobody tracks. --- # One source of truth for every agent. > Register each AI agent with an owner, model, and scopes. Rotate credentials, review access, and offboard an agent the same way you would an employee. Source: https://www.lutril.com/ai-governance/agent-registry --- Every AI agent gets a record: an owner, the model it runs on, the scopes it holds, and its activity. Govern agents with the same lifecycle you already use for employees. - Owner & scopes - Credential rotation - One-click offboard - **Owner & scopes** No anonymous agents; each one has an accountable owner. - **Credential rotation** Rotate or expire an agent's keys on a schedule. - **Access reviews** Include agents in the same campaigns as human accounts. - **One-click offboard** Revoke everything an agent can reach, instantly. ## The agent lifecycle, end to end. An agent is an identity. Governing it the way you govern an employee account closes the gap between what your agents can reach and what anyone can see. 1. **Register** Onboard an agent with an owner, its model, and a scoped role drawn from the same library your employees use. 2. **Rotate** Schedule credential rotation and short-lived tokens so a leaked key has a small blast radius. 3. **Review** Surface idle or over-scoped agents in access reviews and tighten them with a decision that executes. 4. **Offboard** When a project ends, retire the agent and revoke every grant across your SaaS in one action. --- # Every tool call runs through policy. > The Lutril MCP server sits between your agents and your SaaS. Each call is matched against a policy, approved or denied, and written to an immutable audit log. Source: https://www.lutril.com/ai-governance/mcp-proxy --- The Lutril MCP server sits between your agents and your SaaS. Every tool call is matched against a policy, approved or denied, and written to an immutable audit log, across every SaaS tool. - One MCP endpoint - Role-based policy - Immutable audit - **One MCP endpoint** Any SaaS. No wait for native support. - **Role-based policy** The same roles you use for humans. - **Immutable audit** Every prompt, tool call, and response. - **Global kill switch** Pause an agent across every tool, instantly. ## Raw API keys can't enforce this. Hand an agent a raw API key and nothing enforces what it reaches. The proxy makes every call inspectable, governable, and reversible. - **Policy on every call** Match agent role, tool scope, parameters, and rate limits before a single request leaves your perimeter. - **Any tool, one endpoint** Expose SaaS actions as MCP tools without waiting for each vendor to ship native support. - **Immutable audit** Prompts, calls, and responses land in a WORM log: the evidence trail auditors ask for. - **Kill switch** Pause one agent, or all of them, across every connected tool the moment something looks wrong. ## Frequently asked questions ### How do I control what AI agents can access through MCP? Put a gateway between the agent and the tool servers. The agent authenticates as its own registered identity, the gateway checks each tool call against a policy (which agent, which tool, which parameters), logs the call and can pause the agent. The Lutril MCP proxy is that gateway for every SaaS tool you connect. ### What is an MCP gateway, and why not just hand the agent an API key? An MCP gateway is a proxy that speaks the Model Context Protocol to the agent and enforces policy on every tool call before forwarding it. An API key grants whatever the key allows, for as long as it exists, with no per-call decision and no log you control. A credential is not a control. ### Can policy be enforced per tool call, not just per connection? Yes. Lutril matches each call on the agent's role, the tool, the parameters and rate limits before it leaves your perimeter. Read calls can be allowed while writes require a human approval in Slack, Teams or the app UI, and the decision is logged with the call. ### Does the MCP proxy work with SaaS tools that have no MCP server? Yes. Lutril exposes the actions of its connected SaaS integrations as MCP tools through one endpoint, so an agent gets governed access to a tool the vendor never shipped an MCP server for. ### What does the audit log contain? Every prompt, tool call and response, with the agent identity, the policy decision and the timestamp, written to a WORM store. It is the evidence trail auditors ask for, and the same log is used for access reviews of agents. --- # Lutril vs BetterCloud > BetterCloud is a SaaS management platform built around a no-code workflow engine, hosted in the United States and acquired by CoreStack in 2026. Lutril is access governance for employees and AI agents, hosted in the EU. Where each one fits. Source: https://www.lutril.com/compare/lutril-vs-bettercloud Last reviewed: 2026-09-02 --- ## Short answer Choose BetterCloud if you want a broad SaaS management platform, with spend, file governance and a deep workflow builder, and US hosting is acceptable. Choose Lutril if the job is access governance: reviews whose decisions execute, time-boxed access requested in Slack, Teams or the app UI, HRIS-driven onboarding and offboarding, and AI agents governed through an MCP proxy, with data in the EU and a French-language product. BetterCloud has documented an agent inventory; it has not documented an MCP gateway or prompt DLP. ## Where each one starts **BetterCloud.** Calls itself the only end-to-end SaaS management platform: one workspace to understand, act on and govern users, apps, spend and AI actors. Founded in 2011, Vista-backed from 2022, acquired by CoreStack in March 2026. Modules for user automation, Google Workspace management, spend and file governance are sold separately. **Lutril.** Access governance for employees and AI agents, in one policy layer: discovery from Google Workspace and Microsoft 365, requests in Slack, Teams and the app UI, access reviews that revoke, HRIS-driven lifecycle, and an MCP proxy that checks every agent tool call. Built by a practising CISO, hosted in France. ## Capability by capability | Capability | BetterCloud | Lutril | | --- | --- | --- | | SaaS discovery from IdP sign-in and OAuth grants (Google Workspace, Microsoft 365) | Yes: Via SSO, browser extension and ERP signals; Google Workspace, Microsoft 365, Okta [2] | Yes: Google Workspace and Microsoft 365 sign-in signals and OAuth grants, from the day you connect | | Browser extension for shadow IT and shadow AI discovery | Yes: Chrome extension released March 2026; flags AI tools, allow and deny lists [3] | Yes: Chrome extension for the SaaS and AI tools that skip SSO | | Access reviews whose keep-or-remove decisions execute the revocation | Partial: Certification campaigns with keep, remove or downgrade; remediation runs through workflows [4] | Yes: Decisions execute in the connected tool; proof in the campaign export | | Access requests and approvals in Slack | Yes: Approvers approve or deny with one click in Slack [5] | Yes: Requests, approvals and expiry warnings in Slack | | Access requests and approvals in Microsoft Teams | Partial: Workflow messages via Slack or Teams; Teams approvals not documented [6] | Yes: Same flow in Microsoft Teams, and in the app UI | | Just-in-time, time-boxed access that expires on its own | Partial: Built with a wait-for-duration step, not a request-level expiry [7] | Yes: One hour to seven days; an approver can shorten, never extend; auto-revoked | | Onboarding triggered by the HRIS | Yes: BambooHR triggers; Workday hire event starts onboarding [8] | Yes: Lucca, PayFit and Eurécia native; other HRIS through the MCP endpoint | | Offboarding that deprovisions across SaaS, including apps outside SSO | Yes: Offboarding workflows across many apps, including revoking OAuth grants [6] | Yes: Native connectors plus a universal MCP endpoint for any tool with an API | | Shadow AI discovery: AI tools and agents in use | Yes: App discovery categorises AI tools; extension flags generative AI logins [9] | Yes: Sign-in logs, mailbox scanning, Chrome extension and code scanning | | AI agent registry with an accountable owner | Partial: Agent governance shows who deployed each agent and its permissions; owner assignment not stated [10] | Yes: Owner, model and scopes on every agent; offboarded like an employee | | MCP proxy or gateway enforcing policy on agent tool calls | Not documented | Yes: Lutril MCP proxy: policy on every call, WORM log, global kill switch | | Prompt-level DLP and redaction for LLM traffic | Not documented: DLP add-on scans file content, not LLM traffic | Yes: Detect and redact PII and secrets in prompts, per-model policy | | EU hosting and a French-language product | Not offered: Datacenters in the United States; French UI not documented [11] | Yes: OVHcloud, France; product and documentation in French | | Compliance evidence exports for SOC 2 and ISO 27001 | Partial: Audit-ready evidence exports; no SOC 2 or ISO specific package [12] | Yes: Campaign export with decisions and revocation proof, one link | | Native integrations | Yes: 100+ integrations, 1,000+ actions [1] | Yes: More than 55 native connectors plus the universal MCP endpoint | | Published pricing | Partial: Pricing page without figures, except a $0 spend tier [13] | Not offered: On request | ## Choose BetterCloud if - You want spend optimisation, file governance and Google Workspace administration in the same product as access. - Your team wants to build its own branching workflows with waits, approvals and timers. - US data residency is fine and you are already on BambooHR or Workday. ## Choose Lutril if - Your data has to stay in the EU, or your team works in French. - You need access reviews whose decisions execute and export as SOC 2 or ISO 27001 evidence, without building a workflow for it. - Access requests must be time-boxed and approved in Slack, Teams or the app UI, with automatic revocation. - AI agents are already calling your SaaS tools and you need a registry, an MCP proxy and a kill switch, not only an inventory. ## Frequently asked questions ### Is BetterCloud an alternative to Lutril for access reviews? BetterCloud runs access certification campaigns and remediates through its workflow engine. Lutril runs campaigns whose keep-or-remove decisions execute directly in the connected tool and exports the decision and the revocation proof together. If your reviewers live in Slack or Teams and your auditor wants one link, Lutril is the shorter path. ### Does BetterCloud govern AI agents? BetterCloud announced agent governance in June 2026: an inventory of agents, who deployed them and what permissions they hold. We found no public documentation of an MCP gateway that enforces policy on each tool call, or of prompt-level DLP. Lutril ships both, with an owner on every agent and a global kill switch. ### Where is the data hosted? BetterCloud states its datacenters are located in the United States and relies on standard contractual clauses for GDPR. Lutril is hosted at OVHcloud in France with Cloudflare at the edge. ### What changed with the CoreStack acquisition? CoreStack announced the acquisition of BetterCloud on March 31, 2026, positioning the combined company as an AI-native IT operations platform. Terms were not disclosed. Check the vendor's roadmap for how the SaaS management modules evolve. ## Sources 1. [BetterCloud homepage](https://www.bettercloud.com/) (accessed 2026-09-02) 2. [BetterCloud, Shadow IT use case](https://www.bettercloud.com/use-case/shadow-it/) (accessed 2026-09-02) 3. [BetterCloud, Chrome browser extension announcement](https://www.bettercloud.com/monitor/bettercloud-chrome-browser-extension/) (accessed 2026-09-02) 4. [BetterCloud, SaaS application access audit guide](https://www.bettercloud.com/saas-application-access-audit-guide/) (accessed 2026-09-02) 5. [BetterCloud, self-service access provisioning](https://www.bettercloud.com/monitor/self-service-access-provisioning/) (accessed 2026-09-02) 6. [BetterCloud, anatomy of the perfect offboarding workflow](https://www.bettercloud.com/monitor/anatomy-of-the-perfect-bettercloud-offboarding-workflow/) (accessed 2026-09-02) 7. [BetterCloud, Wait for Duration](https://www.bettercloud.com/monitor/automatically-pause-your-workflows-wait-for-duration/) (accessed 2026-09-02) 8. [BetterCloud, BambooHR integration](https://www.bettercloud.com/monitor/bamboohr-integration/) (accessed 2026-09-02) 9. [BetterCloud, App Discovery](https://www.bettercloud.com/app-discovery/) (accessed 2026-09-02) 10. [BetterCloud, introducing the next generation of BetterCloud](https://www.bettercloud.com/monitor/introducing-the-next-generation-of-bettercloud/) (accessed 2026-09-02) 11. [BetterCloud, security and compliance](https://www.bettercloud.com/security-and-compliance/) (accessed 2026-09-02) 12. [BetterCloud, streamline SaaS app security compliance](https://www.bettercloud.com/how-to-streamline-saas-app-security-compliance/) (accessed 2026-09-02) 13. [BetterCloud pricing](https://www.bettercloud.com/pricing/) (accessed 2026-09-02) 14. [BetterCloud, CoreStack acquires BetterCloud](https://www.bettercloud.com/monitor/corestack-acquires-bettercloud/) (accessed 2026-09-02) Lutril wrote this page. Facts about BetterCloud come from their public documentation as of 2026-09-02. Spotted an error? Write to hello@lutril.com. --- # Lutril vs AccessOwl > AccessOwl is a Slack-first access management tool for small IT teams, priced per user from $4.50. Lutril is access governance for employees and AI agents, with time-boxed access, Teams as well as Slack, and an MCP proxy. Where each one fits. Source: https://www.lutril.com/compare/lutril-vs-accessowl Last reviewed: 2026-09-02 --- ## Short answer Choose AccessOwl if you are a lean IT team under a few hundred employees, live in Slack, and want published per-user pricing with onboarding, offboarding and access reviews. Choose Lutril if you need access that expires on its own, requests in Microsoft Teams as well as Slack, a browser extension for the tools OAuth never sees, and governance for AI agents through an MCP proxy. AccessOwl states it does not offer automatic expiration of approved requests and ships no browser extension; both are core to Lutril. ## Where each one starts **AccessOwl.** Automates SaaS access administration across the employee lifecycle for lean, fast-growing teams with fewer than five people in IT: onboard new hires, cut off leavers, run access reviews, all from Slack. Berlin-based, Y Combinator 2022, provisioning to 400+ apps without SCIM or SAML upgrades. **Lutril.** Access governance for employees and AI agents: discovery from Google Workspace and Microsoft 365, requests in Slack, Teams and the app UI with automatic expiry, access reviews that revoke, HRIS-driven lifecycle, and an MCP proxy with a kill switch for agents. Hosted in France, product in French and English. ## Capability by capability | Capability | AccessOwl | Lutril | | --- | --- | --- | | SaaS discovery from IdP sign-in and OAuth grants (Google Workspace, Microsoft 365) | Yes: OAuth and SSO log analysis across Google Workspace and Microsoft 365, plus Gmail invitation scanning [3] | Yes: Google Workspace and Microsoft 365 sign-in signals and OAuth grants, from the day you connect | | Browser extension for shadow IT and shadow AI discovery | Not offered: Vendor states: no browser extension and no endpoint agent [3] | Yes: Chrome extension for the SaaS and AI tools that skip SSO | | Access reviews whose keep-or-remove decisions execute the revocation | Yes: Reviewer changes applied immediately on automated-provisioning apps; manual apps go to an admin [4] | Yes: Decisions execute in the connected tool; proof in the campaign export | | Access requests and approvals in Slack | Yes: /request in Slack; approvals in Slack; default approver is the manager [5] | Yes: Requests, approvals and expiry warnings in Slack | | Access requests and approvals in Microsoft Teams | Not documented: Docs list Slack and the web app as request channels | Yes: Same flow in Microsoft Teams, and in the app UI | | Just-in-time, time-boxed access that expires on its own | Not offered: Vendor FAQ: no automatic expiration feature for approved requests [6] | Yes: One hour to seven days; an approver can shorten, never extend; auto-revoked | | Onboarding triggered by the HRIS | Yes: 40+ HRIS providers: BambooHR, HiBob, Personio, Workday, Deel and more [7] | Yes: Lucca, PayFit and Eurécia native; other HRIS through the MCP endpoint | | Offboarding that deprovisions across SaaS, including apps outside SSO | Yes: Provisioning via APIs, RPA and screen scraping; non-integrated apps notify an admin [8] | Yes: Native connectors plus a universal MCP endpoint for any tool with an API | | Shadow AI discovery: AI tools and agents in use | Partial: AI apps surface through OAuth, SSO and email scanning; no dedicated agent discovery [3] | Yes: Sign-in logs, mailbox scanning, Chrome extension and code scanning | | AI agent registry with an accountable owner | Not documented | Yes: Owner, model and scopes on every agent; offboarded like an employee | | MCP proxy or gateway enforcing policy on agent tool calls | Not documented | Yes: Lutril MCP proxy: policy on every call, WORM log, global kill switch | | Prompt-level DLP and redaction for LLM traffic | Not documented | Yes: Detect and redact PII and secrets in prompts, per-model policy | | EU hosting and a French-language product | Partial: Data processed in the Netherlands, Germany, France and Ireland; no region choice; French UI not documented [9] | Yes: OVHcloud, France; product and documentation in French | | Compliance evidence exports for SOC 2 and ISO 27001 | Yes: Reviews export as CSV and sync to Vanta [10] | Yes: Campaign export with decisions and revocation proof, one link | | Native integrations | Yes: 400+ applications on the homepage; docs say over 300 [1] | Yes: More than 55 native connectors plus the universal MCP endpoint | | Published pricing | Yes: $4.50 and $6.00 per user per month, $250 minimum; provisioning is a $2.50 add-on [2] | Not offered: On request | ## Choose AccessOwl if - You have fewer than five people in IT, everything runs in Slack, and you want a price list before a call. - Standing access with periodic reviews is your model; you do not need requests that expire on their own. - You need onboarding and offboarding for hundreds of long-tail apps, including ones with no API, through RPA. ## Choose Lutril if - Access must be time-boxed: requested for a window, revoked at the deadline, without a reviewer remembering. - Your company runs on Microsoft Teams, or on both Slack and Teams. - You want a browser extension and code scanning to catch the SaaS and AI tools that never touch OAuth. - AI agents call your tools and you need a registry, policy on each MCP tool call and a kill switch. - You are a French company, or want the product and documentation in French. ## Frequently asked questions ### Is AccessOwl cheaper than Lutril? AccessOwl publishes its prices: $4.50 or $6.00 per user per month with a $250 minimum, plus add-ons for provisioning and spend. Lutril prices on request, scoped to the number of people and agents governed and the integrations connected. Ask for a quote with your headcount and compare like for like, including the provisioning add-on. ### Does AccessOwl support just-in-time access? AccessOwl's own documentation says it does not offer an automatic expiration feature for approved requests. In Lutril the requester picks a duration from one hour to seven days, the policy caps it, and the access is revoked automatically at the deadline. ### Which one works in Microsoft Teams? AccessOwl documents Slack and its web app as request channels. Lutril runs the same request and approval flow in Slack, Microsoft Teams and the app UI. ### Can either tool see apps people signed up for with a password? Neither can see them through OAuth logs, because nothing is written to the identity provider. AccessOwl scans Gmail for invitation emails. Lutril scans Google and Microsoft mailboxes for sign-up and receipt emails and adds a Chrome extension that recognises SaaS and AI tools at the point of use. ## Sources 1. [AccessOwl homepage](https://www.accessowl.com/) (accessed 2026-09-02) 2. [AccessOwl pricing](https://www.accessowl.com/pricing) (accessed 2026-09-02) 3. [AccessOwl, shadow IT tools compared, buyer's guide](https://www.accessowl.com/blog/shadow-it-tools-compared-buyers-guide) (accessed 2026-09-02) 4. [AccessOwl docs, access reviews](https://docs.accessowl.com/guides/access-reviews.md) (accessed 2026-09-02) 5. [AccessOwl docs, access requests](https://docs.accessowl.com/guides/requests/access-requests.md) (accessed 2026-09-02) 6. [AccessOwl docs, approval policies FAQ](https://docs.accessowl.com/guides/requests/approval-policies.md) (accessed 2026-09-02) 7. [AccessOwl docs, onboarding](https://docs.accessowl.com/guides/onboarding-offboarding/onboarding) (accessed 2026-09-02) 8. [AccessOwl docs, integrations overview](https://docs.accessowl.com/integrations/overview) (accessed 2026-09-02) 9. [AccessOwl privacy policy](https://www.accessowl.com/privacy-policy) (accessed 2026-09-02) 10. [AccessOwl docs, Vanta integration](https://docs.accessowl.com/integrations/all/vanta) (accessed 2026-09-02) 11. [AccessOwl docs, notifications](https://docs.accessowl.com/guides/notifications) (accessed 2026-09-02) 12. [Y Combinator, AccessOwl](https://www.ycombinator.com/companies/accessowl) (accessed 2026-09-02) Lutril wrote this page. Facts about AccessOwl come from their public documentation as of 2026-09-02. Spotted an error? Write to hello@lutril.com. --- # Lutril vs Okta Identity Governance > Okta is the identity provider; Okta Identity Governance adds access requests, certifications and lifecycle on top of it. Lutril governs what sits behind the IdP across SaaS tools and AI agents, and works alongside Okta. Where the two overlap and where they do not. Source: https://www.lutril.com/compare/lutril-vs-okta Last reviewed: 2026-09-02 --- ## Short answer Most teams keep Okta as the front door and run access governance in Lutril. Okta Identity Governance is a strong choice if you are an Okta shop, want certifications and Slack and Teams requests inside the same vendor, and your SaaS tools are all in the Okta Integration Network with SCIM. Lutril is the choice when governance has to cover the tools outside SSO, when discovery should start from Google Workspace or Microsoft 365 sign-in signals without ISPM, when reviews must execute removals everywhere, and when AI agents need policy on every MCP tool call plus prompt DLP. Lutril connects to Okta as a directory source. ## Where each one starts **Okta Identity Governance.** An add-on to the Okta workforce identity platform bundling access requests, access certifications, entitlement management and auditor reporting, alongside Lifecycle Management and Workflows. Requests and approvals run in Slack and Microsoft Teams. Okta is a public company founded in 2009, headquartered in San Francisco, with more than 8,000 integrations and EU cells in Ireland and Frankfurt. **Lutril.** Access governance for employees and AI agents that starts where authentication stops: who holds which permission in each SaaS tool, how access is requested and approved in Slack, Teams and the app UI, what expires on its own, what is removed when someone leaves, and what an AI agent may call through the MCP proxy. Works with Okta, Entra ID or Google as the identity source. ## Capability by capability | Capability | Okta Identity Governance | Lutril | | --- | --- | --- | | SaaS discovery from IdP sign-in and OAuth grants (Google Workspace, Microsoft 365) | Partial: OAuth grant inventory through ISPM and the SAM plugin; not sign-in log discovery [4] | Yes: Google Workspace and Microsoft 365 sign-in signals and OAuth grants, from the day you connect | | Browser extension for shadow IT and shadow AI discovery | Yes: Managed Chrome extension monitors unmanaged OAuth grants; Chrome only [5] | Yes: Chrome extension for the SaaS and AI tools that skip SSO | | Access reviews whose keep-or-remove decisions execute the revocation | Partial: Auto-remove for group-based access when enabled; manual for group rules and app-sourced groups [6] | Yes: Decisions execute in the connected tool; proof in the campaign export | | Access requests and approvals in Slack | Yes: Submit and approve requests from Slack [7] | Yes: Requests, approvals and expiry warnings in Slack | | Access requests and approvals in Microsoft Teams | Yes: Requests and approvals in Slack and Microsoft Teams; admin roles excluded [8] | Yes: Same flow in Microsoft Teams, and in the app UI | | Just-in-time, time-boxed access that expires on its own | Yes: Access duration on request conditions; timer adds automatic revocation [9] | Yes: One hour to seven days; an approver can shorten, never extend; auto-revoked | | Onboarding triggered by the HRIS | Yes: Workday, SAP SuccessFactors, BambooHR, UltiPro, Namely as HR sources [10] | Yes: Lucca, PayFit and Eurécia native; other HRIS through the MCP endpoint | | Offboarding that deprovisions across SaaS, including apps outside SSO | Partial: SCIM deprovisioning through the integration network; Connector Builder for apps with a public API [11] | Yes: Native connectors plus a universal MCP endpoint for any tool with an API | | Shadow AI discovery: AI tools and agents in use | Yes: Agent discovery via ISPM; excluded from the Okta for AI Agents core SKU [12] | Yes: Sign-in logs, mailbox scanning, Chrome extension and code scanning | | AI agent registry with an accountable owner | Yes: Agents registered in the directory with a mandatory human owner [13] | Yes: Owner, model and scopes on every agent; offboarded like an employee | | MCP proxy or gateway enforcing policy on agent tool calls | Yes: Agent Gateway with a virtual MCP server capability, available from April 30, 2026 [14] | Yes: Lutril MCP proxy: policy on every call, WORM log, global kill switch | | Prompt-level DLP and redaction for LLM traffic | Not documented | Yes: Detect and redact PII and secrets in prompts, per-model policy | | EU hosting and a French-language product | Yes: Ireland and Frankfurt cells; French in the end-user dashboard and admin console [18] | Yes: OVHcloud, France; product and documentation in French | | Compliance evidence exports for SOC 2 and ISO 27001 | Yes: Auditor reporting package with five campaign reports [16] | Yes: Campaign export with decisions and revocation proof, one link | | Native integrations | Yes: More than 8,000 pre-built integrations [17] | Yes: More than 55 native connectors plus the universal MCP endpoint | | Published pricing | Partial: Suites from $6 to $17 per user per month, $1,500 annual minimum; the governance add-on is on inquiry [2] | Not offered: On request | ## Choose Okta Identity Governance if - You are standardised on Okta, every application is in the Okta Integration Network with SCIM, and one vendor for identity and governance matters more than coverage of the long tail. - You need entitlement management inside enterprise applications at the depth an IGA suite provides. - Your governance scope is the accounts Okta already knows about. ## Choose Lutril if - Your SaaS estate is larger than your SSO catalogue: apps signed up with a Google or Microsoft account, or with a password, have to be governed too. - You want discovery to start from Google Workspace or Microsoft 365 sign-in signals on day one, without buying a posture add-on. - Access review decisions must execute in every connected tool, not only where SCIM exists. - AI agents need policy on each MCP tool call and prompt-level DLP, with a global kill switch. - You are not an Okta customer, or you run Entra ID or Google as the identity provider. ## Frequently asked questions ### Does Lutril replace Okta? No. Okta authenticates and provisions SSO identities; Lutril governs what happens after login across SaaS tools and AI agents. Lutril reads Okta, Entra ID or Google Workspace as its directory source. Most customers keep their IdP and add Lutril for governance. ### Okta Identity Governance already has access requests in Slack and Teams. What does Lutril add? Coverage and execution. Lutril requests can target any connected tool, including ones with no SCIM, and every grant is time-boxed by default with automatic revocation. Reviews execute removals in the tool itself. And the same request flow exists for AI agents, enforced through the MCP proxy. ### Which one governs AI agents through MCP? Both now document it. Okta announced an Agent Gateway with a virtual MCP server capability available from April 30, 2026, with agent discovery in its ISPM product. Lutril's MCP proxy has been the core of the platform: policy on every tool call, a WORM audit log, prompt DLP and a global kill switch, sold as one product rather than separate SKUs. ### How does pricing compare? Okta publishes suite prices from $6 to $17 per user per month with a $1,500 annual minimum; the Identity Governance add-on is priced on inquiry. Lutril prices on request, scoped to the people and agents governed. Ask both for a quote on your headcount and the tools you actually need governed. ## Sources 1. [Okta Identity Governance product page](https://www.okta.com/products/identity-governance/) (accessed 2026-09-02) 2. [Okta pricing](https://www.okta.com/pricing/) (accessed 2026-09-02) 3. [Okta pricing, add-ons](https://www.okta.com/pricing/add-ons/) (accessed 2026-09-02) 4. [Okta help, identify AI agents with OAuth](https://help.okta.com/oie/en-us/content/topics/ai-agents/ai-agent-identify-with-oauth.htm) (accessed 2026-09-02) 5. [Okta help, SAM browser plugin](https://help.okta.com/oie/en-us/content/topics/ai-agents/ai-agent-sam-plugin.htm) (accessed 2026-09-02) 6. [Okta help, access certification remediation](https://help.okta.com/oie/en-us/content/topics/identity-governance/access-certification/remediation.htm) (accessed 2026-09-02) 7. [Okta help, Slack integration](https://help.okta.com/en-us/content/topics/identity-governance/integrations/slack.htm) (accessed 2026-09-02) 8. [Okta help, collaboration integrations best practices](https://help.okta.com/oie/en-us/content/topics/identity-governance/integrations/bp-integrations.htm) (accessed 2026-09-02) 9. [Okta help, request conditions and access duration](https://help.okta.com/oie/en-us/content/topics/identity-governance/access-requests/rcar-condition-create.htm) (accessed 2026-09-02) 10. [Okta, HR-driven IT provisioning](https://www.okta.com/solutions/hr-driven-it-provisioning/) (accessed 2026-09-02) 11. [Okta Lifecycle Management](https://www.okta.com/products/lifecycle-management/) (accessed 2026-09-02) 12. [Okta help, discover AI agents](https://help.okta.com/oie/en-us/content/topics/ai-agents/ai-agent-discover.htm) (accessed 2026-09-02) 13. [Okta, secure AI](https://www.okta.com/solutions/secure-ai/) (accessed 2026-09-02) 14. [Okta newsroom, Showcase 2026](https://www.okta.com/newsroom/press-releases/showcase-2026/) (accessed 2026-09-02) 15. [Okta help, supported languages](https://help.okta.com/oie/en-us/content/topics/reference/ref-supported-languages.htm) (accessed 2026-09-02) 16. [Okta help, auditor reporting package](https://help.okta.com/oie/en-us/content/topics/identity-governance/auditor-reporting/auditor-report-pkg.htm) (accessed 2026-09-02) 17. [Okta integrations](https://www.okta.com/integrations/) (accessed 2026-09-02) 18. [Okta blog, identity availability in EMEA](https://www.okta.com/blog/product-innovation/resilience-redefined-strengthening-identity-availability-in-emea-and-australia/) (accessed 2026-09-02) Lutril wrote this page. Facts about Okta Identity Governance come from their public documentation as of 2026-09-02. Spotted an error? Write to hello@lutril.com. --- # Lutril vs SailPoint Identity Security Cloud > SailPoint is the enterprise IGA reference: certifications, lifecycle, entitlements and, since 2026, an Agentic Fabric for AI agents, for organisations with a dedicated IAM team. Lutril delivers access governance for employees and AI agents to teams without one. Where each fits. Source: https://www.lutril.com/compare/lutril-vs-sailpoint Last reviewed: 2026-09-02 --- ## Short answer Choose SailPoint if you are a large enterprise with a dedicated IAM team, complex entitlements in ERP and on-prem systems, and a budget and timeline for a platform programme: it covers certifications, lifecycle, Slack and Teams requests, EU regions, agent identity and, through Agentic Fabric, tool-call policy and prompt redaction. Choose Lutril if you are a mid-market company that needs the same outcomes in weeks: discovery from Google Workspace or Microsoft 365 the day you connect, reviews that execute, time-boxed requests in Slack, Teams and the app UI, HRIS-driven lifecycle, and an MCP proxy with a kill switch, in one product with no add-on SKUs. ## Where each one starts **SailPoint Identity Security Cloud.** Identity-first security for humans, machines and AI, from the IGA vendor founded in 2005 in Austin and listed on NASDAQ in 2025. Suites named Standard, Agentic Business and Agentic Business Plus cover certifications, lifecycle, requests in Slack and Teams, agent ownership and, with Agentic Fabric, policy on agent tool calls. 53% of the Fortune 500 are customers. **Lutril.** Access governance for employees and AI agents built for teams without an IAM department: connect Google Workspace or Microsoft 365 and discovery starts the same day; requests, approvals and reviews run in Slack, Teams and the app UI; the HRIS drives onboarding and offboarding; every agent tool call passes through the MCP proxy. One product, hosted in France. ## Capability by capability | Capability | SailPoint Identity Security Cloud | Lutril | | --- | --- | --- | | SaaS discovery from IdP sign-in and OAuth grants (Google Workspace, Microsoft 365) | Partial: Application Visibility via IdP connections and an extension; the SaaS Management product reached end of life on June 30, 2026 [3] | Yes: Google Workspace and Microsoft 365 sign-in signals and OAuth grants, from the day you connect | | Browser extension for shadow IT and shadow AI discovery | Yes: Application Visibility extension logs sign-ins, uploads and pastes; Shadow AI Remediation extension [5] | Yes: Chrome extension for the SaaS and AI tools that skip SSO | | Access reviews whose keep-or-remove decisions execute the revocation | Yes: Direct-connect sources remove access automatically; others create a manual task [6] | Yes: Decisions execute in the connected tool; proof in the campaign export | | Access requests and approvals in Slack | Yes: Request and approve through Slack shortcuts [7] | Yes: Requests, approvals and expiry warnings in Slack | | Access requests and approvals in Microsoft Teams | Yes: Same through the SailPoint bot in Microsoft Teams [7] | Yes: Same flow in Microsoft Teams, and in the app UI | | Just-in-time, time-boxed access that expires on its own | Yes: Expiration date on requests; revocation scheduled, automatic on direct-connect sources [8] | Yes: One hour to seven days; an approver can shorten, never extend; auto-revoked | | Onboarding triggered by the HRIS | Yes: Workday connector; lifecycle states from the authoritative HR source [9] | Yes: Lucca, PayFit and Eurécia native; other HRIS through the MCP endpoint | | Offboarding that deprovisions across SaaS, including apps outside SSO | Partial: Automatic on connected sources; disconnected sources produce manual tasks [9] | Yes: Native connectors plus a universal MCP endpoint for any tool with an API | | Shadow AI discovery: AI tools and agents in use | Yes: Shadow AI Remediation, March 2026; sensors expose agents and MCP servers [10] | Yes: Sign-in logs, mailbox scanning, Chrome extension and code scanning | | AI agent registry with an accountable owner | Yes: Assign owners to AI agents with an automated succession plan [11] | Yes: Owner, model and scopes on every agent; offboarded like an employee | | MCP proxy or gateway enforcing policy on agent tool calls | Yes: Agentic Fabric evaluates policy before a call is allowed; separate offering, GA August 2026 [12] | Yes: Lutril MCP proxy: policy on every call, WORM log, global kill switch | | Prompt-level DLP and redaction for LLM traffic | Yes: Inline prompt security redacting PII before it reaches LLMs [13] | Yes: Detect and redact PII and secrets in prompts, per-model policy | | EU hosting and a French-language product | Yes: Frankfurt and London regions; French among 20+ UI languages [14] | Yes: OVHcloud, France; product and documentation in French | | Compliance evidence exports for SOC 2 and ISO 27001 | Yes: Campaign composition, status, remediation and sign-off reports in CSV or PDF [16] | Yes: Campaign export with decisions and revocation proof, one link | | Native integrations | Yes: 1,100+ enterprise applications, 20,000 custom applications [17] | Yes: More than 55 native connectors plus the universal MCP endpoint | | Published pricing | Not offered: No figures published; three suites, demo on request [2] | Not offered: On request | ## Choose SailPoint Identity Security Cloud if - You have thousands of identities across ERP, mainframe and on-prem systems and a team to run an IGA programme. - You need entitlement-level governance, separation-of-duties policy and role mining at enterprise depth. - Procurement prefers a public company with a long audit history and a large partner ecosystem. ## Choose Lutril if - You need discovery, reviews and offboarding running in weeks, not a multi-quarter implementation. - Your team has no IAM specialist: requests and reviews must live in Slack, Teams or the app UI, not in a portal. - Your estate is SaaS-first and includes the long tail signed up outside SSO. - You want agent governance, prompt DLP and a kill switch in the same product, not separate suites or add-ons. - A French-speaking team and EU hosting matter, without enterprise pricing. ## Frequently asked questions ### Is Lutril an IGA platform like SailPoint? Lutril delivers the outcomes IGA promises, access reviews, lifecycle, requests and evidence, for SaaS tools and AI agents, without the entitlement modelling depth or the implementation programme of an enterprise IGA suite. If your governance scope is SaaS and agents, that is the point. If it is SAP roles and mainframe entitlements, SailPoint is built for that. ### Does SailPoint govern AI agents through MCP? Yes, through Agentic Fabric, generally available in August 2026 as a separate offering: policy evaluation before a tool call is allowed and inline prompt redaction. Lutril's MCP proxy does the same as part of the one product, with a global kill switch and agents included in the same access reviews as employees. ### What happened to SailPoint's SaaS management? SailPoint's documentation states the SaaS Management product reached end of life on June 30, 2026. Shadow IT discovery continues through Application Visibility and the browser extension. Lutril's shadow IT and shadow AI discovery is a core, ongoing part of the platform. ### How long does each take to deploy? SailPoint deployments are programmes: sources, roles, certifications and workflows configured with an implementation partner. Lutril starts discovering the day you connect Google Workspace or Microsoft 365, then adds the HRIS and native connectors for provisioning and reviews, with nothing installed on endpoints. ## Sources 1. [SailPoint Identity Security Cloud](https://www.sailpoint.com/products/identity-security-cloud) (accessed 2026-09-02) 2. [SailPoint, Identity Security Cloud suites](https://www.sailpoint.com/products/identity-security-cloud/atlas/suites/business-plus/) (accessed 2026-09-02) 3. [SailPoint docs, Application Visibility](https://documentation.sailpoint.com/saam/help/index.html) (accessed 2026-09-02) 4. [SailPoint docs, SaaS Management end of life](https://documentation.sailpoint.com/saas-mgmt/help/index.html) (accessed 2026-09-02) 5. [SailPoint docs, Application Visibility browser extension](https://documentation.sailpoint.com/saam/help/browser_extension/index.html) (accessed 2026-09-02) 6. [SailPoint docs, completing certification campaigns](https://documentation.sailpoint.com/saas/help/certs/completing_campaigns.html) (accessed 2026-09-02) 7. [SailPoint docs, collaboration platform integrations](https://documentation.sailpoint.com/saas/help/collaboration_platform_integrations/index.html) (accessed 2026-09-02) 8. [SailPoint docs, access requests](https://documentation.sailpoint.com/saas/help/requests/index.html) (accessed 2026-09-02) 9. [SailPoint docs, lifecycle management](https://documentation.sailpoint.com/saas/help/provisioning/lifecycle.html) (accessed 2026-09-02) 10. [SailPoint press, Shadow AI Remediation](https://www.sailpoint.com/press-releases/sailpoint-launches-shadow-ai-remediation) (accessed 2026-09-02) 11. [SailPoint docs, AI agent identity](https://documentation.sailpoint.com/saas/help/agent/index.html) (accessed 2026-09-02) 12. [SailPoint, Agentic Fabric](https://www.sailpoint.com/products/agentic-fabric) (accessed 2026-09-02) 13. [SailPoint press, identity security solution for AI agents](https://www.sailpoint.com/press-releases/sailpoint-identity-security-solution) (accessed 2026-09-02) 14. [SailPoint status page, regions](https://status.sailpoint.com/) (accessed 2026-09-02) 15. [SailPoint docs, supported languages](https://documentation.sailpoint.com/saas/user-help/getting_started/supported_languages.html) (accessed 2026-09-02) 16. [SailPoint docs, campaign status reports](https://documentation.sailpoint.com/saas/help/certs/campaign_status_reports.html) (accessed 2026-09-02) 17. [SailPoint press, connectivity expands support](https://www.sailpoint.com/press-releases/sailpoint-connectivity-expands-support) (accessed 2026-09-02) 18. [SailPoint company page](https://www.sailpoint.com/company) (accessed 2026-09-02) Lutril wrote this page. Facts about SailPoint Identity Security Cloud come from their public documentation as of 2026-09-02. Spotted an error? Write to hello@lutril.com. --- # Lutril vs Nudge Security > Nudge Security is a SaaS and AI security platform that discovers every app and agent from email metadata in hours and remediates through nudges to the people involved. Lutril discovers the same estate and then governs it: requests, reviews, lifecycle and an MCP proxy. Where each fits. Source: https://www.lutril.com/compare/lutril-vs-nudge-security Last reviewed: 2026-09-02 --- ## Short answer Choose Nudge Security if your first problem is visibility: a five-minute, agentless deployment that lists every SaaS and AI tool from Google Workspace or Microsoft 365 email metadata, with published pricing and a strong AI-agent inventory, and you are comfortable remediating through nudges to app owners. Choose Lutril if you need the same discovery followed by enforcement: access reviews whose decisions execute, time-boxed requests approved in Slack, Teams or the app UI, HRIS-driven onboarding and offboarding, and an MCP proxy that applies policy to each agent tool call, hosted in the EU. ## Where each one starts **Nudge Security.** Deploy in five minutes, see all AI and SaaS in under two hours, scale risk remediation. Austin-based, founded in 2021, $22.5M Series A in November 2025. Discovery from email metadata and OAuth grants plus a browser extension; remediation through nudges to the people who own each app; published pricing with all features on every tier. **Lutril.** Discovery from the same Google Workspace and Microsoft 365 signals, a Chrome extension and code scanning, then governance: requests in Slack, Teams and the app UI with automatic expiry, reviews that revoke, HRIS-driven lifecycle, and an MCP proxy with policy on every agent call and a global kill switch. Hosted in France, in French and English. ## Capability by capability | Capability | Nudge Security | Lutril | | --- | --- | --- | | SaaS discovery from IdP sign-in and OAuth grants (Google Workspace, Microsoft 365) | Yes: Email metadata discovery via Google Workspace or Microsoft 365 read-only API; OAuth grants; Okta integration [3] | Yes: Google Workspace and Microsoft 365 sign-in signals and OAuth grants, from the day you connect | | Browser extension for shadow IT and shadow AI discovery | Yes: Extension for Chromium, Edge and Firefox; logins, AI access, file uploads [4] | Yes: Chrome extension for the SaaS and AI tools that skip SSO | | Access reviews whose keep-or-remove decisions execute the revocation | Partial: Nudges confirm accounts; changes routed to app owners for clean-up; OAuth grants auto-revoke [5] | Yes: Decisions execute in the connected tool; proof in the campaign export | | Access requests and approvals in Slack | Partial: App directory request emails or Slack-messages the technical contact; provisioning not documented [6] | Yes: Requests, approvals and expiry warnings in Slack | | Access requests and approvals in Microsoft Teams | Partial: Nudges and notifications delivered in Teams; approvals in Teams not documented [7] | Yes: Same flow in Microsoft Teams, and in the app UI | | Just-in-time, time-boxed access that expires on its own | Not documented | Yes: One hour to seven days; an approver can shorten, never extend; auto-revoked | | Onboarding triggered by the HRIS | Partial: BambooHR and Deel connected; aligns with HR offboarding events; HRIS-triggered provisioning not documented [8] | Yes: Lucca, PayFit and Eurécia native; other HRIS through the MCP endpoint | | Offboarding that deprovisions across SaaS, including apps outside SSO | Yes: Revoke OAuth grants, automate password resets on unmanaged accounts, guided nudges elsewhere [8] | Yes: Native connectors plus a universal MCP endpoint for any tool with an API | | Shadow AI discovery: AI tools and agents in use | Yes: API discovery (Agentforce, Copilot Studio, ChatGPT, n8n) plus browser discovery [9] | Yes: Sign-in logs, mailbox scanning, Chrome extension and code scanning | | AI agent registry with an accountable owner | Yes: Single agent inventory with creator; owner can be assigned separately [9] | Yes: Owner, model and scopes on every agent; offboarded like an employee | | MCP proxy or gateway enforcing policy on agent tool calls | Not documented: Flags unauthenticated MCP connections as a risk signal | Yes: Lutril MCP proxy: policy on every call, WORM log, global kill switch | | Prompt-level DLP and redaction for LLM traffic | Partial: Detects secrets, PII and PHI in AI prompts; alert, mask or store; blocking not documented [10] | Yes: Detect and redact PII and secrets in prompts, per-model policy | | EU hosting and a French-language product | Not documented: Built in AWS; no region or French UI stated | Yes: OVHcloud, France; product and documentation in French | | Compliance evidence exports for SOC 2 and ISO 27001 | Yes: SOC 2 evidence: asset inventory, review actions, offboarding records; Drata integration [11] | Yes: Campaign export with decisions and revocation proof, one link | | Native integrations | Not documented: Connect unlimited apps; no figure published | Yes: More than 55 native connectors plus the universal MCP endpoint | | Published pricing | Yes: $750 per month up to 150 users; $5 per user per month from 150 to 1,500 [2] | Not offered: On request | ## Choose Nudge Security if - You need a complete SaaS and AI inventory this week, with nothing to install and a price you can see. - Your remediation model is people-driven: nudge the owner, confirm the account, revoke the grant. - SaaS security posture (SSPM) and breach alerts matter more than access workflows. ## Choose Lutril if - Discovery is step one; you also need reviews that execute removals and requests that expire on their own. - Onboarding and offboarding must run from the HRIS with accounts created and revoked, not nudged. - AI agents need policy enforced on each MCP tool call, with a kill switch, rather than an inventory and risk flags. - Your data must stay in the EU, or your team works in French. ## Frequently asked questions ### Is Nudge Security a shadow IT discovery tool or a governance tool? Its own category is SaaS and AI security platform, or SSPM. Discovery and risk remediation through nudges are the core; access reviews route changes to app owners rather than executing them. Lutril covers the same discovery and adds the governance layer: reviews that revoke, time-boxed requests, HRIS lifecycle and an MCP proxy. ### Which one finds more AI agents? Nudge Security documents two discovery channels, API-based for platforms like Agentforce and Copilot Studio and browser-based for tools like Cursor, with an agent inventory and assignable owners. Lutril finds agents through sign-in logs, mailbox scanning, its Chrome extension and code scanning of GitHub and GitLab, then registers each one with an owner and governs its tool calls through the MCP proxy. ### Does Nudge Security block sensitive prompts? Its AI conversation monitoring detects secrets, PII and PHI in prompts and can alert, mask or store; blocking is not documented, and monitoring requires the browser extension. Lutril's prompt DLP can redact, mask or block per policy at the proxy layer. ### How do the prices compare? Nudge Security publishes $750 per month for up to 150 users and $5 per user per month from 150 to 1,500, all features included. Lutril prices on request, scoped to the people and agents governed. Compare on the outcome you need: an inventory with nudges, or an inventory with enforcement. ## Sources 1. [Nudge Security homepage](https://www.nudgesecurity.com/) (accessed 2026-09-02) 2. [Nudge Security pricing](https://www.nudgesecurity.com/pricing) (accessed 2026-09-02) 3. [Nudge Security FAQs](https://www.nudgesecurity.com/faqs) (accessed 2026-09-02) 4. [Nudge Security, browser extension](https://www.nudgesecurity.com/features/browser-extension) (accessed 2026-09-02) 5. [Nudge Security, user access reviews](https://www.nudgesecurity.com/use-cases/user-access-reviews) (accessed 2026-09-02) 6. [Nudge Security, app directory and access requests](https://www.nudgesecurity.com/post/streamline-saas-access-requests-with-nudge-securitys-new-app-directory) (accessed 2026-09-02) 7. [Nudge Security changelog, Microsoft Teams integration](https://www.nudgesecurity.com/changelog/deliver-nudges-and-receive-notification-on-microsoft-teams-with-new-integration) (accessed 2026-09-02) 8. [Nudge Security, IT offboarding](https://www.nudgesecurity.com/use-cases/it-offboarding) (accessed 2026-09-02) 9. [Nudge Security, AI agent discovery](https://www.nudgesecurity.com/features/ai-agent-discovery) (accessed 2026-09-02) 10. [Nudge Security, AI conversation monitoring](https://www.nudgesecurity.com/features/ai-conversation-monitoring) (accessed 2026-09-02) 11. [Nudge Security, SOC 2 compliance](https://www.nudgesecurity.com/use-cases/soc-2-compliance) (accessed 2026-09-02) 12. [Nudge Security press, Series A](https://www.nudgesecurity.com/press/nudge-security-raises-22-5m-series-a-to-secure-workforce-ai-and-saas) (accessed 2026-09-02) 13. [Nudge Security integrations](https://www.nudgesecurity.com/integrations) (accessed 2026-09-02) Lutril wrote this page. Facts about Nudge Security come from their public documentation as of 2026-09-02. Spotted an error? Write to hello@lutril.com. --- # Lutril vs Lumos > Lumos is an autonomous identity platform for mid-market and enterprise companies of 200 employees and up, with agentic access reviews and Slack requests. Lutril is access governance for employees and AI agents, in Slack, Teams and the app UI, hosted in the EU, with an MCP proxy. Where each fits, and the Lumos alternatives question answered. Source: https://www.lutril.com/compare/lutril-vs-lumos Last reviewed: 2026-09-02 --- ## Short answer Lumos and Lutril overlap on the core: SaaS discovery from Google Workspace and Microsoft 365, access reviews whose rejections auto-revoke, Slack requests with time-boxed grants, HRIS-driven lifecycle and an owner on every non-human identity. They differ on three things. Lumos targets companies of 200 employees and up and says a small team may find it more than it needs; Lutril is built for teams without an IAM function. Lumos ships MCP servers that expose its own product to assistants, while Lutril's MCP proxy sits in front of every SaaS tool and enforces policy on each agent call, with prompt DLP and a kill switch. And Lumos documents no EU hosting region or French UI, where Lutril is hosted in France and available in French. ## Where each one starts **Lumos.** The autonomous identity platform: agents that continuously govern access for every human, machine and AI, with an AI layer called Albus and an Identity Agent Force of out-of-the-box agents. San Francisco, $85M+ raised, Series B led by Scale in 2024, a Strong Performer in Gartner's 2026 Voice of the Customer for IGA. Requests in Slack, the IT system or through MCP; 300+ integrations. **Lutril.** Access governance for employees and AI agents in one policy layer: discovery the day you connect Google Workspace or Microsoft 365, requests in Slack, Teams and the app UI with automatic expiry, reviews that revoke, HRIS-driven lifecycle, and an MCP proxy that checks every agent tool call with prompt DLP and a global kill switch. Built by a practising CISO, hosted in France, in French and English. ## Capability by capability | Capability | Lumos | Lutril | | --- | --- | --- | | SaaS discovery from IdP sign-in and OAuth grants (Google Workspace, Microsoft 365) | Yes: Google scope to discover apps employees signed into with Google; Microsoft 365 report and audit scopes [3] | Yes: Google Workspace and Microsoft 365 sign-in signals and OAuth grants, from the day you connect | | Browser extension for shadow IT and shadow AI discovery | Partial: Browser sessions cited as a signal; no extension documented in the help centre [4] | Yes: Chrome extension for the SaaS and AI tools that skip SSO | | Access reviews whose keep-or-remove decisions execute the revocation | Yes: Auto-revoke rejected access through downstream integrations [5] | Yes: Decisions execute in the connected tool; proof in the campaign export | | Access requests and approvals in Slack | Yes: Slack app for requests, approver notifications and reminders [6] | Yes: Requests, approvals and expiry warnings in Slack | | Access requests and approvals in Microsoft Teams | Partial: Requests flow into Teams; approval inside Teams not explicitly documented [7] | Yes: Same flow in Microsoft Teams, and in the app UI | | Just-in-time, time-boxed access that expires on its own | Yes: Durations from 2 hours to 90 days, or unlimited, with automatic revocation [8] | Yes: One hour to seven days; an approver can shorten, never extend; auto-revoked | | Onboarding triggered by the HRIS | Yes: Workday, BambooHR, Rippling, ADP Workforce Now, Oracle HCM [9] | Yes: Lucca, PayFit and Eurécia native; other HRIS through the MCP endpoint | | Offboarding that deprovisions across SaaS, including apps outside SSO | Yes: One-click offboarding for SSO and non-SSO apps [10] | Yes: Native connectors plus a universal MCP endpoint for any tool with an API | | Shadow AI discovery: AI tools and agents in use | Partial: Shadow IT and AI discovered and monitored; method not documented [11] | Yes: Sign-in logs, mailbox scanning, Chrome extension and code scanning | | AI agent registry with an accountable owner | Yes: Every NHI mapped to a human owner; Agent Ownership Finder [12] | Yes: Owner, model and scopes on every agent; offboarded like an employee | | MCP proxy or gateway enforcing policy on agent tool calls | Not offered: Ships MCP servers exposing Lumos's own tools; not a proxy over third-party agent calls [13] | Yes: Lutril MCP proxy: policy on every call, WORM log, global kill switch | | Prompt-level DLP and redaction for LLM traffic | Not documented | Yes: Detect and redact PII and secrets in prompts, per-model policy | | EU hosting and a French-language product | Not documented: Privacy policy mentions transfers outside the EEA; no region or language option found | Yes: OVHcloud, France; product and documentation in French | | Compliance evidence exports for SOC 2 and ISO 27001 | Yes: Evidence-backed reports formatted for SOC 2, SOX and ISO 27001 [5] | Yes: Campaign export with decisions and revocation proof, one link | | Native integrations | Yes: 300+ integrations [15] | Yes: More than 55 native connectors plus the universal MCP endpoint | | Published pricing | Not offered: Pricing page without figures [2] | Not offered: On request | ## Choose Lumos if - You have 200 employees or more, an IT or IAM team to run it, and want AI-assisted reviews and an agent workforce inside the identity platform. - Your HRIS is Workday, ADP or Oracle HCM and your integrations are already in Lumos's catalogue. - US hosting is acceptable and an English-only product is fine. ## Choose Lutril if - You are a mid-market company without an IAM team and need discovery, reviews and offboarding running in weeks. - AI agents call your SaaS tools and you need a proxy that enforces policy on each MCP call, with prompt DLP and a kill switch, not only ownership mapping. - Requests and approvals must run in Microsoft Teams as well as Slack. - Your data has to stay in the EU, or your team works in French. ## Frequently asked questions ### What are the best alternatives to Lumos for access reviews? Look for a tool whose review decisions execute the removal, that covers apps outside SSO, and that exports evidence an auditor accepts. Lutril, C1 (formerly ConductorOne), Zluri, Torii and Okta Identity Governance all run campaigns; they differ on automatic remediation, Teams support, EU hosting and AI agent coverage. Lutril's campaigns include registered AI agents alongside employees, execute removals in the connected tool, and export one link with the decisions and the revocation proof. ### Does Lumos govern AI agents through MCP? Lumos governs non-human identities, maps each to a human owner and ships MCP servers so assistants can request access or administer Lumos itself. It does not document a proxy that sits in front of third-party SaaS tools and enforces policy on each agent tool call. That proxy is what Lutril's MCP proxy is: one endpoint for every connected tool, role-based policy per call, a WORM log, prompt DLP and a global kill switch. ### Is Lumos suitable for a company of 80 people? Lumos's own comparison content says it targets mid-market and enterprise, generally 200 or more employees, and that a small team may find it more capability than it needs. Lutril is designed for teams with no dedicated IAM function, with discovery starting the day you connect your workspace. ### Where is each product hosted? Lumos's privacy policy refers to transfers outside the EEA with safeguards; we found no documented EU region or French-language option. Lutril is hosted at OVHcloud in France, with Cloudflare at the edge, and the product and documentation exist in French and English. ## Sources 1. [Lumos homepage](https://www.lumos.com) (accessed 2026-09-02) 2. [Lumos pricing](https://www.lumos.com/pricing) (accessed 2026-09-02) 3. [Lumos help, connecting Google Workspace](https://lumos.help.usepylon.com/articles/1877502581-connecting-google-workspace) (accessed 2026-09-02) 4. [Lumos, Zluri alternatives and competitors](https://www.lumos.com/identity-matters/identity-governance/zluri-alternatives-and-competitors) (accessed 2026-09-02) 5. [Lumos, access reviews](https://www.lumos.com/products/access-reviews) (accessed 2026-09-02) 6. [Lumos help, connecting Slack](https://support.lumos.com/articles/3448469670-connecting-slack) (accessed 2026-09-02) 7. [Lumos, Microsoft Teams integration](https://www.lumos.com/integrations/microsoft-teams) (accessed 2026-09-02) 8. [Lumos help, AppStore quick start](https://support.lumos.com/articles/7910043985-lumos-appstore-quick-start-guide) (accessed 2026-09-02) 9. [Lumos, lifecycle management](https://www.lumos.com/products/lifecycle-management) (accessed 2026-09-02) 10. [Lumos, JML workflow orchestration](https://www.lumos.com/solutions/jml-workflow-orchestration) (accessed 2026-09-02) 11. [Lumos, identity security posture](https://www.lumos.com/solutions/identity-security-posture) (accessed 2026-09-02) 12. [Lumos, non-human identities](https://www.lumos.com/solutions/non-human-identities) (accessed 2026-09-02) 13. [Lumos developers, MCP](https://developers.lumos.com/docs/mcp) (accessed 2026-09-02) 14. [Lumos privacy policy](https://www.lumos.com/privacy) (accessed 2026-09-02) 15. [Lumos integrations](https://www.lumos.com/integrations) (accessed 2026-09-02) 16. [Lumos, ConductorOne competitors and alternatives](https://www.lumos.com/identity-matters/identity-governance/conductorone-competitors-and-alternatives) (accessed 2026-09-02) 17. [Lumos, about](https://www.lumos.com/company/about) (accessed 2026-09-02) Lutril wrote this page. Facts about Lumos come from their public documentation as of 2026-09-02. Spotted an error? Write to hello@lutril.com. --- # Lutril vs Zluri > Zluri is a SaaS management platform turned identity security suite, a Gartner Magic Quadrant Leader for SMPs, with eight discovery methods and Slack-native requests. Lutril is access governance for employees and AI agents, in Slack, Teams and the app UI, hosted in the EU, with an MCP proxy. Where each fits. Source: https://www.lutril.com/compare/lutril-vs-zluri Last reviewed: 2026-09-02 --- ## Short answer Choose Zluri if SaaS management is the centre of the job: discovery from eight parallel sources against a 240,000-app library, licence and spend optimisation, and Slack-native requests with time-boxed grants, for an enterprise or mid-market team. Choose Lutril if the job is access governance across employees and AI agents: reviews whose decisions execute without waiting for an admin to conclude the review, requests in Microsoft Teams as well as Slack, an MCP proxy with policy on each agent tool call and prompt DLP, and hosting in the EU with a French-language product. Zluri states it does not capture prompt content and documents notifications only in email and Slack. ## Where each one starts **Zluri.** Identity security for autonomous enterprises: discover, govern and secure every human and non-human identity, across four lines (identity visibility, IGA, ISPM and SaaS management). Milpitas, founded 2020, $32M raised with a Series B led by Lightspeed in 2023, a Leader in Gartner's Magic Quadrant for SaaS Management Platforms in 2024 and 2025. 300+ connectors. **Lutril.** Access governance for employees and AI agents: discovery from Google Workspace and Microsoft 365, a Chrome extension and code scanning; requests in Slack, Teams and the app UI with automatic expiry; reviews that revoke; HRIS-driven lifecycle; and an MCP proxy with prompt DLP and a global kill switch. Hosted in France, in French and English. ## Capability by capability | Capability | Zluri | Lutril | | --- | --- | --- | | SaaS discovery from IdP sign-in and OAuth grants (Google Workspace, Microsoft 365) | Yes: Google Workspace and Entra ID integrations: accounts, usage, third-party apps connected [3] | Yes: Google Workspace and Microsoft 365 sign-in signals and OAuth grants, from the day you connect | | Browser extension for shadow IT and shadow AI discovery | Yes: Chrome, Firefox, Edge and Brave; logs URLs and titles, no content [4] | Yes: Chrome extension for the SaaS and AI tools that skip SSO | | Access reviews whose keep-or-remove decisions execute the revocation | Partial: Remediation playbooks run after an admin concludes the review; manual task for non-integrated apps [5] | Yes: Decisions execute in the connected tool; proof in the campaign export | | Access requests and approvals in Slack | Yes: Request, approve and reject in Slack; provisioning playbook on approval [6] | Yes: Requests, approvals and expiry warnings in Slack | | Access requests and approvals in Microsoft Teams | Not offered: Notification channels documented as email and Slack [7] | Yes: Same flow in Microsoft Teams, and in the app UI | | Just-in-time, time-boxed access that expires on its own | Yes: Access duration on requests; deprovisioning playbook on expiry [8] | Yes: One hour to seven days; an approver can shorten, never extend; auto-revoked | | Onboarding triggered by the HRIS | Yes: HiBob, Personio, BambooHR, Workday; set up with a customer success manager [9] | Yes: Lucca, PayFit and Eurécia native; other HRIS through the MCP endpoint | | Offboarding that deprovisions across SaaS, including apps outside SSO | Yes: Revokes access to SSO and non-SSO apps [10] | Yes: Native connectors plus a universal MCP endpoint for any tool with an API | | Shadow AI discovery: AI tools and agents in use | Yes: AI apps across 37+ sub-categories; AI agents discovered as NHIs [11] | Yes: Sign-in logs, mailbox scanning, Chrome extension and code scanning | | AI agent registry with an accountable owner | Yes: Service accounts, tokens, bots and AI agents with enforced ownership [12] | Yes: Owner, model and scopes on every agent; offboarded like an employee | | MCP proxy or gateway enforcing policy on agent tool calls | Not documented | Yes: Lutril MCP proxy: policy on every call, WORM log, global kill switch | | Prompt-level DLP and redaction for LLM traffic | Not offered: Vendor: does not capture prompt content or the data payloads sent to AI models [11] | Yes: Detect and redact PII and secrets in prompts, per-model policy | | EU hosting and a French-language product | Partial: AWS-hosted; only the PII vault region is customer-selectable; no French UI documented [13] | Yes: OVHcloud, France; product and documentation in French | | Compliance evidence exports for SOC 2 and ISO 27001 | Yes: Certification exports in CSV and timestamped PDF for SOC 2, ISO 27001, SOX [5] | Yes: Campaign export with decisions and revocation proof, one link | | Native integrations | Yes: 300+ connectors [14] | Yes: More than 55 native connectors plus the universal MCP endpoint | | Published pricing | Not offered: Pricing page is a demo request [2] | Not offered: On request | ## Choose Zluri if - SaaS spend, licence reclamation and renewals are as important to you as access. - You want discovery from finance systems, CASB and MDM in addition to the identity provider. - Your team lives in Slack and does not need Microsoft Teams. ## Choose Lutril if - Review decisions should execute in the tool the moment the reviewer decides, with the proof attached. - Requests and approvals must run in Microsoft Teams as well as Slack and the app UI. - AI agents need policy on each MCP tool call and prompt-level DLP, not only an inventory with owners. - Your data has to stay in the EU, or your team works in French. ## Frequently asked questions ### Is Zluri an access governance tool or a SaaS management tool? Both, by its own positioning: it started as a SaaS management platform and now sells identity governance and posture lines on the same discovery engine. Lutril is access governance first, for employees and AI agents, with shadow IT and shadow AI discovery as the entry point rather than spend management. ### Do Zluri access reviews revoke access automatically? Zluri's documentation says remediation playbooks run after the admin clicks Conclude Review, automatically for integrated apps and as a manual task otherwise. In Lutril each keep-or-remove decision executes in the connected tool, and the campaign export carries the revocation proof next to the decision. ### Which one supports Microsoft Teams? Zluri documents email and Slack as notification channels and manages Teams as an application. Lutril runs requests, approvals and expiry warnings in Slack, Microsoft Teams and the app UI. ### Can either one see what employees send to AI tools? Zluri states it does not capture prompt content, keystrokes or the payloads sent to AI models; its shadow AI coverage is usage and identity based. Lutril adds prompt-level DLP at the proxy layer: detect and redact PII and secrets before they reach the model, with a per-model policy and an immutable log. ## Sources 1. [Zluri homepage](https://www.zluri.com) (accessed 2026-09-02) 2. [Zluri pricing](https://www.zluri.com/pricing) (accessed 2026-09-02) 3. [Zluri help, Google Workspace integration](https://help.zluri.com/docs/google-workspace-integration) (accessed 2026-09-02) 4. [Zluri, how the discovery engine works](https://www.zluri.com/blog/how-zluris-discovery-engine-works) (accessed 2026-09-02) 5. [Zluri help, closing and completing certifications](https://help.zluri.com/docs/closing-and-completing-certifications) (accessed 2026-09-02) 6. [Zluri, access requests](https://www.zluri.com/features/access-requests) (accessed 2026-09-02) 7. [Zluri help, notification customization](https://help.zluri.com/docs/notification-customization) (accessed 2026-09-02) 8. [Zluri help, automation rules](https://help.zluri.com/docs/automation-rules-1) (accessed 2026-09-02) 9. [Zluri help, zero touch onboarding](https://help.zluri.com/docs/zero-touch-onboarding) (accessed 2026-09-02) 10. [Zluri, secure deprovisioning](https://www.zluri.com/features/secure-deprovisioning) (accessed 2026-09-02) 11. [Zluri, shadow AI governance tools](https://www.zluri.com/eye-on-identity/shadow-ai-governance-tools) (accessed 2026-09-02) 12. [Zluri, identity visibility and intelligence](https://www.zluri.com/products/identity-visibility-and-intelligence) (accessed 2026-09-02) 13. [Zluri security](https://www.zluri.com/security) (accessed 2026-09-02) 14. [Zluri integrations](https://www.zluri.com/integrations) (accessed 2026-09-02) 15. [Zluri, Series B funding](https://www.zluri.com/blog/series-b-funding) (accessed 2026-09-02) Lutril wrote this page. Facts about Zluri come from their public documentation as of 2026-09-02. Spotted an error? Write to hello@lutril.com. --- # Lutril vs Torii > Torii is a SaaS and AI management platform, a Gartner Magic Quadrant Leader, that added access governance, temporary access and Slack and Teams agents through 2026. Lutril is access governance for employees and AI agents, hosted in the EU, with an MCP proxy and prompt DLP. Where each fits. Source: https://www.lutril.com/compare/lutril-vs-torii Last reviewed: 2026-09-02 --- ## Short answer Choose Torii if SaaS management is the anchor, with spend, renewals and licence data alongside discovery, and you want the access governance features it shipped in 2026: temporary access, request agents in Slack and Teams, review remediation. Choose Lutril if the anchor is access governance for employees and AI agents: policy-driven requests in Slack, Teams and the app UI, reviews that execute, HRIS-driven lifecycle, and an MCP proxy that enforces policy on every agent tool call with prompt DLP, in the EU and in French. Torii documents that EU customers use its US instance and recommends pairing with a separate runtime DLP layer. ## Where each one starts **Torii.** Take control of every app, licence and AI tool: a SaaS and AI management platform with three product lines (SaaS management, identity governance, AI management), a Leader in Gartner's Magic Quadrant for SaaS Management Platforms for the third year in 2026. New York and Israel, founded 2017, $65M raised with a Series B led by Tiger Global in 2022. **Lutril.** Access governance for employees and AI agents: discovery from Google Workspace and Microsoft 365, a Chrome extension and code scanning; requests in Slack, Teams and the app UI with automatic expiry; reviews that revoke; HRIS-driven lifecycle; and an MCP proxy with prompt DLP and a global kill switch. Hosted in France, in French and English. ## Capability by capability | Capability | Torii | Lutril | | --- | --- | --- | | SaaS discovery from IdP sign-in and OAuth grants (Google Workspace, Microsoft 365) | Yes: Google Workspace and Microsoft 365 integrations pull users, usage and third-party apps [3] | Yes: Google Workspace and Microsoft 365 sign-in signals and OAuth grants, from the day you connect | | Browser extension for shadow IT and shadow AI discovery | Yes: Extension detects logins to business applications [4] | Yes: Chrome extension for the SaaS and AI tools that skip SSO | | Access reviews whose keep-or-remove decisions execute the revocation | Yes: Since August 2026: reviewers trigger an action and Torii resyncs the app [5] | Yes: Decisions execute in the connected tool; proof in the campaign export | | Access requests and approvals in Slack | Yes: Slack agent for catalogue requests; approve or deny in Slack [6] | Yes: Requests, approvals and expiry warnings in Slack | | Access requests and approvals in Microsoft Teams | Yes: Teams agent for requests; approvals inline in Teams [7] | Yes: Same flow in Microsoft Teams, and in the app UI | | Just-in-time, time-boxed access that expires on its own | Yes: Temporary access with deprovisioning workflows and admin-set durations [8] | Yes: One hour to seven days; an approver can shorten, never extend; auto-revoked | | Onboarding triggered by the HRIS | Yes: Workday, BambooHR, HiBob, Rippling, Personio, SuccessFactors and more [9] | Yes: Lucca, PayFit and Eurécia native; other HRIS through the MCP endpoint | | Offboarding that deprovisions across SaaS, including apps outside SSO | Yes: Revokes every app, including the ones the IdP never saw [10] | Yes: Native connectors plus a universal MCP endpoint for any tool with an API | | Shadow AI discovery: AI tools and agents in use | Partial: AI tools discovered with sign-up alerts; AI agent discovery not documented [11] | Yes: Sign-in logs, mailbox scanning, Chrome extension and code scanning | | AI agent registry with an accountable owner | Partial: Service accounts, bots and API keys get a human owner; AI agents not named [12] | Yes: Owner, model and scopes on every agent; offboarded like an employee | | MCP proxy or gateway enforcing policy on agent tool calls | Not offered: Torii's MCP server exposes Torii data to assistants; no enforcement on agent tool calls [13] | Yes: Lutril MCP proxy: policy on every call, WORM log, global kill switch | | Prompt-level DLP and redaction for LLM traffic | Not offered: Torii recommends pairing with a runtime DLP layer [14] | Yes: Detect and redact PII and secrets in prompts, per-model policy | | EU hosting and a French-language product | Not offered: EU customers use the US instance; French UI not documented [15] | Yes: OVHcloud, France; product and documentation in French | | Compliance evidence exports for SOC 2 and ISO 27001 | Partial: Full decision trail export; no SOC 2 or ISO formatted package documented [16] | Yes: Campaign export with decisions and revocation proof, one link | | Native integrations | Partial: Hundreds of pre-built integrations; no figure published [1] | Yes: More than 55 native connectors plus the universal MCP endpoint | | Published pricing | Not offered: Pricing page without figures; access governance requires the Identity module [2] | Not offered: On request | ## Choose Torii if - Licences, renewals and spend are the first problem and access is the second. - You want a Gartner Leader for SaaS management with discovery from finance systems as well as the IdP. - US hosting is acceptable and you can pair a separate DLP product for AI traffic. ## Choose Lutril if - Access governance is the job, and AI agents are already part of it: you need a proxy on each MCP tool call, prompt DLP and a kill switch in one product. - Your data has to stay in the EU, or your team works in French. - You want one product rather than separate SaaS management, identity and AI management modules. - Audit evidence should come out as one link with decisions and revocation proof, mapped to SOC 2 and ISO 27001. ## Frequently asked questions ### Does Torii do access governance now? Yes. Torii's product updates show access governance going generally available in June 2026, temporary access in July, Slack and Teams request agents in June and July, and automated review remediation in August. It requires the Torii Identity module. Lutril has been access governance from the start, with AI agents governed the same way as employees. ### Does Torii govern AI agents through MCP? Torii offers an MCP server that lets assistants query Torii data, and its own articles state it has no on-premise runtime control and recommend pairing it with a runtime DLP layer. Lutril's MCP proxy sits in front of your SaaS tools, enforces policy on each agent call, redacts sensitive data in prompts and can pause any agent instantly. ### Where does Torii store data for European customers? Torii's GDPR documentation states that EU citizens may use its US instance, and its sub-processor list is US-based, with standard contractual clauses for transfers. Lutril is hosted at OVHcloud in France. ### Which one is better for shadow IT discovery? Both discover from the identity provider and a browser extension. Torii adds finance-system discovery for spend. Lutril adds mailbox scanning for sign-up receipts and code scanning for agents in GitHub and GitLab, then puts every discovered app or agent under access governance with an owner and a decision. ## Sources 1. [Torii homepage](https://www.toriihq.com) (accessed 2026-09-02) 2. [Torii pricing](https://www.toriihq.com/pricing) (accessed 2026-09-02) 3. [Torii, Google Workspace integration](https://www.toriihq.com/integration/google-workspace) (accessed 2026-09-02) 4. [Torii, browser extension](https://www.toriihq.com/browser-extension) (accessed 2026-09-02) 5. [Torii product updates, access reviews automated remediation](https://product-updates.toriihq.com/r/access-reviews-automated-remediation-is-live-436479) (accessed 2026-09-02) 6. [Torii product updates, Slack agent for app catalog](https://product-updates.toriihq.com/r/slack-agent-for-app-catalog-is-live-933329) (accessed 2026-09-02) 7. [Torii product updates, Teams agent for app catalog](https://product-updates.toriihq.com/r/teams-agent-for-app-catalog-is-live-401219) (accessed 2026-09-02) 8. [Torii product updates, temporary access management](https://product-updates.toriihq.com/r/temporary-access-management-leveled-up-893619) (accessed 2026-09-02) 9. [Torii, department-based onboarding workflow](https://www.toriihq.com/workflow/onboarding-department-based) (accessed 2026-09-02) 10. [Torii, real-time offboarding workflow](https://www.toriihq.com/workflow/offboarding-real-time) (accessed 2026-09-02) 11. [Torii, AI management platform](https://www.toriihq.com/ai-management-platform-working) (accessed 2026-09-02) 12. [Torii, non-human identities](https://www.toriihq.com/solutions/non-human-identities) (accessed 2026-09-02) 13. [Torii, introducing Model Context Protocol in Torii](https://www.toriihq.com/blog/introducing-model-context-protocol-in-torii) (accessed 2026-09-02) 14. [Torii, six tools for AI governance and policy enforcement](https://www.toriihq.com/articles/six-tools-for-ai-governance-and-policy-enforcement) (accessed 2026-09-02) 15. [Torii, GDPR](https://www.toriihq.com/docs/gdpr) (accessed 2026-09-02) 16. [Torii, identity governance platform](https://www.toriihq.com/products/identity-governance-platform) (accessed 2026-09-02) 17. [Torii, Gartner Magic Quadrant for SaaS Management Platforms](https://www.toriihq.com/reports/gartner-magic-quadrant-for-saas-management-platforms) (accessed 2026-09-02) 18. [Torii, Series B led by Tiger Global](https://www.toriihq.com/blog/torii-raises-50m-series-b-led-by-tiger-global) (accessed 2026-09-02) Lutril wrote this page. Facts about Torii come from their public documentation as of 2026-09-02. Spotted an error? Write to hello@lutril.com. --- # Lutril vs C1 (formerly ConductorOne) > C1, the identity platform formerly known as ConductorOne, governs human, non-human and AI identities for Fortune 500 and hypergrowth enterprises, with an MCP Gateway. Lutril delivers access governance for employees and AI agents to mid-market teams, in the EU and in French. Where each fits. Source: https://www.lutril.com/compare/lutril-vs-conductorone Last reviewed: 2026-09-02 --- ## Short answer C1 and Lutril are the two products on this site that govern AI agents at the tool-call level: both register agents as identities and both enforce policy in front of MCP tool calls. C1 is built for Fortune 500 and hypergrowth enterprises, with 400+ connectors, an open-source connector SDK, Slack and Teams requests and a consumption-billed AI access module; its sub-processors are in the United States and prompt DLP is described as in progress. Lutril is built for mid-market teams: the same request, review and lifecycle outcomes in Slack, Teams and the app UI, prompt DLP shipped in the MCP proxy, a browser extension for shadow SaaS and AI, EU hosting and a French-language product. ## Where each one starts **C1 (formerly ConductorOne).** An AI-native identity platform governing access for human, non-human and AI identities, and the control plane for the agentic enterprise: Lifecycle, Access, Comply, LLM Gateway, MCP Gateway, Vault, Worker and Bridge. Rebranded from ConductorOne to C1 in April 2026. San Francisco and Portland, founded late 2020, $79M Series B led by Greycroft in October 2025, more than $100M raised. **Lutril.** Access governance for employees and AI agents in one product: discovery from Google Workspace and Microsoft 365, a Chrome extension and code scanning; requests in Slack, Teams and the app UI with automatic expiry; reviews that revoke; HRIS-driven lifecycle; and an MCP proxy with policy on every call, prompt DLP and a global kill switch. Hosted in France, in French and English. ## Capability by capability | Capability | C1 (formerly ConductorOne) | Lutril | | --- | --- | --- | | SaaS discovery from IdP sign-in and OAuth grants (Google Workspace, Microsoft 365) | Yes: Shadow apps detected from Okta, Google Workspace and Entra ID logins; OAuth scopes monitored [3] | Yes: Google Workspace and Microsoft 365 sign-in signals and OAuth grants, from the day you connect | | Browser extension for shadow IT and shadow AI discovery | Not documented | Yes: Chrome extension for the SaaS and AI tools that skip SSO | | Access reviews whose keep-or-remove decisions execute the revocation | Yes: Policy auto-creates a revoke task on denial; connector deprovisions, manual task otherwise [4] | Yes: Decisions execute in the connected tool; proof in the campaign export | | Access requests and approvals in Slack | Yes: /c1 request in Slack; approve or deny without leaving Slack [5] | Yes: Requests, approvals and expiry warnings in Slack | | Access requests and approvals in Microsoft Teams | Yes: Approve and deny in Teams since November 2025; create requests in Teams since early 2026 [6] | Yes: Same flow in Microsoft Teams, and in the app UI | | Just-in-time, time-boxed access that expires on its own | Yes: Time-limited grants expire automatically with reminders [7] | Yes: One hour to seven days; an approver can shorten, never extend; auto-revoked | | Onboarding triggered by the HRIS | Yes: Inbound webhooks for Workday and BambooHR; SAP SuccessFactors connector [8] | Yes: Lucca, PayFit and Eurécia native; other HRIS through the MCP endpoint | | Offboarding that deprovisions across SaaS, including apps outside SSO | Yes: Deprovision via connector, IdP, ticket, webhook or manual task; not all connectors support it [9] | Yes: Native connectors plus a universal MCP endpoint for any tool with an API | | Shadow AI discovery: AI tools and agents in use | Yes: Finds agents and service accounts across Agentforce, Bedrock, Entra, Okta, GCP, GitHub; scans for MCP configs [10] | Yes: Sign-in logs, mailbox scanning, Chrome extension and code scanning | | AI agent registry with an accountable owner | Yes: Identities and NHI dashboard with ownership status; standalone agents get their own identity [11] | Yes: Owner, model and scopes on every agent; offboarded like an employee | | MCP proxy or gateway enforcing policy on agent tool calls | Yes: MCP Gateway: identity-aware policy in front of every MCP tool call; approval for high-risk calls [11] | Yes: Lutril MCP proxy: policy on every call, WORM log, global kill switch | | Prompt-level DLP and redaction for LLM traffic | Not offered: LLM Gateway does routing and cost; DLP hooks described as being built [12] | Yes: Detect and redact PII and secrets in prompts, per-model policy | | EU hosting and a French-language product | Not offered: Sub-processors in the United States; DPA authorises EEA-to-US transfer; no French UI documented [13] | Yes: OVHcloud, France; product and documentation in French | | Compliance evidence exports for SOC 2 and ISO 27001 | Yes: Audit-ready reports on demand; evidence timestamped, attributed and exportable [14] | Yes: Campaign export with decisions and revocation proof, one link | | Native integrations | Yes: 400+ prebuilt connectors, plus an open-source connector SDK [15] | Yes: More than 55 native connectors plus the universal MCP endpoint | | Published pricing | Not offered: Pricing page without figures; platform tiers by managed identities, or usage-based tokens [2] | Not offered: On request | ## Choose C1 (formerly ConductorOne) if - You are a large or hypergrowth enterprise with hybrid infrastructure: Active Directory, LDAP, databases, cloud, and a team to run a platform. - You need an open-source connector SDK to build integrations for in-house systems. - US hosting is acceptable and AI agent access can be billed on consumption. ## Choose Lutril if - You are a mid-market company and want agent governance, prompt DLP and a kill switch shipped in one product, priced on the people and agents governed. - Your data has to stay in the EU, or your team works in French. - You want a browser extension and mailbox scanning to catch the SaaS and AI tools that never touch the identity provider. - Reviews and approvals should happen in Slack, Teams or the app UI, not in a web console only. ## Frequently asked questions ### What is C1, and what happened to ConductorOne? ConductorOne rebranded to C1 on April 6, 2026; conductorone.com now redirects to c1.ai. The product is the same identity platform, positioned as AI-native and as a control plane for the agentic enterprise, with an MCP Gateway and an LLM Gateway alongside lifecycle, access and compliance modules. ### Both have an MCP gateway. What is the difference? Both put identity-aware policy in front of MCP tool calls and register agents as identities. C1 documents auto-approval for low-risk calls and human approval for high-risk ones, with a consumption-billed AI access module. Lutril's MCP proxy adds prompt-level DLP that redacts PII and secrets before the model sees them, a WORM audit log, a global kill switch, and one MCP endpoint that exposes any connected SaaS tool, all in the base product. ### Which one fits a company of 150 to 1,500 people? C1 targets Fortune 500 and hypergrowth enterprises and also publishes an SMB solution page. Lutril is designed for mid-market teams without an IAM function, with discovery starting the day you connect Google Workspace or Microsoft 365 and requests running where people already work. ### Where is each product hosted? C1's sub-processor list is US-based and its data processing agreement authorises transfers from the EEA to the United States. Lutril is hosted at OVHcloud in France, with Cloudflare at the edge. ## Sources 1. [C1 homepage](https://www.c1.ai/) (accessed 2026-09-02) 2. [C1 pricing](https://www.c1.ai/pricing) (accessed 2026-09-02) 3. [C1 docs, shadow apps](https://www.c1.ai/docs/product/admin/shadow-apps) (accessed 2026-09-02) 4. [C1 docs, policies](https://www.c1.ai/docs/product/admin/policies) (accessed 2026-09-02) 5. [C1 docs, Slack application](https://www.c1.ai/docs/product/admin/slack-application) (accessed 2026-09-02) 6. [C1 blog, advanced Microsoft Teams integration](https://www.c1.ai/blog/introducing-conductorones-advanced-microsoft-teams-integration/) (accessed 2026-09-02) 7. [C1 docs, create requests](https://www.c1.ai/docs/product/how-to/create-requests) (accessed 2026-09-02) 8. [C1 docs, inbound webhooks](https://www.c1.ai/docs/product/admin/webhooks-inbound) (accessed 2026-09-02) 9. [C1 docs, provisioning](https://www.c1.ai/docs/product/admin/provisioning) (accessed 2026-09-02) 10. [C1, shadow AI discovery](https://www.c1.ai/solutions/shadow-ai-discovery) (accessed 2026-09-02) 11. [C1, MCP Gateway](https://www.c1.ai/products/mcp-gateway) (accessed 2026-09-02) 12. [C1 blog, AI access management, your questions answered](https://www.c1.ai/blog/ai-access-management-your-questions-answered) (accessed 2026-09-02) 13. [C1 legal, sub-processors](https://www.c1.ai/legal/subprocessors) (accessed 2026-09-02) 14. [C1, Comply](https://www.c1.ai/products/comply) (accessed 2026-09-02) 15. [C1 integrations](https://www.c1.ai/integrations) (accessed 2026-09-02) 16. [C1 blog, we are C1](https://www.c1.ai/blog/wearec1) (accessed 2026-09-02) 17. [C1 press, $79M Series B](https://www.c1.ai/news/press-release/conductorone-raises-79-million-series-b) (accessed 2026-09-02) 18. [C1 docs, review tasks](https://www.c1.ai/docs/product/how-to/review-tasks) (accessed 2026-09-02) Lutril wrote this page. Facts about C1 (formerly ConductorOne) come from their public documentation as of 2026-09-02. Spotted an error? Write to hello@lutril.com. --- # MCP gateways compared: MintMCP, Cerbos, Datawiza and Lutril > What an MCP gateway does, which products enforce policy on AI agent tool calls, and how MintMCP, Cerbos, Datawiza and Lutril differ on agent identity, audit, kill switch, DLP, human approvals and whether they also govern the employees behind the agents. Source: https://www.lutril.com/compare/mcp-gateways Last reviewed: 2026-09-02 --- ## Short answer The best MCP gateway to enforce policy on AI agent tool calls depends on what else you need governed. MintMCP is a dedicated gateway with programmable middleware, signed append-only audit records and an org-wide kill switch, and stops at MCP tool entitlements. Cerbos is an open-source authorization decision point that a gateway calls; it does not proxy traffic itself. Datawiza is an inline proxy with credential brokering for agents and legacy apps, with human approval routing. Lutril is an MCP proxy inside an access governance platform: every agent has an owner, every call is checked against the same role-based policy used for employees, prompts pass through DLP, calls land in a WORM log, one kill switch pauses any agent, and the same product runs access reviews, onboarding and offboarding for the humans who own those agents, with approvals in Slack, Teams or the app UI. ## Where each one starts **MintMCP.** MCP gateway and AI agent infrastructure: give your team AI everywhere while staying in control. A gateway that makes 10,000+ MCP servers enterprise-ready with hosted connectors, plus Agent Monitor for coding agents. Founded by early Google Brain members, backed by Coatue and angels including Andrej Karpathy and Jeff Dean; launched publicly in February 2026. SOC 2 Type II, cloud or self-hosted. **Cerbos.** Authorize every identity, govern every action: an authorization management platform with an Apache-2.0 open-source policy decision point, Cerbos Hub as the managed control plane and Cerbos Synapse for identity enrichment. London, founded 2021, $11M raised. Integrates with gateways such as agentgateway through Envoy ext_authz to decide on each tool call. **Datawiza.** Secure AI agents and critical apps with zero-trust, identity-aware runtime enforcement: an Access Proxy for legacy and on-prem applications and an Agent Gateway that sits between agents and the tools, APIs, MCP servers and SaaS systems they reach, brokering credentials and applying policy before tool calls. Campbell, California, founded 2021, Microsoft security partner. **Lutril.** The MCP proxy is one part of an access governance platform for employees and AI agents. Agents are registered with an owner and scopes, every call passes through role-based policy, prompt DLP and a WORM log, one kill switch pauses any agent, and the same product runs shadow AI discovery, access reviews, onboarding and offboarding, with approvals in Slack, Teams and the app UI. Hosted in France. ## Capability by capability | Capability | MintMCP | Cerbos | Datawiza | Lutril | | --- | --- | --- | --- | --- | | Acts as an MCP gateway between agents and tool servers | Yes: Sits between AI clients and MCP servers, handling authentication [2] | Not offered: A decision point the gateway calls; Cerbos states it is not the gateway [15] | Yes: Reverse proxy between MCP clients and servers, no server code changes [23] | Yes: One MCP endpoint for every connected SaaS tool | | Per-tool-call policy, including parameters | Yes: Middleware blocks on tool name, argument values or prompt content [3] | Yes: Policy reads structured arguments joined with the calling identity [16] | Yes: Decisions on identity, role, resource, action, parameters, environment and risk [23] | Yes: Role, tool, parameters and rate limits checked before the call leaves | | Agent identity with an owner and scoped credentials | Partial: Named org-scoped principals with expiring keys; creator recorded, no ongoing owner field [4] | Partial: Synapse passes the delegating user's identity; registry and credentials are not Cerbos features [17] | Partial: Agents authenticate via IdP or per-agent virtual key; owner assignment not documented [25] | Yes: Owner, model and scopes on every agent; short-lived scoped credentials | | Immutable or tamper-evident audit log of tool calls | Yes: Signed, append-only records with a published verification key; SIEM export [5] | Partial: Decision logs with inputs and policy version; no immutability claim [18] | Partial: Logs identity, agent, tool, parameters and decision; no immutability claim [25] | Yes: Prompts, calls and responses in a WORM log | | Kill switch: pause one or all agents instantly | Yes: Org-wide switch rejects every call immediately; per-tool disables [6] | Partial: A revocable task authority pattern, not a button [16] | Partial: Per-agent key revocation; no documented all-agents switch [26] | Yes: Global kill switch across every connected tool | | Human access governance: reviews, onboarding, offboarding | Partial: SCIM groups drive MCP tool access; no access reviews; MCP scope only [7] | Not offered: Application and API authorization; no reviews or lifecycle [14] | Not offered: Access Proxy adds SSO, MFA and RBAC to apps; no reviews or lifecycle [27] | Yes: Same product runs reviews, HRIS onboarding and offboarding | | SaaS discovery: shadow IT and shadow AI | Partial: Agent Monitor sees coding agents' tool calls; vendor says it is not a discovery tool [8] | Not offered: Discovery left to the gateway; no SaaS discovery [15] | Not offered: Inline enforcement only; no discovery offering [28] | Yes: Sign-in logs, mailbox scanning, Chrome extension, code scanning | | Prompt-level DLP and redaction | Yes: Mask action on arguments and results; DLP provider templates; prompt masking falls back to block [3] | Not offered: Permission-aware filtering and log masking only [22] | Partial: Data protection guardrails stated; redaction mechanism not documented [29] | Yes: Detect and redact PII and secrets before the model sees them | | Exposes SaaS actions as MCP tools without a vendor MCP server | Partial: Hosts open-source or custom MCP servers; wrapping an arbitrary API not documented [9] | Not offered: Does not expose or host tools [15] | Partial: Proxies REST APIs alongside MCP; API-to-MCP conversion not documented [24] | Yes: Connected SaaS integrations exposed as MCP tools through one endpoint | | Self-hosted or on-prem deployment | Yes: Self-hosted on your infrastructure listed on the pricing page [10] | Yes: PDP runs anywhere; Hub self-hostable since January 2026 [20] | Yes: Cloud, on-premises, hybrid or Datawiza-hosted [29] | Not offered: SaaS hosted in the EU | | EU hosting | Yes: US and EU availability stated on the vendor blog [11] | Partial: Self-host anywhere; no EU region documented for cloud Hub [20] | Partial: Self-host in any region; no EU region documented for the hosted service [24] | Yes: OVHcloud, France | | Human-in-the-loop approvals for sensitive calls | Partial: Ask-user rule pauses the call for the same end user; Slack is alert only [12] | Partial: Denials can name required approvers; no approval workflow [16] | Partial: Sensitive actions can be routed for approval; channel not documented [29] | Yes: Approval in Slack, Teams or the app UI, logged with the call | | Published pricing | Partial: Pricing page, custom per-user licensing, no figures [10] | Yes: Open source free; development from $25 per month; production from $933 per month [19] | Partial: Pricing page, subscription customised, no figures [30] | Not offered: On request | ## Choose MintMCP if - You want a dedicated gateway for coding agents and hosted MCP connectors, with signed audit records and programmable middleware. - Human access governance is handled elsewhere and SCIM group entitlements are enough. ## Choose Cerbos if - You run your own gateway and want an open-source, self-hostable policy decision point with one policy language across apps and agents. - Your team writes authorization policy as code and wants sub-millisecond decisions. ## Choose Datawiza if - You need to put SSO and policy in front of legacy and on-prem applications as well as agents, with credential brokering so agents never hold secrets. - You want inline deployment with no SDK and no agent code changes, in your own cloud or DMZ. ## Choose Lutril if - The agents and the employees who own them should be governed by one policy, one review campaign and one audit log. - Prompt DLP, a WORM log and a global kill switch must be in the base product, not integrations to assemble. - Sensitive tool calls need a human approval in Slack, Teams or the app UI, with the decision logged. - You also need to find the agents you do not know about, through sign-in logs, mailboxes, the browser and code. - Your data has to stay in the EU, or your team works in French. ## Frequently asked questions ### What is an MCP gateway? A proxy that speaks the Model Context Protocol to AI agents and sits in front of the tool servers they call. It authenticates the agent, applies policy to each tool call (which agent, which tool, which parameters), logs the call and can stop the agent. It replaces the pattern of handing an agent a raw API key that grants everything the key allows. ### What is the best MCP gateway to enforce policy on AI agent tool calls? For a standalone gateway with deep middleware and signed audit records, MintMCP. For an open-source decision point behind a gateway you already run, Cerbos. For inline enforcement across legacy apps and agents with credential brokering, Datawiza. For a gateway that is part of access governance for the whole company, with agent owners, prompt DLP, a kill switch, human approvals in Slack, Teams or the app UI, and the same reviews for agents and employees, Lutril. ### How do I control what AI agents can access through MCP? Register each agent as its own identity with an owner and a scoped role. Route its tool calls through a gateway that checks each call against policy before forwarding it. Log every call immutably. Keep a kill switch that pauses the agent everywhere. Include agents in access reviews so idle or over-scoped ones get tightened. Lutril's MCP proxy and agent registry do all five. ### Is Cerbos an MCP gateway? No, by its own account. Cerbos is an authorization decision point that a gateway such as agentgateway calls before a tool runs. It decides; the gateway routes. If you already operate a gateway and want policy as code, that split works well. If you want one product that proxies and decides, look at MintMCP, Datawiza or Lutril. ### Can a gateway expose a SaaS tool that has no MCP server? Only if the gateway itself wraps the vendor's API as MCP tools. Lutril does this for its connected SaaS integrations through one endpoint. MintMCP hosts open-source or custom MCP servers; Datawiza proxies REST APIs alongside MCP. Cerbos does not expose tools. ## Sources 1. [MintMCP homepage](https://www.mintmcp.com/) (accessed 2026-09-02) 2. [MintMCP docs, introduction](https://www.mintmcp.com/docs/intro) (accessed 2026-09-02) 3. [MintMCP docs, gateway middleware](https://www.mintmcp.com/docs/gateway-middleware) (accessed 2026-09-02) 4. [MintMCP docs, agent identities](https://www.mintmcp.com/docs/agent-identities) (accessed 2026-09-02) 5. [MintMCP docs, audit and observability](https://www.mintmcp.com/docs/security/audit-observability) (accessed 2026-09-02) 6. [MintMCP docs, operational controls](https://www.mintmcp.com/docs/operational-controls) (accessed 2026-09-02) 7. [MintMCP docs, RBAC](https://www.mintmcp.com/docs/rbac) (accessed 2026-09-02) 8. [MintMCP docs, Agent Monitor overview](https://www.mintmcp.com/docs/agent-monitor-overview) (accessed 2026-09-02) 9. [MintMCP docs, add a hosted connector](https://www.mintmcp.com/docs/add-hosted-connector) (accessed 2026-09-02) 10. [MintMCP pricing](https://www.mintmcp.com/pricing) (accessed 2026-09-02) 11. [MintMCP blog, agent gateways for healthcare organizations](https://www.mintmcp.com/blog/agent-gateways-healthcare-organizations) (accessed 2026-09-02) 12. [MintMCP docs, Agent Monitor rules](https://www.mintmcp.com/docs/agent-monitor-rules) (accessed 2026-09-02) 13. [MintMCP docs, Mint Guard](https://www.mintmcp.com/docs/mint-guard) (accessed 2026-09-02) 14. [Cerbos homepage](https://www.cerbos.dev/) (accessed 2026-09-02) 15. [Cerbos blog, what is an MCP gateway](https://www.cerbos.dev/blog/what-is-an-mcp-gateway) (accessed 2026-09-02) 16. [Cerbos blog, governing AI agents at the gateway with agentgateway](https://www.cerbos.dev/blog/governing-ai-agents-at-the-gateway-with-cerbos-and-agentgateway) (accessed 2026-09-02) 17. [Cerbos, Synapse](https://www.cerbos.dev/product-cerbos-synapse) (accessed 2026-09-02) 18. [Cerbos docs, audit log collection](https://docs.cerbos.dev/cerbos-hub/audit-log-collection.html) (accessed 2026-09-02) 19. [Cerbos pricing](https://www.cerbos.dev/pricing) (accessed 2026-09-02) 20. [Cerbos blog, Hub available on premise](https://www.cerbos.dev/blog/cerbos-hub-now-available-on-premise) (accessed 2026-09-02) 21. [Cerbos on GitHub](https://github.com/cerbos/cerbos) (accessed 2026-09-02) 22. [Cerbos, dynamic authorization for MCP servers](https://www.cerbos.dev/features-benefits-and-use-cases/dynamic-authorization-for-MCP-servers) (accessed 2026-09-02) 23. [Datawiza, MCP gateway](https://www.datawiza.com/mcp-gateway) (accessed 2026-09-02) 24. [Datawiza, Agent Gateway](https://www.datawiza.com/products/agent-gateway) (accessed 2026-09-02) 25. [Datawiza docs, Agent Gateway introduction](https://docs.datawiza.com/agent-gateway/introduction.html) (accessed 2026-09-02) 26. [Datawiza blog, Agent Gateway for secure AI agent access](https://www.datawiza.com/blog/industry/datawiza-agent-gateway-for-secure-ai-agent-access-to-enterprise-apis/) (accessed 2026-09-02) 27. [Datawiza, Access Proxy](https://www.datawiza.com/products/access-proxy) (accessed 2026-09-02) 28. [Datawiza homepage](https://www.datawiza.com/) (accessed 2026-09-02) 29. [Datawiza, AI agent security use case](https://www.datawiza.com/use-cases/ai-agent-security) (accessed 2026-09-02) 30. [Datawiza pricing](https://www.datawiza.com/pricing) (accessed 2026-09-02) Lutril wrote this page. Facts about MintMCP, Cerbos, Datawiza come from their public documentation as of 2026-09-02. Spotted an error? Write to hello@lutril.com. --- # Best access management tools for SaaS apps in 2026: Lumos, Zluri, Torii, BetterCloud, AccessOwl and Lutril > Six tools that govern who can reach which SaaS app, compared on discovery, access reviews, Slack and Teams requests, time-boxed access, HRIS lifecycle, offboarding outside SSO, AI agents, EU hosting and published pricing. Written from public documentation, dated. Source: https://www.lutril.com/compare/saas-access-management-tools Last reviewed: 2026-09-02 --- ## Short answer The best access management tool for SaaS apps is the one whose reviews execute removals, whose requests run where your people work, and whose coverage includes the apps outside SSO. For a lean team under 300 people that lives in Slack and wants a price list, AccessOwl. For SaaS management with spend and licences alongside access, Zluri or Torii, both Gartner Magic Quadrant Leaders. For a workflow-builder approach with Google Workspace administration, BetterCloud. For companies of 200 and up wanting AI-assisted reviews, Lumos. For access governance that treats AI agents as identities alongside employees, with requests in Slack, Teams and the app UI, an MCP proxy, EU hosting and a French-language product, Lutril. ## Where each one starts **Lumos.** Autonomous identity platform for companies of 200 employees and up: agentic access reviews, Slack requests with time-boxed grants, HRIS-driven lifecycle and NHI ownership. 300+ integrations, US-based. **Zluri.** SaaS management turned identity security: eight discovery sources, Slack-native requests, certifications, licence and spend optimisation. Gartner MQ Leader for SMPs, 300+ connectors, notifications in email and Slack. **Torii.** SaaS and AI management platform, Gartner MQ Leader, that added access governance, temporary access and Slack and Teams request agents through 2026. Finance-system discovery alongside the IdP. US instance. **BetterCloud.** End-to-end SaaS management with a no-code workflow engine, Google Workspace administration, spend and file governance. Founded 2011, acquired by CoreStack in 2026, US datacenters. **AccessOwl.** Slack-first access administration for IT teams of fewer than five people: onboarding, offboarding, access reviews and provisioning to 400+ apps, from $4.50 per user per month. Berlin, Y Combinator 2022. **Lutril.** Access governance for employees and AI agents: discovery from Google Workspace and Microsoft 365, requests in Slack, Teams and the app UI with automatic expiry, reviews that revoke, HRIS-driven lifecycle, and an MCP proxy with prompt DLP and a kill switch. Hosted in France, in French and English. ## Capability by capability | Capability | Lumos | Zluri | Torii | BetterCloud | AccessOwl | Lutril | | --- | --- | --- | --- | --- | --- | --- | | SaaS discovery from IdP sign-in and OAuth grants | Yes | Yes | Yes | Yes | Yes | Yes: Google Workspace and Microsoft 365 sign-in signals and OAuth grants, from the day you connect | | Access reviews whose decisions execute | Yes | Partial [4] | Yes | Partial [12] | Yes | Yes: Decisions execute in the connected tool; proof in the campaign export | | Requests and approvals in Slack | Yes | Yes | Yes | Yes | Yes | Yes: Requests, approvals and expiry warnings in Slack | | Requests and approvals in Microsoft Teams | Partial [1] | Not offered [5] | Yes | Partial [13] | Not documented | Yes: Same flow in Microsoft Teams, and in the app UI | | Time-boxed access that expires on its own | Yes | Yes | Yes | Partial [14] | Not offered [18] | Yes: One hour to seven days; an approver can shorten, never extend; auto-revoked | | Onboarding triggered by the HRIS | Yes | Yes | Yes | Yes | Yes | Yes: Lucca, PayFit and Eurécia native; other HRIS through the MCP endpoint | | Offboarding across SaaS, including apps outside SSO | Yes | Yes | Yes | Yes | Yes | Yes: Native connectors plus a universal MCP endpoint for any tool with an API | | AI agent registry with an owner | Yes | Yes | Partial [8] | Partial [15] | Not documented | Yes: Owner, model and scopes on every agent; offboarded like an employee | | MCP proxy enforcing policy on agent tool calls | Not offered [2] | Not documented | Not offered [9] | Not documented | Not documented | Yes: Lutril MCP proxy: policy on every call, WORM log, global kill switch | | EU hosting | Not documented | Partial [6] | Not offered [10] | Not offered [16] | Partial [19] | Yes: OVHcloud, France; product and documentation in French | | Published pricing | Not offered [3] | Not offered [7] | Not offered [11] | Partial [17] | Yes [20] | Not offered: On request | ## Choose Lumos if - 200+ employees, an IT team to run it, and AI-assisted reviews inside the identity platform matter to you. ## Choose Zluri if - Spend and licence optimisation weigh as much as access, and your team lives in Slack. ## Choose Torii if - You want a SaaS management Leader that also covers temporary access and Slack and Teams requests, and US hosting is fine. ## Choose BetterCloud if - You administer Google Workspace at scale and want to build your own approval and timer workflows. ## Choose AccessOwl if - Fewer than five people in IT, everything in Slack, and a published price. ## Choose Lutril if - AI agents are part of your access problem and you want them governed with the same policy, reviews and audit log as employees. - Requests must run in Slack, Teams and the app UI, time-boxed by default, with automatic revocation. - Your data has to stay in the EU, or your team works in French. - You want discovery, reviews and offboarding running in weeks without an IAM team. ## Frequently asked questions ### What are the best access management tools for SaaS apps? In 2026 the shortlist for SaaS-first companies is Lumos, Zluri, Torii, BetterCloud, AccessOwl, C1 (formerly ConductorOne) and Lutril, with Okta Identity Governance and SailPoint for enterprises already on those platforms. Pick on four questions: do review decisions execute, where do requests run, are apps outside SSO covered, and are AI agents governed. This page answers those from each vendor's public documentation. ### What is the difference between SaaS management and access governance? SaaS management starts from the application inventory and spend: licences, renewals, usage. Access governance starts from the identity: who and what can reach each tool, how that was approved, when it expires, and what is removed on departure. Zluri, Torii and BetterCloud grew from SaaS management into access; Lumos, AccessOwl and Lutril started from access. ### Which tools also govern AI agents? Lumos and Zluri register agents as non-human identities with owners. Torii and BetterCloud document inventories of agents or service accounts. Only Lutril, among the six, documents an MCP proxy that enforces policy on each agent tool call with prompt DLP and a kill switch, alongside human access governance. C1 also ships an MCP gateway, covered on its own page. ### Which tools publish pricing? AccessOwl publishes $4.50 and $6.00 per user per month with a $250 minimum. BetterCloud has a pricing page without figures except a $0 spend tier. Lumos, Zluri, Torii and Lutril price on request. ## Sources 1. [Lumos, Microsoft Teams integration](https://www.lumos.com/integrations/microsoft-teams) (accessed 2026-09-02) 2. [Lumos developers, MCP](https://developers.lumos.com/docs/mcp) (accessed 2026-09-02) 3. [Lumos pricing](https://www.lumos.com/pricing) (accessed 2026-09-02) 4. [Zluri help, closing and completing certifications](https://help.zluri.com/docs/closing-and-completing-certifications) (accessed 2026-09-02) 5. [Zluri help, notification customization](https://help.zluri.com/docs/notification-customization) (accessed 2026-09-02) 6. [Zluri security](https://www.zluri.com/security) (accessed 2026-09-02) 7. [Zluri pricing](https://www.zluri.com/pricing) (accessed 2026-09-02) 8. [Torii, non-human identities](https://www.toriihq.com/solutions/non-human-identities) (accessed 2026-09-02) 9. [Torii, introducing Model Context Protocol in Torii](https://www.toriihq.com/blog/introducing-model-context-protocol-in-torii) (accessed 2026-09-02) 10. [Torii, GDPR](https://www.toriihq.com/docs/gdpr) (accessed 2026-09-02) 11. [Torii pricing](https://www.toriihq.com/pricing) (accessed 2026-09-02) 12. [BetterCloud, SaaS application access audit guide](https://www.bettercloud.com/saas-application-access-audit-guide/) (accessed 2026-09-02) 13. [BetterCloud, anatomy of the perfect offboarding workflow](https://www.bettercloud.com/monitor/anatomy-of-the-perfect-bettercloud-offboarding-workflow/) (accessed 2026-09-02) 14. [BetterCloud, Wait for Duration](https://www.bettercloud.com/monitor/automatically-pause-your-workflows-wait-for-duration/) (accessed 2026-09-02) 15. [BetterCloud, introducing the next generation of BetterCloud](https://www.bettercloud.com/monitor/introducing-the-next-generation-of-bettercloud/) (accessed 2026-09-02) 16. [BetterCloud, security and compliance](https://www.bettercloud.com/security-and-compliance/) (accessed 2026-09-02) 17. [BetterCloud pricing](https://www.bettercloud.com/pricing/) (accessed 2026-09-02) 18. [AccessOwl docs, approval policies FAQ](https://docs.accessowl.com/guides/requests/approval-policies.md) (accessed 2026-09-02) 19. [AccessOwl privacy policy](https://www.accessowl.com/privacy-policy) (accessed 2026-09-02) 20. [AccessOwl pricing](https://www.accessowl.com/pricing) (accessed 2026-09-02) Lutril wrote this page. Facts about Lumos, Zluri, Torii, BetterCloud, AccessOwl come from their public documentation as of 2026-09-02. Spotted an error? Write to hello@lutril.com. --- # Best identity governance (IGA) tools for a fast-growing startup: Lumos, C1, Okta Identity Governance, SailPoint and Lutril > Identity governance for a company that doubles headcount every year: which tools deliver access reviews, requests, lifecycle and AI agent governance without a year of implementation. Lumos, C1 (formerly ConductorOne), Okta Identity Governance, SailPoint and Lutril compared from public documentation. Source: https://www.lutril.com/compare/iga-for-startups Last reviewed: 2026-09-02 --- ## Short answer A fast-growing startup needs IGA outcomes, not an IGA programme: reviews whose decisions execute, requests approved where people work, onboarding and offboarding driven by the HRIS, and AI agents governed before they multiply. SailPoint is the enterprise reference and assumes an IAM team and a multi-quarter rollout. Okta Identity Governance fits if you are already an Okta shop and your apps are in its integration network. Lumos targets 200 employees and up with AI-assisted reviews. C1 governs humans and agents at enterprise depth with an MCP gateway, hosted in the United States. Lutril is built for the team with no IAM specialist: discovery the day you connect Google Workspace or Microsoft 365, requests in Slack, Teams and the app UI, reviews that revoke, an MCP proxy with prompt DLP, EU hosting and a French-language product. ## Where each one starts **Lumos.** Autonomous identity platform for companies of 200 employees and up: agentic access reviews, Slack requests, HRIS lifecycle, NHI ownership. Says a small team may find it more than it needs. **C1 (formerly ConductorOne).** AI-native identity platform for Fortune 500 and hypergrowth enterprises: lifecycle, access, compliance, an MCP Gateway and 400+ connectors with an open-source SDK. Requests in Slack, Teams and CLI. US sub-processors. **Okta Identity Governance.** Access requests, certifications and lifecycle as an add-on to the Okta identity provider, with Slack and Teams approvals, EU cells and 8,000+ integrations. Priced on inquiry on top of Okta suites. **SailPoint Identity Security Cloud.** The enterprise IGA reference, public company, 53% of the Fortune 500: certifications, lifecycle, entitlements, and since 2026 an Agentic Fabric for AI agents. Implemented as a programme with partners. **Lutril.** Access governance for employees and AI agents built for teams without an IAM department: discovery from day one, requests in Slack, Teams and the app UI, reviews that revoke, HRIS lifecycle, MCP proxy with prompt DLP and a kill switch. Hosted in France, in French and English. ## Capability by capability | Capability | Lumos | C1 (formerly ConductorOne) | Okta Identity Governance | SailPoint Identity Security Cloud | Lutril | | --- | --- | --- | --- | --- | --- | | SaaS discovery from IdP sign-in and OAuth grants | Yes | Yes | Partial [6] | Partial [10] | Yes: Google Workspace and Microsoft 365 sign-in signals and OAuth grants, from the day you connect | | Access reviews whose decisions execute | Yes | Yes | Partial [7] | Yes | Yes: Decisions execute in the connected tool; proof in the campaign export | | Requests and approvals in Slack | Yes | Yes | Yes | Yes | Yes: Requests, approvals and expiry warnings in Slack | | Requests and approvals in Microsoft Teams | Partial [1] | Yes | Yes | Yes | Yes: Same flow in Microsoft Teams, and in the app UI | | Time-boxed access that expires on its own | Yes | Yes | Yes | Yes | Yes: One hour to seven days; an approver can shorten, never extend; auto-revoked | | Onboarding triggered by the HRIS | Yes | Yes | Yes | Yes | Yes: Lucca, PayFit and Eurécia native; other HRIS through the MCP endpoint | | Offboarding across SaaS, including apps outside SSO | Yes | Yes | Partial [8] | Partial [11] | Yes: Native connectors plus a universal MCP endpoint for any tool with an API | | AI agent registry with an owner | Yes | Yes | Yes | Yes | Yes: Owner, model and scopes on every agent; offboarded like an employee | | MCP proxy enforcing policy on agent tool calls | Not offered [2] | Yes | Yes | Yes | Yes: Lutril MCP proxy: policy on every call, WORM log, global kill switch | | EU hosting | Not documented | Not offered [4] | Yes | Yes | Yes: OVHcloud, France; product and documentation in French | | Published pricing | Not offered [3] | Not offered [5] | Partial [9] | Not offered [12] | Not offered: On request | ## Choose Lumos if - You are past 200 employees with an IT team, and want AI-assisted reviews inside the identity platform. ## Choose C1 (formerly ConductorOne) if - You are scaling toward enterprise, run hybrid infrastructure, and want an MCP gateway with an open connector SDK, hosted in the US. ## Choose Okta Identity Governance if - You are standardised on Okta and every app is in its integration network with SCIM. ## Choose SailPoint Identity Security Cloud if - You have thousands of identities across ERP and on-prem systems, an IAM team, and a budget for a platform programme. ## Choose Lutril if - You have no IAM specialist and need discovery, reviews and offboarding live in weeks. - Your estate is SaaS-first, including the long tail signed up outside SSO. - AI agents need an owner, policy on each MCP call, prompt DLP and a kill switch, in the same product as human governance. - Your data has to stay in the EU, or your team works in French, without enterprise pricing. ## Frequently asked questions ### What are the best identity governance tools for a fast-growing startup? Lumos, C1 (formerly ConductorOne), Okta Identity Governance, SailPoint and Lutril all deliver access reviews, requests and lifecycle. The difference is who they assume is running them. SailPoint and C1 assume an enterprise team; Okta assumes you are an Okta shop; Lumos assumes 200 employees and up; Lutril assumes a team with no IAM function that needs the outcomes now, in Slack, Teams or the app UI. ### Does a startup need IGA at all? Not the suite, but the outcomes: a list of who has access to what, reviews that remove what should not be there, and offboarding that actually revokes. SOC 2 and ISO 27001 auditors ask for those regardless of company size. Lightweight access governance gets you there without entitlement modelling or a rollout programme. ### Which IGA tools govern AI agents? All five register agents or non-human identities with owners. C1, Okta (Agent Gateway, from April 2026), SailPoint (Agentic Fabric, from August 2026) and Lutril document policy enforcement on MCP tool calls. Lutril and SailPoint document prompt-level DLP. Lutril ships it in the base product; the others sell it as separate SKUs or add-ons. ### Which ones host in the EU? Okta has cells in Ireland and Frankfurt, SailPoint has Frankfurt and London regions, Lutril is hosted at OVHcloud in France. C1 documents US sub-processors and an EEA-to-US transfer clause. Lumos documents no region. ## Sources 1. [Lumos, Microsoft Teams integration](https://www.lumos.com/integrations/microsoft-teams) (accessed 2026-09-02) 2. [Lumos developers, MCP](https://developers.lumos.com/docs/mcp) (accessed 2026-09-02) 3. [Lumos pricing](https://www.lumos.com/pricing) (accessed 2026-09-02) 4. [C1 legal, sub-processors](https://www.c1.ai/legal/subprocessors) (accessed 2026-09-02) 5. [C1 pricing](https://www.c1.ai/pricing) (accessed 2026-09-02) 6. [Okta help, identify AI agents with OAuth](https://help.okta.com/oie/en-us/content/topics/ai-agents/ai-agent-identify-with-oauth.htm) (accessed 2026-09-02) 7. [Okta help, access certification remediation](https://help.okta.com/oie/en-us/content/topics/identity-governance/access-certification/remediation.htm) (accessed 2026-09-02) 8. [Okta Lifecycle Management](https://www.okta.com/products/lifecycle-management/) (accessed 2026-09-02) 9. [Okta pricing](https://www.okta.com/pricing/) (accessed 2026-09-02) 10. [SailPoint docs, Application Visibility](https://documentation.sailpoint.com/saam/help/index.html) (accessed 2026-09-02) 11. [SailPoint docs, lifecycle management](https://documentation.sailpoint.com/saas/help/provisioning/lifecycle.html) (accessed 2026-09-02) 12. [SailPoint, Identity Security Cloud suites](https://www.sailpoint.com/products/identity-security-cloud/atlas/suites/business-plus/) (accessed 2026-09-02) 13. [Lumos, ConductorOne competitors and alternatives](https://www.lumos.com/identity-matters/identity-governance/conductorone-competitors-and-alternatives) (accessed 2026-09-02) Lutril wrote this page. Facts about Lumos, C1 (formerly ConductorOne), Okta Identity Governance, SailPoint Identity Security Cloud come from their public documentation as of 2026-09-02. Spotted an error? Write to hello@lutril.com. --- # Just-in-Time Access: Standing Privilege Is the Breach Path > Identity weaknesses played a material role in nearly 90% of the incidents Unit 42 investigated last year. Just-in-time access shrinks what a leaked credential can reach, by making every grant expire on its own. Here is what the 2026 reports actually say, why AI agents changed the math, and how Lutril's policy engine works. Source: https://www.lutril.com/blog/just-in-time-access Published: 2026-08-07 Topic: Access Control --- ## What just-in-time access actually means Most access in most companies is **standing access**. Someone needed a permission once, an admin granted it, and it stayed. Nobody scheduled its removal because removal was never part of the grant. Three years later that permission is still attached to the account, still valid, and still invisible until an auditor or an attacker finds it. Just-in-time access inverts the default. Permission is granted for a stated reason, for a bounded window, and it is reclaimed when the window closes. Palo Alto Networks describes the end state, [zero standing privileges](https://www.paloaltonetworks.com/cyberpedia/zero-standing-privileges), as "eliminating all permanent (standing) access rights for every identity, human or machine." JIT is the mechanism that gets you there: elevate for a task, for a set time, then drop back down. The idea is not new. What changed is that the cost of standing access became measurable, and the number of identities holding it stopped being a human-scale number. ## Standing access is where the breach actually happens The [2026 Verizon Data Breach Investigations Report](https://www.verizon.com/business/resources/reports/dbir/) reports a genuine shift at the front door: 31% of breaches now start with software vulnerabilities, unseating stolen credentials as the top initial access vector for the first time. It would be easy to read that as good news for identity teams. It is not. Credentials did not stop mattering. They moved. Counted across the whole breach, not just the first step, [credential abuse still appears in 39% of breaches](https://spycloud.com/blog/top-takeaways-from-the-2026-verizon-data-breach-investigations-report/), and 73% of ransomware victims had an associated infostealer infection or credential leak in the year before the attack. The exploit gets the attacker in. The standing permissions attached to whatever identity they land on decide how far they get. Unit 42 measured the same thing from the incident response side. Across [more than 750 major incidents](https://www.paloaltonetworks.com/resources/research/unit-42-incident-response-report) handled between October 2024 and September 2025, identity weaknesses played a material role in nearly 90% of investigations, and 65% of initial access was driven by identity-based techniques. - **~90%**: Unit 42 investigations where identity weakness was material - **39%**: Breaches involving credential abuse (2026 DBIR) - **73%**: Ransomware victims with a prior credential leak This is the honest case for JIT, and it is narrower than the marketing usually claims. Time-boxing access will not stop a phish and it will not patch a CVE. What it does is shrink the blast radius of every credential that eventually leaks, because most of the permissions an attacker would want to inherit no longer exist at the moment they arrive. ## The identity count stopped being human-scale There is a second reason this became urgent in 2026. The Cloud Security Alliance's [whitepaper on non-human identity and agentic AI governance](https://labs.cloudsecurityalliance.org/research/csa-whitepaper-nonhuman-identity-agentic-ai-governance-v1-cs/) puts it plainly: service accounts, API keys, OAuth tokens, machine certificates, and the credentials wielded by AI agents "now outnumber human users by an average of 45 to 1, and in cloud-native environments the ratio can reach 144 to 1." Other 2026 estimates run higher still. The spread between them is itself the finding. Nobody has a confident count, because most of these identities were created by whoever needed them, in whatever tool needed them, with no lifecycle attached. The same paper reports that **78% of organizations have no documented policy for creating or removing AI identities**, and only 8% are highly confident their existing IAM can manage AI and non-human identity risk. Manual review does not scale to that population. A quarterly campaign that works reasonably well for 400 employees does not work for 18,000 tokens, and it works even less well for an agent that was spun up on Tuesday for one workflow and never turned off. We wrote about the structural version of this problem in [The AI Governance Gap](/blog/the-ai-governance-gap) and [What Is the Access Layer for AI Agents?](/blog/ai-agent-access-layer). The short version: if access has no expiry, something has to remove it, and at this scale that something cannot be a person. ## Why JIT projects stall Almost every security team agrees with the principle. Far fewer have it running. The failures are consistent, and they are not about buy-in. **What breaks** - An expiry date is written down but nothing enforces it. The grant is "temporary" in a spreadsheet and permanent in the SaaS tool. - Every request routes to a human. Approvers get twenty a day, stop reading them, and approve on reflex. - Conditions are written against attributes nobody actually syncs, so the rule silently never matches or silently always does. - Requests live in a portal nobody opens, so people route around the system and ask an admin directly. **What has to be true** - The system that grants access is the system that removes it, on a schedule it owns. - Low-risk, well-understood requests resolve without a human, so the ones that reach an approver are worth reading. - The policy editor tells you which attributes it can actually resolve, and refuses to pretend about the rest. - Requesting and approving happen where work happens: Slack, Teams, and the app. ## How Lutril does it In Lutril, JIT is configured per application on the **Policies** page. Each policy targets one audience, either **Employees** or **AI agents**, and can be scoped to a specific access level. A policy written for a specific level wins over the app default, so "Admin on Notion" and "Member on Notion" can behave completely differently. Each audience gets three settings: what happens on request, the maximum duration, and optional conditions. | On request | What happens | Use it for | | --- | --- | --- | | Auto-approve | Granted instantly, no human in the loop, and still time-boxed. | Access the person's role already justifies, where the risk is the duration, not the decision. | | Require approval | Routes through the approval workflow, then expires. | Privileged levels, production systems, anything an auditor will ask about by name. | | Deny | Refused outright, with the reason recorded. | Access that should never be self-served, no matter who asks. | ### Duration is a ceiling, not a fixed value The maximum duration is set in hours on the policy. The requester is asked "How long do you need access?" and picks from a ladder of 1 hour, 4 hours, 8 hours, 1 day, 3 days, or 7 days, filtered down to whatever the policy allows. The same prompt renders as a dropdown in Slack, a choice set in Teams, and a select in the Lutril app. An approver can shorten a grant when they decide. They cannot lengthen one. The effective window is the smallest of the three numbers in play: **the policy maximum, what the requester asked for, and what the approver granted**. There is no path through the flow that produces access lasting longer than the policy allows. The clock starts when the decision lands, not when the request was filed. If an approver takes six hours to respond, the requester still gets their full window. ### Conditions decide who skips the queue Approval fatigue is what kills JIT programmes, so the interesting question is not "who is allowed" but "who should not need a human." The conditions editor asks exactly that, in one sentence: **Grant automatically when**. You build a rule, then answer a second question about everyone who does not match: does an approver decide and it still expires, or does an approver decide and it never expires. Attributes that resolve today include department, job title, manager, HR status, MFA state, internal versus external, IdP status, outstanding security trainings, whether the person already has access to the app, the application's sensitivity, and the request itself: duration asked for, access level, and stated reason. Any attribute that depends on a source you have not connected yet is shown as unavailable, with the reason written next to it. You never build a rule on a signal that will not arrive, and you always know which connection would unlock it. That sounds like a small thing. It is the third failure mode above, closed. **Dry run before you enforce** Next to the editor is a panel called "Who does this match?". Enter a real email and Lutril evaluates the policy against that person right now, returning whether they are in scope, whether they would be auto-approved, and a per-rule trace. Each rule comes back as passed, did not hold, could not check, or not understood. The distinction matters: "did not hold" means the rule ran and the answer was no, while "could not check" means a fact was missing, which is a data problem, not a policy problem. ### Failures resolve toward approval, never toward silence A policy engine that cannot resolve a fact has three options: allow, deny, or ask a human. Lutril always asks a human. An unmet or unverifiable condition degrades to "approval required," never to a silent grant and never to a silent refusal. A deny rule is evaluated before scope, so narrowing a policy can never accidentally loosen it. When a decision is made, the terms of the policy are frozen onto the grant. Editing the policy tomorrow does not rewrite what was authorized today, which is what makes the record usable as [audit evidence](/blog/access-reviews-soc2-iso27001) rather than a snapshot of current configuration. Every expiry Lutril sets is one it can honour. Time-boxing is wired to a real removal path, whether Lutril manages the account through the application's own provisioning or through Google Workspace and Microsoft Entra groups. The deadline is not a reminder in someone's calendar. It is the removal. ## What happens at the deadline A background job checks for expiring and expired grants every few minutes. Three things can happen. **A warning goes out first.** Lead time is proportional to the grant, roughly a quarter of the window, capped at 24 hours. A 7 day grant is flagged a day ahead. A 1 hour grant is not warned at all, because a warning on a 1 hour grant is just noise. The message arrives in Slack or Teams with buttons to extend or to let it lapse. **Extensions are bounded.** A grant can be extended up to three times, and each extension is re-resolved against the live policy rather than the frozen snapshot. If you tightened the policy since the grant was issued, the extension respects the new limit. There is no fresh approval round, because the approver already authorized "up to the policy maximum," and every extension is logged. **Removal is deprovision-first.** Access is removed at the source before the grant is marked expired. If removal fails, the grant stays live and the failure is logged for the next pass. A record that says "expired" while the permission is still attached is worse than no record. ``` 09:14:02 ACCESS_REQUEST_CREATED notion / admin requested 8h, reason: incident 4471 09:16:48 ACCESS_REQUEST_DECIDED granted approver capped at 4h, policy max 8h 12:16:48 ACCESS_GRANT_EXPIRY_WARNED slack dm expires in 1h 12:31:10 ACCESS_GRANT_EXTENDED +2h extension 1 of 3, re-read from live policy 15:20:05 ACCESS_GRANT_EXPIRED notion / admin deprovisioned, ttl_expired ``` **You choose how it lands** Removal is precise. Lutril takes back exactly what the grant added, checked against what it recorded granting, and it leaves the access alone if the person still holds the app through another route. Before enforcement changes anything, you see the full list of grants already past their deadline, so the first run holds no surprises. Teams that want a soft landing can run warnings only for a cycle, then switch removal on once the backlog is clean. ## The same engine, applied to AI agents Agent policies use the same table, the same conditions, and the same duration logic. Four things differ, and all four exist because an agent is not a person. - **The subject is the human driving the agent.** Department, HR status, and training conditions evaluate against that person, not against a service account with no attributes to evaluate. - **An agent can never exceed its owner's access.** That check runs before the policy is consulted. If the owner does not have the integration, no policy can hand it to the agent. - **Read and write are separate policies.** Scope is matched exactly, so a read policy never implies write. An agent that can search your CRM does not thereby get to modify it. - **Single-use grants exist.** Some agents get permission for exactly one call, consumed on the first successful use, with a short safety expiry behind it in case the call never comes. Enforcement happens at the tool call, through the MCP proxy the agent connects to. If you want the mechanics of that layer, we covered it in [MCP Governance](/blog/mcp-governance). The relevant point here is that time-boxing an agent is not a different product from time-boxing an employee. It is the same policy, with the subject swapped. ## What to demand of any JIT implementation Whether you build this or buy it, these are the properties that separate working JIT from an expiry column in a database. - The grantor is the revoker. If a different system, team, or ticket queue is responsible for removal, removal will not happen reliably. - Duration is a ceiling that no role can raise. Ask specifically whether an approver can grant longer than the policy. The answer should be no. - Unknown facts route to a human. A policy engine that fails to an allow is a liability. One that fails to a deny will be switched off within a week. - You can dry-run a policy against a real person before it decides anything, and see why each rule passed or failed. - The terms are frozen onto the grant. Editing a policy must not rewrite the history of what was authorized under the old one. - Coverage is honest. If the tool cannot revoke an app, it should say so rather than offer an expiry it cannot enforce. JIT will not fix your offboarding on its own, and it does not replace [access reviews](/blog/access-reviews-soc2-iso27001) or a real [departure process](/blog/employee-offboarding-security). What it does is change the default. Access that nobody renewed stops existing, without anyone remembering to remove it. At 45 non-human identities per employee and climbing, that is the only version of least privilege that survives contact with the actual number of identities you have. --- # OAuth Finds the SaaS Employees Sign Into. Our Chrome Extension Finds the Rest. > OAuth discovery surfaces every app an employee authorized through Sign in with Google or Microsoft, with exact scopes and who granted them. It cannot see the tools people sign up for with a work email and a password. Today we are shipping a browser extension to close that gap, privacy first. Source: https://www.lutril.com/blog/chrome-extension-shadow-it Published: 2026-06-22 Topic: Shadow IT --- ## Why OAuth discovery is the right foundation Lutril already discovers SaaS by reading OAuth grants from Google Workspace and Microsoft Entra ID. Every time an employee clicks "Sign in with Google" or "Sign in with Microsoft" to start using a new tool, the identity provider records a grant: which application was authorized, which scopes it was given, which user authorized it, and when. We read those grants through admin consent and turn them into a live inventory. This is a strong baseline, and we want to be clear about why. It needs no endpoint agent. It is admin-consented, so it works across the whole organization from one connection rather than waiting for software to land on every laptop. And it is precise about the thing that matters most for risk: the scopes. For each discovered app, you see exactly what it can read or write (calendar, mail, files, full Drive access), who granted that access, when it was first seen, and who the first authorizer was. That is the difference between knowing an app exists and knowing what it can actually do with your data. - **0**: endpoint agents required - **1**: admin connection, org-wide - **Scopes**: exact data access per app For most teams, connecting Google and Microsoft surfaces more apps in the first hour than the last year of asking around did. It is low friction, it is accurate, and it should be the first thing you turn on. ## The structural blind spot OAuth discovery has a boundary, and it is important to name it precisely. It is not a flaw in the approach. It is a coverage limit that follows directly from how the data is generated. An OAuth grant only exists when an employee authorizes an app through your identity provider. If a tool offers "Sign in with Google," the grant is created and we see it. But a large share of SaaS does not get adopted that way. An employee finds a tool, signs up with their **work email and a password**, and starts using it. No OAuth handshake happens. No grant is ever recorded. The app is, by construction, invisible to grant-based discovery. **Why this matters for Shadow IT specifically** The email-and-password path is exactly how the quiet experiments start: the tool someone tries for a week, the free tier a team adopts before anyone files a ticket, the niche utility that never appears on a procurement list. As we covered in Your IT Team Knows About 40 SaaS Apps. You Have 130., that long tail is the bulk of real Shadow IT. OAuth sees the apps employees signed into. It cannot see the ones they signed up for. You can close part of this gap with network logs or a proxy, but those approaches are heavy: they require infrastructure changes, they often miss devices off the corporate network, and they tend to drown teams in raw traffic that has nothing to do with SaaS. We wanted something lighter, more accurate, and built specifically to report known SaaS usage and nothing else. ## The launch: a Lutril browser extension Today we are launching a Lutril browser extension, Chrome first, with Firefox next. It closes the email-and-password gap by reporting the **known-SaaS domains** an employee visits. If someone uses a tool in the browser, the extension can tell you the tool is in use, even when no OAuth grant was ever created. Because a browser extension is the most sensitive thing you can deploy to an employee's machine, we will lead with privacy, since that is the first and most reasonable objection. The design choices below are not add-ons. They are the point. ### It is force-installed, and employees do nothing The extension is pushed to managed browsers through your MDM, the Google Workspace Admin console or Microsoft Intune. There is no install step for the employee, no login, no popup, no account to create. Admins generate one enrollment token and push it through managed configuration. From the employee's side, nothing changes about how they browse. That zero-friction deployment is what makes org-wide coverage realistic rather than a rollout project that stalls at 30 percent. ## What it sends, and what it never sees The single most important property of the extension is what it does not transmit. The filtering happens on the device, before anything leaves it. **Never leaves the machine** - General browsing: banking, personal, intranet, news - Full URLs, paths, and query strings - Page content: nothing is read or scraped - Any domain not on the curated SaaS catalog **Reported to Lutril** - A hostname, only if it is on the SaaS catalog - Hostname only: never the path or query string - Which user (or anonymized, if you choose) - Top-level navigations, not page activity To be concrete about each line: - **On-device filtering.** The extension carries a curated catalog of known SaaS domains. It transmits a hostname only if that domain is on the catalog. A visit to your bank, your webmail, an internal wiki, or a news site matches nothing and never leaves the machine. There is no general browsing log, on your servers or ours. - **Hostnames only.** When a known SaaS domain does match, the extension reports the hostname, for example `notion.so`, and nothing more. No full URL, no path, no query string, no page content. The signal is "this person uses Notion," not "this is the page they were on." - **Minimal permissions.** The extension watches top-level navigations to know which site loaded. It does not request permission to read page content, and it does no scraping. The permission surface is deliberately small so a security reviewer can reason about it quickly. - **Per-device enrollment tokens.** Each install enrolls with a per-device token that can be revoked individually, so you can cut off a single device without touching the rest of the fleet. - **Optional anonymized mode.** If you operate in a works-council or GDPR context where per-user attribution is sensitive, you can run the extension in an anonymized mode that reports app usage at the organization level without attributing it to individuals. You still see which tools are in use, without naming who used them. ## One inventory, two lenses Apps the extension discovers do not land in a separate report. They flow into the **same Shadow IT inventory** as your OAuth-discovered apps, tagged with a "Browser Extension" source. Lutril then correlates the two signals by vendor, which is where the picture gets useful. - An app seen by **both** SSO and the extension shows both sources. This is your high-confidence, actively-used inventory: authorized through your IdP and observed in real use. - An app seen by **OAuth only** was authorized through SSO. You have the scopes and the authorizer, which is the right view for scope and access risk. - An app seen by the **extension only** is the email-and-password Shadow IT that grant-based discovery could never surface. This is the category that was previously invisible. Per-user attribution shows who used what, so a finding is actionable rather than just a count. Here is a sample of how the two sources resolve in one inventory: - Notion 21 SSO grant + observed use Both - Figma 34 Sign in with Google OAuth - Linear 9 Email + password signup Extension - Typeform 6 Email + password signup Extension - Calendly 18 SSO grant + observed use Both The "Extension" rows are the ones that matter for this launch. Linear and Typeform were adopted with a work email and a password. No OAuth grant exists for either, so neither would have appeared in a grant-based inventory at all. The extension is what makes them visible, and per-user attribution tells you exactly which nine people are in that Linear workspace. ## Deployment in practice The whole rollout is an admin task. Employees are never asked to do anything. A short version: 1. **Connect Google and Microsoft.** This turns on the OAuth baseline and gives you the SSO-authorized inventory with scopes immediately. 2. **Generate the extension enrollment token.** In Settings, create the enrollment token Lutril uses to associate installs with your workspace. 3. **Push the extension through your MDM.** Force-install it via Google Workspace Admin or Microsoft Intune, and attach the managed configuration: the enrollment token, your workspace slug, and the user email (substituted per device by the MDM so each install reports the right person). 4. **Watch the inventory fill in.** Discovered domains roll up into the same Shadow IT inventory automatically, tagged by source and correlated against your OAuth grants. **The managed configuration, briefly** Three values get pushed with the extension: the enrollment token (per device, revocable), the workspace slug (which Lutril workspace to report to), and the user email (filled in by the MDM's own substitution variable, so you set it once for the whole fleet). After that, the extension enrolls itself on first launch with no employee interaction. ## When to use which These are not competing approaches. They cover different surfaces, and the value is in running both. The short version of where each one earns its place: | Approach | What it is best at | What it cannot see | | --- | --- | --- | | OAuth discovery | Sanctioned and SSO apps, with exact scopes, authorizer, and first-seen date | Anything reached with a work email and a password | | Browser extension | The long tail of email-and-password signups, plus a real in-use signal | Scopes and granted permissions (no OAuth grant exists to read) | | Both together | Full coverage: what was authorized, what is actually used, and who is using it | The genuinely offline tools that never touch a managed browser | OAuth tells you what an app is allowed to do with your data. The extension tells you the app is in use at all. Neither replaces the other. Run the OAuth baseline for scope risk, add the extension for the email-and-password long tail and the usage signal, and the Shadow IT inventory stops being an estimate and starts being a record. If you have already connected Google and Microsoft, generating the extension token and pushing it through your MDM is a short afternoon, and it surfaces a category of Shadow IT you have never been able to see before. If you have not connected an identity provider yet, start there: it is the baseline everything else builds on. --- # MCP Governance: How to Control What AI Agents Can Do in Your SaaS > AI agents now call your SaaS tools through the Model Context Protocol. MCP governance is how you decide what they're allowed to do, prove what they did, and shut them off in seconds. Here's the model. Source: https://www.lutril.com/blog/mcp-governance Published: 2026-06-18 Topic: AI Governance --- ## Short answer You control what AI agents can access through MCP by putting a gateway between the agent and the tool servers. The agent authenticates as its own identity, the gateway checks every tool call against a policy (which agent, which tool, which parameters), logs the call immutably and can pause the agent instantly. A raw API key cannot do any of that. The Lutril MCP proxy is that gateway: one MCP endpoint for every connected SaaS tool, role-based policy on each call, a WORM audit log and a global kill switch. ## What is MCP governance? **MCP governance is the practice of controlling, authorizing, and auditing what AI agents are allowed to do when they call your tools through the Model Context Protocol (MCP).** In practice it means giving every agent a registered identity, scoping its access to specific tools, checking each tool call against a policy before it reaches your SaaS, logging the call, and being able to revoke that access instantly. It's the same discipline you already apply to employees, applied to the software now acting alongside them. Humans get SSO, roles, audit logs, and offboarding. Agents, until recently, got an API key pasted into a config file and nothing else. MCP governance closes that gap. ## Why MCP changes the access problem The Model Context Protocol, released by Anthropic in late 2024, has become the standard way AI agents connect to external tools. Instead of every agent shipping a bespoke integration for every SaaS app, agents call tools through MCP servers: standardized middleware that brokers the connection. Claude, and a growing list of other clients, speak it natively. That standardization cuts both ways. It makes agents dramatically more capable, because one protocol unlocks every connected tool. And it concentrates risk, because a single agent with the wrong access can now read, write, and act across your entire SaaS estate through one channel. The same property that makes MCP useful, a single connective layer, is exactly what makes it the right place to put controls. ## Why API keys aren't governance The default way an agent gets access today is simple: someone generates an API key, pastes it into the agent's configuration, and the agent starts calling APIs. That key is a raw credential. It usually inherits the full access of whoever created it, it rarely expires, and nothing records what the agent actually did with it. **Raw API key** - No identity: calls show up as an anonymous token - Inherits whatever the creator could do; no least privilege - No per-call policy: every tool is fair game - Never expires; survives the creator's offboarding - No audit trail of prompts, parameters, or outcomes **Governed MCP access** - Registered agent identity, owned by a named person - Scoped to specific tools via explicit bindings - Every call evaluated against policy before it runs - Time-boxed access; auto-flagged when the owner leaves - Immutable, exportable log of every tool call The point isn't that API keys are bad, it's that a credential is not a control. Governance is what you wrap around the credential so it can be reasoned about, reviewed, and revoked. For the full picture of why traditional identity tooling misses agents entirely, see [The AI Governance Gap](/blog/the-ai-governance-gap). ## Governance vs. authorization These two terms get used interchangeably, and they shouldn't be. **MCP authorization** The per-call decision: is this agent allowed to invoke this tool with these parameters, right now? It's a yes/no gate evaluated on every request. **MCP governance** The program around that gate: registering agents as identities, assigning roles and scopes, logging every call, reviewing access on a schedule, and revoking it on offboarding. Authorization is one control inside governance, the enforcement moment, but governance is what makes that moment auditable and reversible. You can have authorization without governance, a gateway that allows or blocks calls but keeps no durable record and never gets reviewed. That passes a demo and fails an audit. Governance is what an auditor, a regulator, or your future self actually needs. ## The MCP gateway pattern The cleanest way to govern agents is to stop letting them hold credentials at all. Instead, put a server between your agents and your SaaS tools. Agents call tools through it; it holds the credentials, makes the decisions, and keeps the record. This is the **MCP gateway** (sometimes called an MCP proxy), and it's the equivalent of what an API gateway does for services or a reverse proxy does for web traffic. A governing MCP gateway does five things on every request: - Authenticates the calling agent and maps it to a registered identity and role - Evaluates the tool call against policy **before** forwarding it to the target SaaS - Forwards allowed calls, using credentials the agent never sees - Blocks calls that violate policy, and can open an access request for review - Writes an immutable log entry: which agent, which tool, what parameters, what outcome What that enforcement looks like in practice: ``` 2026-06-18 09:14:03 agt_7fRxP2 ALLOW slack.list_channels (24 channels, 41 ms · binding: slack:read) 2026-06-18 09:14:38 agt_7fRxP2 ALLOW hubspot.read_deals (25 rows, 88 ms · policy: ai.sales.read) 2026-06-18 09:15:02 agt_7fRxP2 DENY hubspot.export_contacts (no binding · bulk export outside scope) 2026-06-18 09:15:19 agt_3kQmost DENY notion.delete_page (agent suspended · kill switch active) ``` The two DENY lines are the whole point. Logging what happened is table stakes; governance is about stopping the wrong thing from happening in the first place, and being able to prove you did. For a hands-on walkthrough of wiring an agent through a gateway with scoped access, see [how to connect Claude to Slack via MCP with access controls](/blog/connect-claude-slack-mcp-lutril). ## The five controls of MCP governance Whatever tool you use, a complete MCP governance model rests on five controls. If any one is missing, you have a gap an auditor (or an incident) will find. ### 1. Identity Every agent is registered as a first-class identity: a name, an owner, a stated purpose, and an expiry. Not a service account, not an anonymous key. When a tool call happens, you know which agent did it and who is accountable for it. ### 2. Least-privilege scope An agent gets explicit bindings to the specific tools it needs, and nothing more. A summarizer that reads Slack and posts to one channel does not get write access to your CRM. Scopes are narrow by default; broadening them is a deliberate, logged action. ### 3. Policy-based authorization Each tool call is checked against policy in real time. Read versus write, rate limits, parameter constraints, and PII rules are evaluated before the call reaches the SaaS. Anything outside policy is blocked, not logged-after-the-fact. ### 4. Immutable audit trail Every call, allowed or denied, is written to a tamper-evident log with full context: agent, tool, parameters, response, and the policy that applied. That log is exportable as evidence for SOC 2, ISO 27001, and the EU AI Act's logging requirements. ### 5. Revocation and review You can suspend an agent globally in one action, a kill switch that stops access across every tool at once, without hunting down credentials. Access is time-boxed (expiry forces a periodic decision to renew), reviewed on a schedule, and flagged automatically when the agent's owner is offboarded. An agent whose creator has left should never keep running silently; see [when the employee leaves but the agent stays](/blog/ai-agent-offboarding). ## Shadow MCP: the part nobody watches There's a governance problem that sits one level up from policy: the agents and MCP servers you don't know about. A developer spins up an MCP connector to a SaaS tool for a side project. A team wires an internal agent to your data warehouse. None of it goes through security review. This is **shadow MCP**, the AI-native cousin of shadow IT, and it holds live credentials to production systems while being invisible to the people responsible for them. You cannot govern what you cannot see. Discovery, finding ungoverned MCP servers and agent connectors and pulling them under the controls above, is the precondition for everything else. It's the same muscle as [shadow AI discovery](/blog/shadow-ai-risks), pointed at a new surface. Most access-governance tools assume agents arrive already registered; the harder and more valuable step is surfacing the ones that didn't. ## An MCP governance checklist A practical starting point. If you can answer yes to each, you have governance, not just connectivity: - Is every agent registered with a named owner, purpose, and expiry date? - Does each agent have explicit, least-privilege bindings instead of a broad key? - Is every tool call authorized against policy *before* it reaches the SaaS? - Do agents call tools through a gateway, rather than holding raw credentials? - Is there an immutable, exportable log of every call with full context? - Can you suspend any agent across all tools in one action? - Are agent access rights reviewed on a schedule and revoked on owner offboarding? - Do you actively discover ungoverned (shadow) MCP servers and agents? The frameworks here aren't new, we spent two decades getting them right for humans. What's new is the urgency of applying them to agents before deployments grow past the point where you can retrofit controls. The control point already exists: it's the MCP layer. The question is what you enforce there. ## Frequently asked questions ### What is MCP governance? MCP governance is the practice of controlling, authorizing, and auditing what AI agents can do when they call tools through the Model Context Protocol. It gives each agent a registered identity, scopes its access to specific tools, evaluates every tool call against a policy before it reaches your SaaS, logs the call, and lets you revoke access instantly. ### What is the difference between MCP authorization and MCP governance? MCP authorization is the per-call decision of whether a specific agent may invoke a specific tool. MCP governance is the broader program around it: registering agents as identities, assigning roles and scopes, logging every call, reviewing access periodically, and revoking it on offboarding. Authorization is one control inside governance. ### Why aren't API keys enough to govern AI agents? An API key is a raw credential with no identity, no per-call policy, no expiry by default, and no audit trail of what the agent actually did. It typically inherits the full access of whoever created it, survives that person's offboarding, and can't be revoked without finding and rotating the key everywhere it was pasted. ### What is an MCP gateway? An MCP gateway is a server that sits between your AI agents and your SaaS tools. Agents call tools through the gateway instead of holding credentials directly. It authenticates the agent, checks each tool call against policy, forwards allowed calls, blocks the rest, and writes an immutable audit log. It's the natural enforcement point for MCP governance. ### What is shadow MCP? Shadow MCP refers to MCP servers and AI-agent connectors deployed without security review or central governance, often by individual developers or teams. Like shadow IT, they hold live credentials to production SaaS and stay invisible to the security team until they're discovered and brought under governance. --- # Shadow AI: 80% of Your Employees Use It. You Approved 23%. > Shadow AI is shadow IT that reads your data and acts on your systems. Employees adopt AI tools faster than security can review them, and the newest ones do not just answer questions, they take actions. Here is why it spreads, what it actually costs, and how to govern it instead of pretending a ban will hold. Source: https://www.lutril.com/blog/shadow-ai-risks Published: 2026-06-16 Topic: Shadow AI --- ## What shadow AI actually is Shadow AI is the use of AI tools inside your organization that your security and IT teams never approved, never configured, and cannot see. It is the same shape as [shadow IT](/blog/shadow-it-risks), the SaaS tools employees adopt on their own, but with two differences that make it sharper: the tools ingest your data to function, and the newest of them do not just read, they act. It does not look like a violation from the inside. It looks like a sales rep pasting an account's contract into a free chatbot to summarize it. A support engineer connecting an AI assistant to the company knowledge base to answer tickets faster. A finance analyst uploading a quarterly export so a model can find anomalies. Each decision is individually reasonable. The aggregate is a large, unmanaged surface where corporate data flows into systems you have no contract with and no log of. - **80%**: of employees use unapproved AI tools - **23%**: use only AI their org governs - **37%**: have any policy to detect it The gap between the first two numbers is the entire problem. Most of the AI in your organization is running outside whatever governance you think you have. And barely a third of companies have a policy that would even surface it, let alone control it. ## Why it spreads faster than shadow IT Shadow IT took years to accumulate because each tool still required a sign-up, a workspace, a bit of setup. Shadow AI skips most of that. There is no install, no workspace to provision, often no account beyond a personal login. An employee opens a browser tab, pastes in their work, and gets value in seconds. Three dynamics make it move faster than any wave of SaaS adoption before it: - **The productivity gap is real and immediate.** The approved toolset almost always lags what an employee can reach on their own. When the sanctioned option is slower or absent, people route around it. Shadow AI thrives precisely where governance is missing and official tools trail what is freely available. - **Personal accounts bypass every control.** A large share of generative-AI use happens through unmanaged personal accounts, which means it never touches your SSO, your DLP, or your audit logs. The activity is invisible by construction, not by accident. - **The tools recruit each other.** One person finds a workflow that works, shares it with the team, and adoption compounds. By the time anyone in security hears about it, there is real business data inside and a workflow people now depend on. You cannot policy your way out of this with a memo. The friction of following an approval process still exceeds the friction of opening a tab, and as long as that is true, the behavior continues. ## The real risks Shadow AI is usually framed as a data-leakage problem, and it is one. But the cost shows up across three distinct surfaces, and the financial impact is now measurable. - **+$670K**: added breach cost when shadow AI is involved - **20%**: of breaches involved shadow AI - **47%**: of AI use via unmanaged personal accounts **Data you cannot account for** When an employee pastes customer records into a free-tier AI tool, that data leaves your environment and lands in a third-party system you have no contract with, no DPA for, and no way to retrieve. GDPR Article 28 requires a data processing agreement with every processor handling personal data. Shadow AI creates processors you never knew existed, and "we did not know our staff used it" is not a defense a regulator accepts. **Decisions you cannot explain** When an ungoverned model drafts a hiring screen, a credit decision, or customer-facing output, you inherit responsibility for a process you cannot reconstruct. The EU AI Act expects human oversight and logging for consequential automated decisions. A tool nobody registered produces no logs and supports no oversight, so you cannot show how a decision was reached. **Audit evidence you cannot produce** SOC 2 and ISO 27001 ask you to demonstrate that access to systems holding sensitive data is controlled. Shadow AI tools are systems holding sensitive data with zero access controls. An auditor sampling real usage will find AI services that appear on no inventory and no access review. ## When shadow AI gets write access So far this describes shadow AI as a chat box: data goes in, an answer comes out, the damage is exposure. That was the 2024 version. The current version is worse, because the tools no longer just read. AI agents connect to your systems and take actions inside them. Through connectors and the Model Context Protocol (MCP), an agent can read a CRM, post to Slack, open pull requests, move money, or update records, on its own, in a loop. When an employee wires one of these up without review, you do not have a shadow tool that has seen some data. You have a shadow actor with standing write access to production systems, and no owner, no scoped permissions, and no audit trail. This is the part most "shadow AI" coverage misses. The reporting treats it as a data-privacy story, but the agentic version is an access-control story. Surveys already find a majority of organizations granting AI systems more access than the human doing the equivalent job. An agent that outlives the project it was built for is the AI equivalent of an [employee who left but kept their keys](/blog/ai-agent-offboarding), except it runs continuously and nobody remembers it exists. **Why your IdP does not see it** Okta and Azure AD govern human logins. An agent connecting to a SaaS tool over an API token or an OAuth grant is not a human login, so it does not appear in your identity provider's view of who has access. That is the structural reason agentic shadow AI is invisible to the stack you already trust, and why governing it needs a layer built for non-human callers. We walk through that layer in The AI Governance Gap and What Is the Access Layer for AI Agents. ## What a shadow AI discovery scan shows You cannot govern what you cannot see, so the first move is discovery. Signals already exist in systems you control: OAuth grants in Google Workspace and Microsoft 365, sign-in events, and connected-app records all reveal which AI services your people have wired in. Most teams are surprised by their first scan, not because the tools are exotic, but because of the volume and what the tools can touch. - ChatGPT (personal) 52 Pasted docs, customer data High - Claude + CRM connector 6 Read/write to HubSpot High - Cursor / AI code agent 18 Repo + GitHub write High - Otter / meeting notetaker 34 Calendar, call transcripts Medium - Gamma / AI deck builder 11 Drive, internal content Medium The two agentic rows are the ones that should stop you. A CRM connector with write access and a code agent that can push to GitHub are not exposure risks, they are action risks. Six people wired an AI into your customer system and granted it the ability to change records, and until the scan ran, that was true and invisible at the same time. ## Govern, don't block The reflex after a shadow AI scan is to ban it: block the domains, kill the OAuth grants, send the memo. It does not work, for the same reason it never worked with shadow IT. People route around the ban, and you lose the visibility you just gained because usage moves to personal devices and accounts you cannot see at all. The data backs this up from the other direction: organizations that gave employees a governed AI alternative cut unauthorized AI use by roughly 89%. People are not attached to the shadow tool. They are attached to the capability. Give them a sanctioned path to that capability and most of the shadow usage evaporates on its own. A workable approach sorts tools by risk and intent rather than reaching for a blanket ban: | Category | Approach | Why | | --- | --- | --- | | Agent with write access to a core system | Route through a governed access layer | Scoped permissions, an owner, and an audit log turn a shadow actor into a managed one | | High-risk chatbot, clear business case | Fast-track to a sanctioned enterprise tier | People will use it either way; better with a DPA, SSO, and data controls | | High-risk, no business case | Block and explain why | Reduce surface area where no legitimate need exists | | Medium-risk, widespread use | Adopt and govern | Blocking a tool half the company relies on creates more friction than risk | The goal is not zero shadow AI, which is unreachable without also killing the productivity people adopted it for. The goal is **known AI**: a continuous, current picture of which AI tools and agents exist, who uses them, what data and systems they can reach, and the ability to scope or cut off any of them. For chatbots that means a sanctioned tier with real data controls. For agents it means an access layer that checks every call against policy, ties each agent to a named owner, logs what it does, and offers a kill switch, so an AI acting on your systems is governed exactly like a human with the same reach. --- # The AI Governance Gap > Your security stack controls who can access your SaaS tools. It has no idea your AI agents even exist. Source: https://www.lutril.com/blog/the-ai-governance-gap Published: 2026-06-03 Topic: AI Governance --- ## The assumption that broke Modern identity infrastructure is genuinely impressive. SAML, OIDC, SCIM, MFA, JIT provisioning. Enterprise IT has spent two decades building a system that knows who every employee is, what they should access, and when to cut them off. That system has one core assumption: access requests come from people. An employee authenticates via SSO. Your IdP issues a token scoped to their groups and roles. When they leave, SCIM deprovisions them automatically. When their role changes, group memberships update. The whole system is predicated on identity. Because it is, it works. That assumption quietly broke over the last two years. And most organizations haven't caught up yet. ## How agents get access today AI agents like Claude, ChatGPT, Copilot, and Gemini are now doing real work inside real organizations. Not just answering questions, but reading pipelines, writing emails, querying databases, and taking actions that have consequences. To do that work, they need access to your SaaS tools. And the way they get that access today is simple: **someone generates an API key, pastes it into the agent's configuration, and the agent starts calling APIs.** That's it. No SSO. No group membership. No session token tied to an identity. A raw credential that grants access to whatever that key's scope allows, typically whatever the developer who generated it was allowed to do. - **50+** - **41%** - **0** ## Three gaps that current tooling doesn't close **Gap 1: No identity** When Claude reads 500 CRM deals, who did that? Not the developer who generated the key. They might have done nothing that day. The action shows up in your SaaS logs as a raw API call from a token. That token has no name, no role, no owner in your IdP. When the developer leaves, you might disable their SSO account, but the API key they generated is still active, still calling APIs. **Gap 2: No scope enforcement** An HubSpot API key generated by a Sales Director typically grants the same access as that director. Not just read_deals, but write_deals, delete_contacts, export_all. There is no "least privilege" applied to agents by default. In practice, agents run overpermissioned, not by design but because tight scopes are friction and business value is the priority. **Gap 3: No audit trail** What did your AI agent do last Tuesday? Unless someone built a separate instrumentation layer, you don't know with any precision. You have access logs in your SaaS tools, but those logs tell you that a token was used: not what prompt triggered the call, not what the agent was trying to accomplish, and not whether the call was authorized by any policy. Compare this to how a human analyst does the same work: **Human analyst** - Authenticated via SSO, identity verified - Role-based: "sales-analyst" can read, not write - Session expires, access tied to employment - Deprovision in seconds when they leave - Every access logged with full context **AI agent today** - API key. No SSO, not in your IdP. - Inherits whatever the key allows - Key never expires unless manually rotated - Survives offboarding unless key is found - Token used. No prompt, no reason, no policy. ## The regulatory angle is closer than it looks The EU AI Act came into full effect in 2025. Its requirements for high-risk AI systems include human oversight measures (Article 14) and automatic logging of events (Article 12). The scope of what counts as "high-risk" is broader than most legal teams expect, and enforcement is ramping up. Meanwhile, SOC2 auditors are starting to ask pointed questions about AI governance. The typical answer is a vague policy document plus good intentions. It is increasingly insufficient. Type II reports are supposed to demonstrate operating effectiveness over time. **You can't demonstrate that for controls that don't exist.** GDPR's data minimization principle (Article 5) is also relevant. If your agent reads 10,000 customer records to answer a question about one deal, that's a data minimization problem. Current agent architectures make it easy to accidentally over-retrieve, with no mechanism to constrain access at the level of individual tool calls. ## What governance for agents actually looks like The good news: we know how to solve this in principle, because we've already solved it for humans. The right mental model is simple. **Agents should be first-class identities in your access control system.** Not service accounts. Not API keys. Identities with: - A **registered agent ID** tied to a definition: what is this agent, who built it, what is it supposed to do - A **role** using the same RBAC framework you already use for people: "sales-analyst" reads deals but can't write; "hr-ops" accesses employee data; "finance-viewer" is read-only everywhere - A **policy set** governing which tool calls are allowed, with what parameters, at what rate - An **immutable audit log** capturing every tool call with full context: agent ID, tool called, parameters, response, and outcome - A **kill switch** that suspends an agent globally, across every tool it touches, in seconds, without revoking underlying credentials What that audit log looks like in practice: ``` 2026-06-03 14:02:11 clde_7fRxP2 ALLOW hubspot.read_deals (25 rows, 41 ms · policy: ai.sales.read) 2026-06-03 14:02:41 clde_7fRxP2 DENY hubspot.export_contacts (PII policy violation · bulk export not in role) 2026-06-03 14:03:15 clde_7fRxP2 ALLOW notion.read_page (doc: "Q2 Pipeline Review", 1.2 kB) 2026-06-03 14:05:02 clde_9mWkQ1 DENY salesforce.delete_record (write ops disabled for agent role · kill switch active) ``` The DENY on line 2 is the part that matters most. Governance isn't just about logging what happened. It's about preventing the wrong things from happening in the first place. ## The MCP opportunity The Model Context Protocol (MCP), released by Anthropic in late 2024, is becoming the standard way AI agents connect to external tools. Instead of each agent needing bespoke integrations with every SaaS tool, agents call tools through MCP servers, standardized middleware that brokers the connection. This creates a natural control point. An MCP server sitting between your agents and your SaaS tools can: - Authenticate the calling agent and map it to a registered identity and role - Evaluate each tool call against a policy before forwarding it to the target SaaS - Log every call with full context: what was asked, what was returned, what policy applied - Block calls that violate policy without the agent needing to know why - Provide a global kill switch that suspends an agent across all tools simultaneously It's the equivalent of what a reverse proxy does for web traffic, or what an API gateway does for services. There's a natural enforcement layer. The question is what policies you enforce there. ## The window is now Most organizations are still in the "we'll figure out governance later" phase with AI agents. That's understandable. The use cases are compelling, the tooling is new, and the security implications feel abstract until they're not. The organizations that build governance infrastructure now, while agent deployments are still manageable, will be in a very different position from those who retrofit controls onto a system that's grown too large to audit. Access control for humans took decades to get right. The window to get it right for agents, before the mess becomes irreversible, is narrowing. The frameworks already exist. The control point already exists. What's needed is the will to enforce it before something goes wrong. --- # What Is the Access Layer for AI Agents? > AI agents need identity, policy enforcement, audit logs, and a kill switch before they touch your SaaS stack. That infrastructure has a name. Here is what it is and how it works. Source: https://www.lutril.com/blog/ai-agent-access-layer Published: 2026-06-03 Topic: AI Governance --- ## The concept: what an access layer is An **access layer for AI agents** is the control plane between an agent and the SaaS tools it can reach. It sits in the path of every tool call an agent makes and enforces four things: who the agent is, what it is allowed to do, what it actually did, and whether it should keep running. Two analogies make the role concrete. An API gateway sits between microservices and enforces authentication, rate limiting, and routing before any upstream call completes. An IAM system sits between humans and enterprise resources and enforces identity, policy, and access control before any login or API call goes through. The access layer for AI agents is both of those things, built for non-human actors that operate through tool APIs at machine speed. The four components that define the category: Identity Each agent has a stable, unique ID tied to its definition. Not a shared API key. Not a human credential. A persistent identity that persists across runs and can be revoked independently. Policy Rules that define which tools an agent can call, which parameters it can pass, and how often. A deal-closing agent can read HubSpot contacts. It cannot delete them. That boundary is enforced, not assumed. Audit An immutable record of every tool call: which agent, which tool, which parameters, what the response was, and when. Written once. Cannot be edited retroactively. Available for security review and compliance evidence. Control The ability to stop an agent immediately, pause a specific capability, or reassign access without touching the underlying SaaS credentials. A single revocation point that works regardless of how many tools an agent was connected to. ## Why this infrastructure didn't exist before AI agents operating through tool APIs at production scale is a 2024 phenomenon. Before that, automations connected to SaaS tools were narrow, deterministic scripts: a Zapier workflow, a webhook handler, a scheduled job. Those scripts were written by humans, reviewed by humans, and ran predictable paths. They needed credentials, not governance. Existing IAM systems were built for humans. Okta, Azure AD, and their peers manage identities that map to employees. They handle login, session management, MFA, and lifecycle events like onboarding and offboarding. They are not designed for an entity that has no login screen, creates no session cookie, and may call 400 tools in a single task run. When teams began deploying LLM-based agents with access to real tools in 2023 and 2024, the standard approach was to provision a service account, put an API key in an environment variable, and move on. That works for a prototype. For production agents with access to customer data, financial systems, or communication channels, it creates ungoverned access with no audit trail and no kill switch. The access layer category exists because that gap became too large to ignore. Security teams asked how to audit agent actions. Compliance teams asked how to scope agent permissions. Engineering teams asked how to revoke access without breaking deployments. The answer required infrastructure that did not exist yet. ## The four components of an access layer Each component addresses a specific failure mode that unmanaged agent access creates. **Identity** solves the attribution problem. When an agent modifies a record in Salesforce, who did that? With shared service account credentials, the answer is "the service account," which could be any of a dozen agents or automated scripts. With agent identity, the answer is a specific agent version, running a specific task, initiated by a specific user or system. Attribution makes revocation targeted rather than nuclear. **Policy** solves the over-permissioning problem. API keys are binary: the bearer can do everything the key allows, or nothing. Policy enforcement adds granularity. An agent can be permitted to read CRM data but not write it, to send Slack messages in a specific channel but not create new channels, to query a database but not execute destructive statements. The policy layer translates broad API access into narrow, task-appropriate permissions. **Audit** solves the visibility problem. Without it, an agent's actions are opaque. You know what it was asked to do, but not what it actually did. A complete audit log records the tool call, the parameters sent, the response received, and the timestamp. That record is the difference between "we think the agent only read the data" and "we can prove it." **Control** solves the incident response problem. When an agent behaves unexpectedly, the question is: how do you stop it, and how quickly? With credentials embedded in deployment configs, stopping an agent means rotating keys and redeploying, which takes time and may break other systems sharing the same key. A dedicated control plane means one revocation call stops the agent across all connected tools, immediately. ## Why MCP is the right control point Model Context Protocol (MCP) is a standard that defines how AI agents call tools. An agent sends a structured request to an MCP server; the server executes the tool and returns a result. Every tool call passes through this protocol boundary. That boundary is the natural enforcement point for an access layer. When the MCP server handles a tool request, it already has everything needed to enforce policy: the requesting agent, the tool being called, and the parameters being passed. Adding identity verification, policy evaluation, and audit logging at this layer requires no changes to the agent or the downstream SaaS tool. The control point is already there. Compare this to the alternative: enforcing governance at the SaaS API layer. That would require integration with every tool's native access control system, each of which has a different model, different APIs, and different audit capabilities. A HubSpot access policy looks nothing like a GitHub access policy. An MCP-level access layer enforces a single, uniform policy model across all connected tools. **The MCP server as access layer** When an MCP server enforces agent identity, evaluates policy before executing tool calls, writes an immutable audit record for each call, and exposes a control API for revocation and pause, it is an access layer. The protocol was designed to be this control point. Most implementations today skip the enforcement step entirely. ## What it looks like in practice A concrete example: a sales agent built on Claude has been given access to HubSpot through an MCP server. It receives a task: summarize the last 10 deals closed in the EMEA region. Here is what happens at each step of the access layer: Access layer trace · Agent: sales-assistant-v2 · Tool: HubSpot - 1 Identity check The MCP server receives the tool call and verifies the agent ID against the registry. The agent is sales-assistant-v2, version hash a4f91c, initiated by user marie@acme.com. Identity confirmed. Verified - 2 Policy evaluation The access layer evaluates the call against the agent's policy. The agent has hubspot:deals:read permission scoped to the EMEA pipeline. The call requests a filtered list read. Policy allows it. Allowed - 3 Audit write Before the tool executes, the access layer writes a log entry: agent ID, tool name, full parameter payload, timestamp. The log entry is immutable. If the call is later reviewed, this record is the source of truth. Logged - 4 Tool execution and result The MCP server calls the HubSpot API, retrieves the 10 deals, and returns the result to the agent. The response is logged alongside the request. The agent never touches HubSpot credentials directly. Complete The full round trip adds roughly 2-5ms of latency. The agent sees no difference. The security team now has a complete record of what the agent accessed, who initiated the task, and what parameters were sent. If the agent's behavior changes or a policy needs tightening, the access layer is the single place to update it. AI Agents Claude ChatGPT Copilot Access Layer Identity Agent ID registry. Each agent has a unique, persistent identity tied to its definition and version. Policy Scoped permissions per agent. Which tools, which operations, which parameters are allowed. Audit Immutable log of every tool call. Agent, tool, parameters, response, timestamp. Control Kill switch, pause, and reassign. One revocation point across all connected tools. SaaS Tools HubSpot Slack GitHub Notion ## Lutril as an access layer Lutril implements the four components as an MCP server. Each agent that connects through Lutril gets a stable identity. Permissions are defined per agent using the same role framework your team uses for human access. Every tool call is logged with full context. Revocation is a single operation that takes effect immediately across all connected tools. The design follows the same model as enterprise IAM, applied to non-human actors. If your security team can audit a human's SaaS access today, they can audit an agent's access through Lutril in the same way. The access reviews, the offboarding workflow, the compliance evidence: same process, same tooling, extended to cover agents. No separate API keys to rotate. No service accounts shared across agents. No blind spots when an agent is decommissioned. --- # When the Employee Leaves but the Agent Stays > AI agents built by departing employees keep running long after their creator's Okta account is disabled. They still have access. Nobody owns them. Here is what to do about it. Source: https://www.lutril.com/blog/ai-agent-offboarding Published: 2026-06-03 Topic: AI Governance --- ## The orphaned agent problem Your offboarding process catches the obvious things. Okta account disabled. Laptop returned. Slack deactivated. The employee is gone. What it does not catch: the three AI agents they built over the past year. One reads the CRM and sends weekly pipeline summaries. One monitors the GitHub repo and posts alerts to Slack. One runs nightly against the billing data and generates reports. All three are still running on Monday morning. All three still have access. None of them appear anywhere on the offboarding checklist. This is the orphaned agent problem. It is new, it is growing, and almost no standard offboarding process accounts for it. ## Why standard offboarding misses it Traditional offboarding was designed for a world where access meant accounts. Disable the SSO account, deprovision the federated apps, revoke the VPN. Done. AI agents break that model in two ways. First, agents typically authenticate with API keys or OAuth tokens rather than SSO. When you disable an employee's SSO account, those credentials are not automatically revoked. The agent keeps calling APIs with the same token it has always used, under the same permissions, with no indication in any log that its owner no longer works there. Second, agents are not in your identity provider. There is no user record to disable, no group membership to remove, no SCIM event to trigger. The agent simply does not exist in the systems that handle offboarding. The result: an agent built by a departed employee is functionally indistinguishable from one built by a current employee, right up until something goes wrong. ## Three scenarios that play out differently Scenario A: The agent keeps running silently The sales ops manager leaves. She built an agent that reads HubSpot deals every Monday and sends a summary to a Slack channel. Nobody knows she built it. It keeps running. Six months later, the channel gets a message with deal names and amounts. The new sales ops manager has no idea where it is coming from or how to stop it. The risk here is not immediate but it compounds. An unowned agent with live business data access, no audit owner, and no one who knows how to modify or stop it represents ongoing exposure that quietly grows. Scenario B: The agent's credentials were tied to the employee's personal account A developer built an agent using their own Google OAuth token to access Google Drive. Their Google account is disabled on their last day. The agent's token is invalidated. Every downstream process that depended on the agent fails silently or starts throwing errors. IT gets involved, nobody knows what the agent was doing or how it was set up, and recovery takes days. This scenario is actually the better outcome. At least the access is gone. The problem is the operational disruption, not the security exposure. Scenario C: The agent used a service account the employee created An engineer built an agent and provisioned it with a service account they created specifically for it. The service account is not tied to the employee's SSO identity. When the engineer leaves, their SSO account is disabled. The service account persists. The agent persists. Six months later, the engineer is discovered to still have access to production systems through the service account, which was never in scope for the offboarding ticket. This is the worst outcome. Persistent access, no audit trail of who owns it, and potentially a security incident waiting to happen. ## What to do at departure When an employee leaves, the question for AI agents is not just "disable" versus "keep running." It depends on whether the agent is still useful to the business. 1 Discover Find every agent the departing employee owned or provisioned. This requires an agent registry, not a manual search. 2 Evaluate Is the agent still needed? Review what it does, what it accesses, and whether the business depends on it. 3 Reassign or suspend If keeping it: assign a new owner and confirm the access scope is still appropriate. If not: suspend and revoke. 4 Document Log the decision with the reviewer's name and timestamp. This is your audit evidence that the agent was addressed at offboarding. The evaluate step is often skipped under time pressure. The instinct is to suspend everything immediately. That is the safe default for security, but it can break operational workflows without warning. A brief review window of 24 to 48 hours before suspension gives the team time to identify critical agents that need reassignment rather than removal. ## The ownership model that prevents the problem The scenarios above share a root cause: agents were created without a formal ownership record that the offboarding process can act on. The fix is to treat agent ownership the same way you treat human role assignments. When an agent is registered, it gets an owner. That owner is a named employee in your identity system, not a team or a department. When that employee is flagged for offboarding, every agent they own is flagged alongside them. Agents flagged for review · Owner: m.santos@company.com (departing) 3 agents require action Agent Owner State Risk score pipeline-summarizer agt_3kPqRx · HubSpot read m.santos (departing) Flagged 42 / 100 repo-watchdog agt_9mTvLw · GitHub read, Slack write m.santos (departing) Flagged 58 / 100 billing-reporter agt_2nHcBp · Stripe read m.santos (departing) Flagged 74 / 100 The billing-reporter agent has a risk score of 74 because it has read access to Stripe. That is the one that needs immediate attention. The pipeline summarizer and repo watchdog can probably be reassigned with minimal review. Without a registry that surfaces this automatically, all three are invisible to the offboarding process. For each flagged agent, the decision comes down to three options: A **Reassign to a new owner** The agent is still useful. A new owner takes responsibility, reviews the current access bindings, and confirms the scope is still appropriate for the work the agent does. B **Suspend pending evaluation** The agent may be useful but needs more review than time allows right now. Suspend it immediately to stop access, then evaluate within a defined window (48 hours is reasonable). C **Revoke permanently** The agent was personal to the departing employee, or nobody is willing to own it going forward. Revoke access, document the decision, and retire it. ## The compliance angle SOC 2 CC6.3 requires that access is removed when no longer needed. An agent whose owner has departed and whose access has not been reviewed is, by definition, access that may no longer be needed. If an auditor asks "how do you ensure access is removed when an employee leaves" and the answer does not cover AI agents, that is a gap in the control. The EU AI Act adds a layer on top. Article 14 requires that high-risk AI systems include mechanisms that allow humans to oversee and intervene. An unowned, undiscovered agent running against production data has no human in the loop at all. That is an accountability gap, not just a security one. **The question auditors are starting to ask** When an employee who deployed AI agents in your environment departs, how do you ensure those agents no longer have access to business systems? If your answer is "we check manually" or "we are not sure," that is the gap. The control needs to be systematic, not best-effort. The practical requirement is straightforward: every AI agent in your environment needs a named owner in your identity system. When that owner is offboarded, the agent is automatically flagged for review. The review decision, whatever it is, gets logged with a timestamp and the name of the reviewer. That is what a defensible control looks like. What makes this hard is the discovery step. You can only flag agents whose owner is departing if you know which agents exist. A registry that captures agent creation from the start is what makes the offboarding step tractable. Without it, you are always doing archaeology: searching for agents after the fact, with no authoritative record of what was built. --- # Okta, Azure AD, and Lutril: Who Manages Access When AI Agents Enter the Picture? > Okta and Azure AD are excellent at managing human identity. Neither was designed for AI agents. Here is where each fits, where the gaps are, and why you probably need all three. Source: https://www.lutril.com/blog/okta-azure-ad-vs-lutril-ai-agents Published: 2026-06-03 Topic: AI Governance --- ## The question IT is starting to ask Most mid-market and enterprise companies have spent real time getting their IAM right. They have Okta or Azure AD configured with SSO across every major SaaS tool, SCIM provisioning tied to their HR system, MFA enforced universally, and lifecycle policies that revoke access within minutes of a termination event. That work is real, it matters, and it works well. Then the engineering or operations team deploys an AI agent. The agent needs to read and write to Salesforce. It needs to create Jira tickets, post to Slack, pull from a knowledge base. The access requests start landing on the IT desk, and the existing playbook does not fit. The agent is not a human. It does not have a manager. It does not have a lifecycle that maps to hire and terminate. It makes dozens or hundreds of tool calls per hour, driven by LLM output rather than deliberate user intent. The question IT is starting to ask is: does my existing IAM cover this, or do I need something else? The honest answer is: your existing IAM is the right foundation, but it does not cover agents natively. Here is exactly what each product handles and where the boundary sits. ## What Okta does (and doesn't do) Okta is genuinely excellent at what it was built to do. Its core capabilities are deep and well-proven across thousands of enterprise deployments. - **Single sign-on.** Okta's SSO catalog covers thousands of SaaS integrations. Employees authenticate once and access every connected application without re-entering credentials. The coverage and reliability here are best-in-class. - **Lifecycle management with SCIM.** When someone joins or leaves, Okta propagates that change to every connected application automatically. Deprovisioning on termination is reliable and fast when SCIM is properly configured. - **Adaptive MFA.** Okta's risk-based authentication evaluates signals including device posture, network, and location before deciding whether to challenge a login. This catches credential-based attacks that would get through static password policies. - **Group-based access policies.** Role assignments flow from groups, which flow from your HRIS. A new hire in engineering gets the right tools automatically. A promotion from analyst to manager triggers role changes without a manual ticket. Where Okta stops is at the concept of agent identity. Okta's directory is a directory of humans and, to a lesser extent, service accounts. When you add an AI agent, the common workaround is to create a service account in Okta, give it a machine credential, and assign it to relevant application groups. That works at a basic level. The agent can authenticate. It can access the SaaS tools you grant it. What Okta does not have: a first-class concept of agent identity, no mechanism for defining which specific tool calls an agent is permitted to make within a connected application, no audit log that records LLM-driven tool call sequences, and no kill switch that halts a specific running agent session when something goes wrong. The service account workaround was designed for infrastructure automation, not for an LLM-driven agent that decides autonomously what actions to take based on a task it was given. **The service account gap** A service account in Okta has a credential, a set of group memberships, and an application assignment. It has no concept of "this agent is allowed to read Salesforce contacts but not modify opportunity stage." That granularity lives nowhere in the current Okta data model. It also has no audit trail that ties individual tool calls back to the specific agent run that made them. ## What Azure AD (Entra ID) does (and doesn't do) Microsoft renamed Azure Active Directory to Microsoft Entra ID in 2023. The underlying capabilities are strong, particularly for organizations running Microsoft 365 workloads, Azure infrastructure, or both. - **Conditional access policies.** Entra ID's conditional access is one of the most granular policy engines in enterprise IAM. You can require compliant devices, specific network conditions, or authentication strength based on application sensitivity and user risk signals. - **Managed identities for Azure workloads.** For applications and services running inside Azure, managed identities eliminate the need for stored credentials entirely. An Azure function or VM gets an identity that Azure manages, and you assign it roles in RBAC. This is well-designed for Azure-native infrastructure. - **Microsoft 365 integration.** For organizations already in the Microsoft ecosystem, Entra ID provides deep integration with SharePoint, Teams, Exchange, and Dynamics that Okta cannot match natively. - **Privileged Identity Management (PIM).** PIM enables just-in-time role activation with approval workflows and time-bound access. This reduces standing privilege for sensitive roles. For AI agents, the picture is similar to Okta. Managed identities work well if your agents are Azure-hosted and only calling Azure APIs. Once an agent needs to call SaaS APIs outside the Azure ecosystem, including tools like Salesforce, Notion, Slack, or any MCP-connected service, managed identities do not extend there. The agent needs a separate credential or OAuth token managed outside of Entra ID. Entra ID has no policy layer for MCP tool calls. It cannot enforce that an agent is permitted to send a Slack message but not delete a channel. It does not capture tool call sequences at the agent level. Its audit logs record authentication events and resource access at the Azure RBAC level, not the semantics of what an LLM-driven agent decided to do with the access it was granted. **Managed identities vs. agent identity** A managed identity proves "this Azure compute resource is who it says it is." That is a solved problem for Azure workloads. What it does not provide is a governance model for the behavior of the code running on that compute resource: what tools it calls, in what sequence, under whose authorization, and with what audit trail across the full task execution. ## The gap both leave open Okta and Azure AD were built before LLM agents existed as a deployed concept. The gaps are not failures of execution. They reflect a scope boundary that made complete sense until recently. Neither product today handles: - **Agent identity in the directory.** There is no first-class object type for "AI agent" with properties like owning team, purpose, permitted tools, and session lifetime. Service accounts are a workaround, not a fit. - **Per-tool-call policy enforcement.** Neither Okta nor Azure AD can express or enforce a policy like "this agent may read CRM records but not update opportunity stage." Application-level permissions are coarse. The granularity required for agent governance does not exist in the current IAM model. - **Immutable audit logs for LLM tool calls.** When an agent runs a multi-step task and calls ten different APIs in sequence, the existing IAM audit logs record the authentication event. They do not record the tool call sequence, the LLM decision that preceded each call, or the data returned. That record is gone when the session ends. - **Kill switches for running agents.** If an agent is behaving unexpectedly mid-task, there is no mechanism in Okta or Azure AD to halt that specific agent session without revoking access for the entire service account, which may affect unrelated systems. - **Role parity between humans and agents.** In a well-governed environment, a human with read-only access to a system should translate to an agent with the same read-only access. That parity mapping does not exist. The agent's access is configured independently of the human role definitions it is supposed to mirror. These are not edge cases. They are the basic governance requirements for any organization that wants to extend its existing security posture to cover AI agents. ## How they compare Across the dimensions that matter for a complete access governance picture: | Dimension | Okta | Azure AD / Entra ID | Lutril | | --- | --- | --- | --- | | Human SSO | Excellent | Excellent | Not applicable | | Human lifecycle (SCIM) | Excellent | Excellent | Via integration | | MFA / adaptive access | Excellent | Excellent | Not applicable | | AI agent identity | No | No | Yes | | MCP-native policy enforcement | No | No | Yes | | Per-tool-call audit log | No | No | Yes | | Agent kill switch | No | No | Yes | | Role parity (humans and agents) | No | No | Yes | Reading this table the right way: the "Not applicable" cells for Lutril in the human identity rows are not absences. Lutril does not attempt to replace Okta or Azure AD for human SSO and lifecycle. That work is already done, and replacing it creates no value. The table reflects scope, not competition. ## Why you need all three The right architecture is layered. Okta or Azure AD handles what it was built to handle: human authentication, lifecycle management, MFA, group-based access. That layer is solid and should stay in place. Lutril sits on top of that as the agent governance layer. Rather than replacing your IdP, Lutril reads role and group definitions from your existing Okta or Azure AD setup and uses them as the source of truth for what agents should be permitted to do. If a Salesforce analyst in your IdP has read-only access, an agent acting on behalf of that analyst inherits read-only access. The parity is enforced automatically, not configured manually per agent. On top of that source of truth, Lutril enforces per-tool-call policy through MCP. When an agent attempts a tool call, the policy is checked before execution: is this agent permitted to run this specific tool, at this time, under this task context? If not, the call is blocked and logged. If yes, the call proceeds and the full context is written to an immutable audit record. The integration works in the other direction too. When a human is offboarded in your IdP, Lutril sees that change and revokes or suspends any agent that was operating on their behalf. You do not need to build a separate offboarding workflow for agents. The existing human lifecycle triggers agent lifecycle automatically. ## When to add an agent access layer A few specific triggers indicate the moment the service account workaround stops being adequate: - **First AI agent with SaaS access.** The moment an agent can write to a production system, the risk profile changes. Read-only access to internal documentation is low stakes. Write access to Salesforce, Jira, or any system with customer data needs governance that a service account cannot provide. - **First SOC 2 or ISO 27001 audit question about agents.** Auditors are starting to ask about AI agent access controls. "We have a service account" does not satisfy the access control criteria in CC6.1 or A.9 when the access is being exercised by autonomous LLM-driven behavior. You need a policy record, an audit log, and evidence of scope limitation. - **First departure of someone who provisioned agents.** When the engineer who set up the agent leaves, who knows what that agent can do? If the answer is nobody, the agent outlives the person who understood it. That is the same problem as shadow IT, applied to autonomous systems. - **More than one team deploying agents.** When multiple teams have agents running in production, the governance surface grows faster than the ability to track it manually. A central policy layer becomes necessary at this point, not optional. If none of these apply yet, the service account approach may be adequate for now. When any of them arrive, that is the right time to layer in dedicated agent governance rather than trying to stretch a human identity model further than it was designed to go. --- # How to Connect Claude to Slack via MCP with Access Controls > Register a Claude agent in Lutril, connect Slack as an MCP app, bind the integration with the right scope, and configure Claude to use it. Every tool call logged from the start. Source: https://www.lutril.com/blog/connect-claude-slack-mcp-lutril Published: 2026-06-03 Topic: Tutorial --- ## Overview Lutril sits between Claude and Slack as an MCP proxy. Claude calls tools through Lutril rather than holding a Slack token directly. Lutril checks that the calling agent has a binding to Slack, forwards the call, and writes an immutable record to the activity log. The setup has four moving parts: the Slack MCP app connection (OAuth), the agent registration, the binding that grants the agent access to Slack, and the Claude configuration that points at Lutril's MCP server. This guide walks through each one. ## Prerequisites **Lutril account** with admin or member access **Slack workspace** where you can authorize a new app **Claude Desktop** or a project using the Claude API with MCP support - 1Connect Slack as an MCP app ## Connect Slack as an MCP app Before any agent can call Slack tools, your workspace needs to authorize Lutril to access Slack on its behalf. This is a one-time OAuth step done by an admin. In Lutril, go to **MCP Apps**. You will see the available integrations: Slack, HubSpot, Notion, Mixpanel, and others. Find the Slack card and click **Connect**. You will be redirected through Slack's OAuth flow. Lutril requests these scopes: - `channels:read` : list public channels - `channels:history` : read message history in public channels - `chat:write` : post messages as the Lutril bot - `users:read` : resolve user IDs to names in activity logs After authorization, the Slack card shows a **Connected** badge with the connection date. Lutril now holds the Slack credential. Individual agents do not hold it. They request access through bindings, which you add in the next step. - 2Register the agent ## Register the agent in the Agent Registry Go to **Agent Registry** and click **Register agent**. Fill in the form: Register agent Agent name claude-slack-assistant Owner your@company.com Purpose Reads Slack channels and posts summaries to #ai-updates Expires at 90 days from today (max) Tags slack, comms Click **Register**. Lutril creates the agent in `draft` state and generates an MCP token. **This token is shown exactly once.** Copy it before closing the modal. MCP Token : copy now agt_7fRxP2kq8m@tenant_4hJnW:sk_live_•••••••••••••••••••••••• This secret is not stored and cannot be retrieved again. Rotate it from the agent detail page if needed. The modal also shows two configuration snippets: one for Claude Code and one for `.mcp.json`. Copy the one that matches your setup and keep it handy for Step 4. - 3Add a Slack binding ## Add a Slack binding to the agent The agent exists but has no access to anything yet. Click into the agent row to open its detail panel, then go to the **Bindings** tab. Click **Add binding**, select **Slack** from the integration dropdown, choose a scope, and confirm. Two scope options: Slack read List channels, read message history. No ability to post. Slack read + write Read access plus the ability to post messages. For a Slack assistant that reads channels and posts summaries, select **read + write**. The risk score on the agent updates automatically once the binding is saved. Now activate the agent. Back in the **Overview** tab, click **Activate**. State moves from `draft` to `active`. The agent can now call Slack tools through Lutril. - 4Configure Claude ## Configure Claude to use Lutril Lutril's MCP server exposes all your connected integrations as tools. You point Claude at it using the MCP token from Step 2. For **Claude Desktop**, open `~/Library/Application Support/Claude/claude_desktop_config.json` and add: ``` claude_desktop_config.jsonjson { "mcpServers": { "lutril": { "command": "npx", "args": ["-y", "@lutril/mcp-server@latest"], "env": { "LUTRIL_MCP_TOKEN": "agt_7fRxP2kq8m@tenant_4hJnW:sk_live_..." } } } } ``` For **Claude Code** or a project-level setup, use `.mcp.json` at the root of your project: ``` .mcp.jsonjson { "servers": { "lutril": { "type": "stdio", "command": "npx", "args": ["-y", "@lutril/mcp-server@latest"], "env": { "LUTRIL_MCP_TOKEN": "${LUTRIL_MCP_TOKEN}" } } } } ``` Keep the token in an environment variable rather than committing it directly. Restart Claude Desktop after saving the config. - 5Test and monitor ## Test it and check the activity log Ask Claude something that requires Slack access. Claude will invoke the relevant tool through Lutril, and you will see the calls appear in real time under **MCP Activity**. - agt_7fRxP2 list_channels24 channels returned Slack Success 41 ms - agt_7fRxP2 get_messages#general · 50 messages Slack Success 178 ms - agt_7fRxP2 post_message#ai-updates · summary posted Slack Success 94 ms Each row is expandable. Click one to see the full input parameters, response payload, and the actor that triggered the call. Every entry is immutable and exportable for compliance purposes. If the agent attempts to use an integration it does not have a binding for, the call is blocked and an **Access Request** is created automatically under the Access Requests tab. An admin can approve or deny it from there, with an optional expiry date. ## Managing the agent lifecycle A few things worth knowing for ongoing management: - **Expiry.** Agents must have an expiry date (maximum 90 days). When an agent expires, it stops working and needs to be renewed explicitly. This is intentional: it forces a periodic review of whether the agent should still exist. - **Suspension.** Admins can suspend an agent immediately from the Agent Registry. All Slack access stops. Reactivation is also one click. - **Token rotation.** If the MCP token is compromised, go to the agent detail page and rotate the credential. The old token gets a 24-hour grace window, then becomes invalid. - **Owner offboarding.** If the agent's owner leaves the company, Lutril flags the agent for reassignment. Access does not silently continue under a deprovisioned user. Agent identity Every tool call is attributed to `agt_7fRxP2` in the activity log, not a raw Slack token. Scope enforcement The agent can only call tools covered by its bindings. Anything outside that is blocked and logged as an access request. Audit trail Immutable log of every call with full context. Exportable for SOC 2 evidence. Kill switch Suspend the agent from the registry. Slack access stops immediately across every environment using that token. --- # Employee Offboarding Security: What Access Actually Gets Removed > 41% of employees keep access to company systems after leaving. Most of that access sits in SaaS tools your IdP never touched. Here is what complete access revocation actually requires. Source: https://www.lutril.com/blog/employee-offboarding-security Published: 2026-06-03 Topic: Offboarding --- ## Short answer To make sure an employee loses all SaaS access the day they leave, start from the HRIS departure date rather than from a ticket, and revoke more than the SSO account: SaaS accounts created with a password, OAuth grants from Sign in with Google or Microsoft, API keys, shared credentials and the AI agents the person owned all survive an IdP deactivation. Complete offboarding lists every account the person holds across every SaaS tool, revokes each one, reassigns or retires their agents, and keeps proof of each removal. Lutril runs that sequence automatically from the HRIS event and logs every revocation. ## The offboarding gap When an employee leaves, IT gets a ticket. They disable the Okta account, maybe revoke a VPN certificate, and mark it done. It takes 30 minutes on a good day. The problem is that the Okta account is only one layer of access. The average knowledge worker accumulates dozens of independent credentials over their time at a company: apps they signed up for with Google, tools IT provisioned directly, API keys they generated, integrations they configured. None of those go away when Okta goes dark. - **41%**: of leavers keep access - **3–5**: days avg. to full removal - **30%**: of SaaS not SSO-managed ## What survives after SSO is disabled SSO and SCIM solve the problem they were designed to solve: federated identity for apps that support it. That covers your core stack well. It does not cover everything, and the gap is wider than most IT teams realize. Access status after SSO deprovisioning Access type Examples Status SSO-federated apps Jira, Confluence, Salesforce (SSO) Revoked Google OAuth apps Notion, Loom, Figma (Google login) Still active Direct-login SaaS Legacy tools, vendor portals Still active API keys they generated HubSpot, Stripe, AWS tokens Still active AI agents they provisioned Agents using their credentials Still active Shared credentials Team accounts, vendor logins Unknown The OAuth apps are the biggest blind spot. An employee who signed into Notion with their Google account while still employed will retain access to that Notion workspace indefinitely after their Google account is disabled, if the Google account was disabled but the Notion session or token was not explicitly revoked. More importantly: IT often does not know which apps fall into which category. The discovery step is missing from most offboarding checklists. ## The exposure window Even when IT has the right processes, timing matters. There is always a gap between when someone's last day is and when all access is confirmed removed. In practice, this gap is often measured in days or weeks, not hours. The risks that live in that window are not theoretical. Departing employees with lingering access to CRM data, source code, or financial systems represent a real exposure. Most security incidents attributed to former employees do not involve sophisticated attacks. They involve someone using credentials that were never revoked. The exposure window has three drivers: - **Manual ticket chains.** Offboarding triggers a series of tasks assigned to different teams. Each handoff is an opportunity for delay or omission. - **Incomplete asset inventory.** You can only revoke access to tools you know the employee used. Shadow IT means the inventory is always incomplete. - **No verification step.** Most offboarding processes have no mechanism to confirm that all access has been removed, only that the ticket was closed. ## What complete employee offboarding covers A complete offboarding covers more ground than most IT checklists include. In rough order of priority: - IdP deprovisioning. Disable the SSO account and trigger SCIM deprovisioning for all federated apps. This should happen automatically, ideally tied to an HR system event. - OAuth token revocation. Revoke all OAuth grants the employee issued, across every connected app. This requires discovery: you need to know which OAuth connections exist before you can revoke them. - API key rotation. Identify and rotate or revoke any API keys the employee generated in tools they had admin or developer access to. - Direct-login SaaS removal. Remove accounts in tools that are not SSO-managed. This requires knowing which tools the employee had access to independently of the IdP. - AI agent deprovisioning. Suspend or reassign any AI agents the employee provisioned or that operated under their credentials. - Shared credential rotation. Any shared passwords or service accounts the employee had access to should be rotated. This is often skipped because there is no clean record of what shared credentials exist. - Verification audit. A final check confirming that the employee no longer appears as an active user in any system. This step is what turns offboarding from a process into a control. ## The AI agent complication Most offboarding checklists were written before AI agents became a standard part of how people work. They have not been updated. When an employee sets up an AI agent, they typically provision it under their own credentials: their API key, their OAuth token, their service account. The agent acts on their behalf. When the employee leaves, the agent does not automatically stop. Unless someone knows the agent exists and explicitly deprovisions it, it keeps running with access that was supposed to expire. This is not a hypothetical. Sales teams run agents against CRM data. Engineers set up agents with repository access. Finance teams build agents connected to billing systems. Each of those agents represents a persistent access path that the standard offboarding ticket will not catch. The fix requires agents to be first-class entities in your access model: registered identities with owners, not anonymous API keys. When the owner is offboarded, the agent should be suspended automatically or reassigned to a new owner with an explicit review step. ## From manual to systematic The reason offboarding security fails is that it depends on humans executing a checklist correctly under time pressure, with incomplete information, for every departure. That model does not scale and does not produce consistent results. Systematic offboarding ties access removal directly to the HR event. When a departure is recorded in the HR system, the access removal workflow starts automatically. It does not wait for a ticket. It does not require someone to remember the checklist. It fires for every departure, including the ones that happen at 5pm on a Friday. The inventory problem, the discovery step that most checklists skip, is the hardest part to automate. You cannot remove access to tools you do not know exist. That requires continuous SaaS discovery running ahead of the offboarding event, not a manual audit triggered by it. ## Frequently asked questions ### Is disabling the Okta or Entra ID account enough to offboard someone? No. It stops new SSO logins. It does not touch SaaS accounts created with an email and password, OAuth tokens already issued, API keys, or AI agents the person set up. Those keep working until each one is revoked in the tool itself. ### How do I find every SaaS account a leaver still holds? Cross the HRIS record with the account lists pulled from each connected SaaS tool, plus the OAuth grants and sign-in logs in Google Workspace or Microsoft 365 for the apps that never went through IT. Lutril's Access Grid does this continuously, so the list exists before the departure date, not after. ### What should happen to the AI agents a leaver owned? Each agent needs a new owner or an end date. An agent with no owner keeps its credentials and keeps acting. Lutril's agent registry surfaces every agent owned by the leaver in the offboarding run so each one is reassigned or retired, and the change is logged. ### What evidence do auditors expect for offboarding? For each leaver: the departure date, the list of accounts held, the timestamp each was revoked, and who or what did it. SOC 2 CC6.2 and CC6.3 and ISO 27001 A.5.18 all look for this. Lutril produces it as one exportable log per departure. --- # Shadow IT: Your IT Team Knows About 40 SaaS Apps. You Have 130. > Shadow IT is not a policy failure. It is the natural result of frictionless SaaS adoption. Here is why it keeps growing, what security and compliance risk it actually creates, and what to do about it beyond writing a policy nobody reads. Source: https://www.lutril.com/blog/shadow-it-risks Published: 2026-06-03 Topic: Shadow IT --- ## Short answer To detect the shadow IT apps employees signed up for with their Google or Microsoft account, read the OAuth grants and sign-in logs in Google Workspace or Microsoft 365: every Sign in with Google or Sign in with Microsoft authorization appears there, with the scopes it was granted, who granted it and when. Lutril pulls that data the day you connect the workspace and turns it into an inventory with an owner, a risk score and a decision per app. Apps created with a work email and a password never show up in OAuth logs; the Lutril Chrome extension catches those at the point of use. ## What shadow IT actually is today Shadow IT used to mean a team spinning up an unauthorized server, or someone plugging in a personal USB drive. That framing is out of date. Today, shadow IT is almost entirely SaaS: tools employees adopt independently, without going through IT approval, procurement, or security review. It does not look like a policy violation from the inside. It looks like a marketer signing up for a free Notion account to organize a campaign. A developer connecting a GitHub repo to a new CI tool to ship faster. An executive using a personal ChatGPT subscription to draft board materials. Each individual decision is reasonable. The aggregate is a large, unmanaged, invisible surface area. - **3x**: more apps than IT knows - **2–3**: new apps added per employee / month - **80%**: via Google or email sign-up ## How it spreads The structural reason shadow IT keeps growing is that signing up for a new SaaS tool is now trivially easy. A Google "Sign in with Google" button, a work email address, and you have an active account in under 60 seconds. No ticket, no approval, no procurement cycle. Three patterns drive most of it: - **OAuth sign-in.** Employees connect new tools using their Google or Microsoft identity. This creates an active session in a tool your IdP never touched and may not know exists. - **Free tiers.** Most SaaS products have a free tier that requires no corporate involvement. The tool starts as a personal experiment and becomes a team workflow before IT is ever notified. - **Team sprawl.** One person adopts a tool, finds it useful, and shares it with their team. By the time IT discovers it, there are 20 active users and real business data inside. IT policies requiring approval before adopting new tools exist at most companies. They do not slow SaaS adoption, because the friction of following the process exceeds the friction of just signing up and dealing with it later. ## The real risks Shadow IT risk gets framed as a compliance problem, and it is. But the compliance framing understates what is actually at stake. **Data you cannot account for** When an employee uploads customer data to a free-tier AI writing tool, that data leaves your environment and lands in a third-party system you have no contract with, no DPA for, and no way to audit. GDPR Article 28 requires a data processing agreement with every processor that handles personal data. Shadow IT creates processors you do not know about. **Access you cannot revoke** Every shadow IT tool is an account your offboarding process will miss. When an employee leaves, their Notion workspace, their Grammarly account with access to all their written content, and their personal ChatGPT subscription with uploaded documents all remain active. The accounts survive the departure because they were never in scope. **Audit evidence you cannot produce** SOC 2 and ISO 27001 ask you to demonstrate that access to systems holding sensitive data is controlled. Shadow IT tools are systems holding sensitive data with zero access controls. An auditor sampling actual employee access will find accounts in tools that were never on any access review. ## What a shadow IT discovery scan actually shows Most IT teams are surprised by the results of their first comprehensive shadow IT scan. Not because the tools are exotic, but because of the volume and what they contain. - ChatGPT (personal) 38 Internal docs, customer data High - Notion (personal accounts) 21 Project data, customer notes High - Grammarly 89 All written content Medium - Loom (free tier) 14 Screen recordings, demos Medium - Zapier (personal) 7 CRM and email data High The Grammarly finding surprises people most. 89 users means effectively your entire writing-heavy workforce has a browser extension with access to everything they type, connected to a third-party service under their personal accounts. It is not malicious. It is completely invisible to IT until a scan surfaces it. ## Govern, not block The instinct after a shadow IT scan is to block. Revoke OAuth grants, enforce browser policies, tighten the approval process. That instinct produces two outcomes: employees find workarounds, and legitimate productivity tools get caught in the net. A more effective approach distinguishes between tools by risk level and treats them accordingly: | Category | Approach | Why | | --- | --- | --- | | High-risk, no business case | Block and communicate why | Reduce surface area where no legitimate need exists | | High-risk, clear business case | Fast-track to managed status | Employees will use it either way. Better to have a DPA and SSO | | Medium-risk, widespread use | Adopt and govern | Blocking 89 Grammarly users creates more friction than value | | Low-risk, limited use | Monitor and review quarterly | Not worth enforcement overhead for minimal risk | The goal is not zero shadow IT. That is not achievable without blocking productivity. The goal is known shadow IT: a continuous, up-to-date picture of what tools exist, who uses them, and what data they touch, so you can make risk decisions rather than discovering problems during an audit. ## The offboarding connection Shadow IT and offboarding are the same problem from different angles. Shadow IT is the discovery problem: you do not know what tools an employee uses. Offboarding is the remediation problem: you cannot remove access to tools you do not know about. Every shadow IT tool an employee uses is an account that will survive their departure. The Notion workspace, the personal ChatGPT subscription with uploaded documents, the Zapier account routing CRM data to personal email. None of those appear on the standard offboarding ticket. All of them remain active when the Okta account goes dark. Solving shadow IT is therefore a prerequisite for complete offboarding. Continuous discovery running ahead of every departure is what makes the offboarding checklist accurate, rather than a best-effort approximation of the access that actually exists. ## Frequently asked questions ### How can I detect shadow IT apps employees signed up for with their Google account? In Google Workspace, the OAuth grants and the token audit log list every third-party app a user authorized with Sign in with Google, including the scopes. Microsoft 365 exposes the same through Entra ID enterprise applications and sign-in logs. Lutril reads both continuously and flags new apps as they appear. ### What does OAuth discovery miss? Any app someone signed up for with a work email and a password instead of Sign in with Google or Microsoft. Nothing is written to the identity provider. That gap is why Lutril ships a Chrome extension that recognises SaaS and AI tools in the browser, and why it also scans mailboxes for sign-up and receipt emails. ### Should shadow IT be blocked? Usually not. Blocking pushes the same tool onto a personal account where nobody can see it. The workable pattern is discover, assign an owner, decide (approve, replace or retire), and put the approved tools under normal access governance with offboarding included. ### How is shadow AI different from shadow IT? Shadow AI is shadow IT that reads your data and, with agents, acts on your systems. The discovery sources are the same (OAuth grants, sign-in logs, mailbox receipts, the browser extension) plus code scanning for agents wired to API keys in GitHub and GitLab. --- # SOC 2 Wants Proof. Not a Spreadsheet. > Most access reviews are a formality. Managers approve without context, shadow IT goes unreviewed, and evidence is thin. Here is what SOC 2 and ISO 27001 actually require, and what closing the gap looks like. Source: https://www.lutril.com/blog/access-reviews-soc2-iso27001 Published: 2026-06-03 Topic: Compliance --- ## Short answer Software that automates user access reviews for SOC 2 has to do five things: collect who has access to what across every SaaS tool, assign each line to a reviewer, record a keep-or-remove decision, execute the removals, and export the evidence in a form an auditor accepts. Lutril's access review campaigns do all five. The Access Grid is the inventory, reviewers decide in Slack, Teams or the app UI, removals execute automatically, and the evidence is one link showing who reviewed what, when, and proof the revocation happened, mapped to SOC 2 CC6.1 to CC6.3 and ISO 27001 A.5.18. ## Your access review works on paper Every quarter, someone on the security team sends a spreadsheet to 40 managers. The managers are busy, uncertain about what their reports actually use, and unclear on what "review" really means. They click approved on most rows and send it back. Someone collects the responses. The audit evidence folder gets another attachment. This is how most companies do access reviews today. It satisfies the letter of the requirement. It increasingly doesn't satisfy auditors, and it definitely doesn't satisfy the spirit of what SOC 2 and ISO 27001 are asking for. ## What the standards actually require Both SOC 2 and ISO 27001 care about the same fundamental question: **can you prove that access is controlled, appropriate, and cleaned up when it shouldn't be there anymore?** - SOC 2CC6.2 Logical access to system components is restricted to authorized users. New accounts are provisioned only with appropriate authorization. Access is based on the minimum necessary for the user's role. - SOC 2CC6.3 Logical access is removed or modified in a timely manner when no longer needed, including terminations, role changes, and changed business requirements. - ISO 27001A.8.2 Access rights of all employees and contractors are reviewed at regular intervals. Rights are adjusted or revoked when no longer appropriate following role changes or departures. - ISO 27001A.8.3 All access rights of employees and contractors are removed upon termination or expiry of employment, contract, or agreement. The key distinction for SOC 2 is between **Type I** and **Type II**. Type I says: "we have controls designed to achieve these criteria." Type II says: "those controls operated effectively over the audit period." For access reviews, Type II means demonstrating that reviews happened, were complete, and resulted in removals, consistently over 6–12 months. "We have a policy" is a Type I answer to a Type II question. ## Three ways access reviews fail in practice **Failure 1: The coverage gap** Your IdP shows you the apps it manages. But SaaS adoption has outpaced SSO rollout at most companies. Employees sign up with a Google login, use personal accounts, or get provisioned directly in tools that aren't federated. The result: your access review only covers a fraction of actual access. During a SOC 2 audit, a sampled user in Salesforce, Notion, or HubSpot will often have accounts that weren't in scope. That's a finding. **Failure 2: The context gap** The review email reaches a manager. They see: "Sarah Chen: Salesforce, HubSpot, Notion, Jira, Linear, Figma, Loom, GitHub." Forty rows like this for every person on the team. What the manager needs to answer is: does Sarah still need all of this? Most managers don't know. They don't know Sarah hasn't logged into Figma in 3 months, or that her Salesforce admin permissions were expanded for a project that ended in Q1. So they approve everything. The review becomes a formality. **Failure 3: The remediation gap** Even when a manager flags something for removal, the action doesn't always happen. A spreadsheet comment says "revoke Salesforce admin for Tom." Two weeks later, Tom still has Salesforce admin. There's no connection between the review decision and the provisioning system. SOC 2 evidence of a review that identified exceptions but didn't remediate them is worse than no review at all. It shows you knew and did nothing. ## What good evidence looks like What auditors want to see is a closed loop: discovery → review → decision → remediation → evidence. Each step traceable, timestamped, and attributable to a named reviewer. Here's what a structured review campaign looks like when the data is actually there to support it: - User Access Last active Decision Reviewer - Sarah Chen GitHub · Notion · Jira · Linear 2 days ago Keep M. Torres - Tom Okafor GitHub · Salesforce (admin) · AWS 94 days ago Revoke admin M. Torres - Priya Nair Figma · Notion · Linear 61 days ago Revoke Figma M. Torres - James Wu GitHub · Jira · Confluence · AWS Yesterday Keep M. Torres - Amara Diallo HubSpot · Notion · Slack 4 days ago Pending unassigned The "last active" column is what makes the difference between a real review and a rubber stamp. Without it, a manager reviewing Tom's access has no basis for a decision. With it, "94 days ago" on a Salesforce admin account is an obvious flag. For audit purposes, the export from this review needs to show: - Scope: which users and systems were in scope for the review period - Completion: who reviewed what, with timestamps and reviewer identity - Exceptions: what was flagged for removal or downgrade, and why - Remediation: evidence that flagged access was actually removed, with timestamps - Coverage gaps: SaaS tools where access wasn't reviewed because they weren't in scope. Auditors will look for these. ## The frequency question SOC 2 doesn't prescribe a specific review cadence, but most auditors expect quarterly reviews for privileged access and at least annual for standard users. ISO 27001 says "at regular intervals", typically interpreted as quarterly or semi-annual depending on your risk profile. The more useful question is: **why is frequency the constraint?** The quarterly cadence is an artifact of the manual process. Collecting access data, building spreadsheets, chasing manager responses, reconciling removals. It takes long enough that doing it more often isn't realistic. But the underlying risk is continuous. Someone changes roles on a Tuesday in February. The next review isn't until April. For two months, they have access they shouldn't. When access data is live and review campaigns are automated, reviews can be triggered by events: a role change, a project closing, 60 days of inactivity, rather than just the calendar. The quarterly review becomes a compliance artifact that confirms what continuous monitoring already caught, rather than a first line of discovery. That's the difference between access review as a compliance exercise and access review as an actual control. ## Frequently asked questions ### What software automates user access reviews for SOC 2 compliance? Access governance platforms that connect to each SaaS tool, build the who-has-what inventory, run review campaigns with reviewers and decisions, execute the removals, and export evidence. Lutril does this for SaaS tools and AI agents in one campaign, with decisions taken in Slack, Teams or the app UI. ### How often do SOC 2 and ISO 27001 require access reviews? Neither standard fixes a number. SOC 2 CC6.1 to CC6.3 and ISO 27001 A.5.18 require that access rights are reviewed at regular intervals and on role change or departure, and that the review is evidenced. Quarterly for privileged access and at least annually for everything else is what most auditors accept. ### What evidence does an auditor want from an access review? The scope (which systems, which accounts), who reviewed each line, the decision, the date, and proof that removals actually happened in the target system. A spreadsheet with ticks fails the last point. Lutril's campaign export carries the revocation log alongside the decisions. ### Do AI agents need to be in the access review? Yes. An agent holds credentials and permissions like any account. Lutril includes registered agents in the same campaign as employees, so an idle or over-scoped agent gets the same keep-or-remove decision, and the decision executes. --- # Aircall + Lutril: setup guide > Lutril connects to Aircall with an API ID and API Token (the Basic Auth username and password) so it can read and manage your Aircall users. Source: https://www.lutril.com/integrations/aircall Category: Communication Auth: api_key Last verified: 2026-06-17 --- ## Setup 1. Sign in to the Aircall Dashboard with Admin or Owner privileges. 2. [object Object] 3. Aircall generates two strings: the API ID (username) and the API Token (password). Copy both now; the token is shown only once. 4. In Lutril, connect Aircall, paste the API ID and API Token, and optionally set the base URL. ## Access requested - Aircall API access via Basic authentication (create the key as an Admin or Owner) ## References - [Aircall documentation](https://developer.aircall.io/tutorials/basic-authentication/) - [Aircall console](https://dashboard.aircall.io) - [Aircall API references](https://developer.aircall.io/api-references/) --- # Allo + Lutril: setup guide > Lutril connects to Allo, the visual collaboration workspace, with an API key. You can optionally set a custom API base URL. Source: https://www.lutril.com/integrations/allo Category: Productivity Auth: api_key Last verified: 2026-06-17 --- ## Setup 1. Sign in to Allo as a workspace administrator. 2. Open your workspace or account settings and look for the API or developer section to generate an API key. 3. Copy the API key and store it securely. 4. In Lutril, connect Allo, paste the API key, and optionally set a custom API base URL. ## Access requested - API access tied to the key's account and role ## References - [Allo documentation](https://withallo.com/) - [Allo](https://withallo.com/) --- # Ansys + Lutril: setup guide > Lutril needs an Ansys ID Portal Personal Access Token (PAT) plus your account number. It lists the members of your Ansys account with their roles, adds new members when access is granted, and removes members when people leave. Source: https://www.lutril.com/integrations/ansys Category: SaaS Auth: api_key Last verified: 2026-08-04 --- ## Setup 1. [object Object] 2. Click your profile icon and select Personal access token. 3. Click Create Token, name it (for example "Lutril"), set an expiration date, and select Full Access under Scope. 4. Click Create and copy the token; note your account number from the account picker or the account details page. 5. In Lutril, open Integrations, choose Ansys, then paste the PAT and enter the Account Number. ## Access requested - PAT scope: Full Access (required for SSO token exchange) - PAT owner: member of the governed account, with an Account Admin role to add and remove users ## References - [Ansys documentation](https://developer.ansys.com/docs/ansys-id-sso/pat-authentication-guide) - [Ansys console](https://id.ansys.com/) - [Ansys ID Portal user management for administrators](https://developer.ansys.com/docs/ansys-id-portal) - [Ansys ID Portal membership sync (API usage reference)](https://developer.ansys.com/docs/ansys-id-portal-membership-sync-setup-and-usage/index.md) - [Ansys ID API (Swagger)](https://iam.ansys.com/swagger/index.html?urls.primaryName=AnsysId) --- # Apollo + Lutril: setup guide > Lutril connects to Apollo with a master API key so it can read your users and manage access. Generate the key from Apollo's API settings and paste it into Lutril. Source: https://www.lutril.com/integrations/apollo Category: Sales & CRM Auth: api_key Last verified: 2026-06-17 --- ## Setup 1. In Apollo, open Settings → Integrations → API. 2. Click Connect beside Apollo API, then open API Keys → Create new key. 3. Enter a name and description, then toggle ‘Set as master key’ so the key can list users. 4. Click Create API key and copy the generated key. 5. In Lutril, connect Apollo and paste the key into the ‘Master API Key’ field. ## Access requested - Master API key (access to all endpoints, including Get a List of Users) ## References - [Apollo documentation](https://docs.apollo.io/docs/create-api-key) - [Apollo console](https://app.apollo.io/#/settings/integrations/api) --- # Appcues + Lutril: setup guide > Lutril connects to Appcues with an API key and secret so it can read and manage your account. You also provide your Account ID. Source: https://www.lutril.com/integrations/appcues Category: Product Auth: api_key Last verified: 2026-06-17 --- ## Setup 1. [object Object] 2. Click Create new key, give it a name, choose the access level, and copy both the API Key and the Secret (the Secret is shown only once). 3. Find your Account ID on your Studio account page. 4. In Lutril, connect Appcues, paste the token or key plus secret, and enter the Account ID. Optionally set the base URL. ## Access requested - Public API access at the level you select when creating the key ## References - [Appcues documentation](https://docs.appcues.com/dev-api-data/appcues-public-api) - [Appcues console](https://studio.appcues.com/settings/keys) - [Appcues public API reference](https://api.appcues.com/v2/docs) --- # Asana + Lutril: setup guide > Lutril connects to Asana with a personal access token created in the Asana developer console. You also provide the Workspace ID Lutril should manage. Source: https://www.lutril.com/integrations/asana Category: Project management Auth: api_key Last verified: 2026-06-17 --- ## Setup 1. In Asana, open your profile photo → Settings → Apps → View developer console. 2. Under Personal access tokens, click Create new token. 3. Name the token, accept the Asana API terms, and click Create token. 4. Copy the token immediately; it is shown only once. 5. In Lutril, connect Asana, paste the token, and enter your Workspace ID. ## Access requested - Full access of the authorizing user (Asana personal access tokens are not scope-limited) ## References - [Asana documentation](https://developers.asana.com/docs/personal-access-token) - [Asana console](https://app.asana.com/0/my-apps) --- # Atlassian + Lutril: setup guide > Lutril connects to Atlassian (Jira and Confluence Cloud) with an account API token. You provide your Atlassian domain, an admin email, and the token. Source: https://www.lutril.com/integrations/atlassian Category: Developer tools Auth: api_key Last verified: 2026-06-17 --- ## Setup 1. Go to id.atlassian.com → Security → Create and manage API tokens. 2. Click Create API token, give it a label, set an expiry, and click Create. 3. Copy the token to clipboard; it cannot be recovered after you close the dialog. 4. In Lutril, connect Atlassian and enter your domain (e.g. mycompany), the admin email, and the API token. ## Access requested - Acts with the granting Atlassian account’s permissions (use an admin account) ## References - [Atlassian documentation](https://support.atlassian.com/atlassian-account/docs/manage-api-tokens-for-your-atlassian-account/) - [Atlassian console](https://id.atlassian.com/manage-profile/security/api-tokens) --- # Avoma + Lutril: setup guide > Lutril connects to Avoma with a scoped API key so it can read and manage your meetings and account data. Only org admins can create keys. Source: https://www.lutril.com/integrations/avoma Category: Sales & CRM Auth: api_key Last verified: 2026-06-17 --- ## Setup 1. Sign in to Avoma as an org admin. 2. [object Object] 3. Click Add API Key, enter a descriptive name, and select a scope. 4. Click Create, then copy the full key string (CLIENT_KEY:CLIENT_SECRET) and store it securely. 5. In Lutril, connect Avoma and paste the API key. ## Access requested - Scoped API key (CLIENT_KEY:CLIENT_SECRET), with the scope you select granting Lutril access to your Avoma data ## References - [Avoma documentation](https://help.avoma.com/api-integration-for-avoma) - [Avoma API documentation](https://help.avoma.com/api-documentation) - [Avoma developer reference](https://dev.avoma.com/) --- # AWS IAM Identity Center + Lutril: setup guide > Lutril reads and manages your workforce directory through the AWS Identity Store API. You provide an IAM access key (Access Key ID and Secret Access Key), the Identity Store ID, and the Region where IAM Identity Center is enabled. SCIM is supported as an alternative. Source: https://www.lutril.com/integrations/aws Category: Identity (IDP) Auth: service_account Last verified: 2026-06-17 --- ## Setup 1. [object Object] 2. On the IAM Identity Center Settings page, copy the Identity Store ID (it starts with d-) and note the Region. Enter both in Lutril. 3. In IAM, create (or reuse) an IAM user with a policy that allows the identitystore actions on your Identity Store. 4. [object Object] 5. Alternative (SCIM): in IAM Identity Center, enable automatic provisioning to get an SCIM endpoint and access token, and enter the SCIM base URL and token in Lutril instead. ## Access requested - IAM policy allowing identitystore actions (for example identitystore:ListUsers, DescribeUser, CreateUser, UpdateUser, DeleteUser) for the Identity Store - Alternative: an SCIM endpoint base URL and access token from the Identity Center provisioning settings ## References - [AWS IAM Identity Center documentation](https://docs.aws.amazon.com/singlesignon/latest/IdentityStoreAPIReference/welcome.html) - [AWS IAM Identity Center console](https://console.aws.amazon.com/singlesignon) - [Identity Store API reference](https://docs.aws.amazon.com/singlesignon/latest/IdentityStoreAPIReference/welcome.html) - [Manage access keys for IAM users](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html) - [Automatic provisioning (SCIM)](https://docs.aws.amazon.com/singlesignon/latest/userguide/provision-automatically.html) --- # Canny + Lutril: setup guide > Lutril connects to Canny with your company’s secret API key, found in Canny settings. Source: https://www.lutril.com/integrations/canny Category: Product Auth: api_key Last verified: 2026-06-17 --- ## Setup 1. In Canny, open Settings → API (your company settings). 2. Copy your secret API key. 3. In Lutril, connect Canny and paste the key into the API Key field. 4. Keep the key on your server only; it grants access to your Canny data. ## Access requested - Secret API key with access to your Canny company data ## References - [Canny documentation](https://developers.canny.io/api-reference) - [Canny developer docs](https://developers.canny.io/) --- # Claude Console + Lutril: setup guide > Lutril connects to Claude (Anthropic) with an organization Admin API key so it can read and manage members and workspaces. Creating one requires an organization admin. Source: https://www.lutril.com/integrations/claude Category: AI Auth: api_key Last verified: 2026-06-17 --- ## Setup 1. Sign in at console.anthropic.com as an organization admin. 2. Open your username (bottom left) → Organization settings → Admin keys (or Admin Keys in the left nav). 3. Click Create Admin Key and name it. 4. Copy the Admin Key and store it securely; it is shown only once. 5. In Lutril, connect Claude and paste the key into the Admin API Key field. ## Access requested - Organization Admin API key (manages members and workspaces; org admin only) ## References - [Claude Console documentation](https://docs.anthropic.com/en/api/administration-api) - [Claude Console console](https://console.anthropic.com/settings/admin-keys) --- # Cloudflare + Lutril: setup guide > Lutril connects to Cloudflare with a scoped API token so it can list, add, and remove account members. You also provide your Account ID. Source: https://www.lutril.com/integrations/cloudflare Category: Infrastructure Auth: api_key Last verified: 2026-06-17 --- ## Setup 1. In Cloudflare, open My Profile → API Tokens → Create Token. 2. Choose Create Custom Token. 3. Add the permission Account → Memberships → Edit, and Account → Account Settings → Read. 4. Scope it to your account, continue to summary, and click Create Token. 5. Copy the token (shown only once). In Lutril, connect Cloudflare, paste the token, and enter your Account ID. ## Access requested - Account → Memberships: Edit (list, add, and remove members) - Account → Account Settings: Read (resolve roles) ## References - [Cloudflare documentation](https://developers.cloudflare.com/fundamentals/api/get-started/create-token/) - [Cloudflare console](https://dash.cloudflare.com/profile/api-tokens) - [API token permissions reference](https://developers.cloudflare.com/fundamentals/api/reference/permissions/) --- # Cursor + Lutril: setup guide > Lutril needs a Cursor Team Admin API key to list your team members and their roles. The key is created in the Cursor dashboard under Settings. Source: https://www.lutril.com/integrations/cursor Category: Developer tools Auth: api_key Last verified: 2026-07-17 --- ## Setup 1. [object Object] 2. Switch the key type to Team, click New API Key, name it, and copy the key immediately. It is shown only once. 3. In Lutril, connect Cursor and paste the key into the Admin API Key field. 4. Leave the API Base URL blank to use https://api.cursor.com, or set it only if you use a custom endpoint. ## Access requested - Team Admin API key (read access to team members) ## References - [Cursor documentation](https://cursor.com/docs/account/teams/admin-api) - [Cursor console](https://cursor.com/dashboard) - [Team Admin API reference](https://cursor.com/docs/account/teams/admin-api) --- # Datadog + Lutril: setup guide > Lutril needs both a Datadog API key and an Application key to read users and roles. Both are created under Organization Settings. EU-region accounts must also set the EU API base URL. Source: https://www.lutril.com/integrations/datadog Category: Monitoring Auth: api_key Last verified: 2026-06-17 --- ## Setup 1. In Datadog, go to Organization Settings → API Keys and click New Key. Name it and copy the API key. 2. Go to Organization Settings → Application Keys and click New Key. Name it and copy the Application key immediately (it may not be retrievable later). 3. In Lutril, connect Datadog and paste the API key and Application key into their fields. 4. If your account is on the EU site, set the API Base URL to https://api.datadoghq.eu/api/v2 in Lutril. ## Access requested - API key - Application key (requires the user_app_keys or org_app_keys_write permission) ## References - [Datadog documentation](https://docs.datadoghq.com/account_management/api-app-keys/) - [Datadog console](https://app.datadoghq.com/organization-settings/api-keys) - [Application Keys page](https://app.datadoghq.com/organization-settings/application-keys) - [EU site (api-keys)](https://app.datadoghq.eu/organization-settings/api-keys) --- # DocuSign + Lutril: setup guide > Connect DocuSign with OAuth so Lutril can read your account and manage users on your behalf. Lutril requests an authorization code grant and stores the resulting refresh token; no API key is pasted manually. Source: https://www.lutril.com/integrations/docusign Category: Productivity Auth: oauth Last verified: 2026-06-17 --- ## Setup 1. In Lutril, open the DocuSign integration and click Connect DocuSign. Lutril redirects you to the DocuSign login and consent screen. 2. Sign in with a DocuSign account that has administrator rights on the target account, so the requested scopes can be granted. 3. Review the requested access (signature, user_read, user_write) and approve. DocuSign redirects you back to Lutril. 4. Lutril picks your default DocuSign account and stores the refresh token; the connection is now active. 5. [object Object] ## Access requested - signature (send and manage envelopes via the eSignature REST API) - user_read (read user profiles in the account) - user_write (create and update users in the account) ## References - [DocuSign documentation](https://developers.docusign.com/platform/auth/authcode/) - [DocuSign console](https://admindemo.docusign.com/apps-and-keys) - [Authorization Code Grant overview](https://developers.docusign.com/platform/auth/authcode/) - [Authentication scopes reference](https://developers.docusign.com/platform/auth/reference/scopes/) --- # elba + Lutril: setup guide > Lutril connects to elba with an API key so it can read and manage your workspace data. Generate the key from your elba settings. Source: https://www.lutril.com/integrations/elba Category: Security Auth: api_key Last verified: 2026-06-17 --- ## Setup 1. Sign in to elba as an administrator. 2. [object Object] 3. Generate a new API key and copy it (store it securely, as it may be shown only once). 4. In Lutril, connect elba and paste the API key. ## Access requested - API key granting Lutril access to your elba workspace data ## References - [elba documentation](https://docs.elba.security/) - [elba settings documentation](https://docs.elba.security/category/settings) --- # Eurecia + Lutril: setup guide > Lutril connects to Eurecia with an API token to read your employee directory: names, emails, job titles, departments, direct managers, and hire and departure dates. Lutril exchanges the token for a temporary session token on every sync; it never creates or modifies anything in Eurecia. Source: https://www.lutril.com/integrations/eurecia Category: Identity (IDP) Auth: api_key Last verified: 2026-08-04 --- ## Setup 1. In Eurecia, make sure the API (Web services) feature is enabled. If the API box is not visible in your admin space, ask Eurecia support to activate it. 2. Generate a token for a dedicated user: open that person's employee file, go to the Admin tab, and create a new API token. Eurecia recommends per-user tokens; the token inherits that user's visibility, so pick an account that can see all employees. 3. Alternatively, generate a profile token: in your company file, open the Settings tab, find the API box, and generate a token tied to a user profile. 4. Copy the token and keep it safe; it is the permanent credential Lutril will use. 5. In Lutril, connect Eurecia and paste the API token. Leave the base URL empty unless Eurecia gave you a non-standard environment. ## Access requested - GET /v4/users (employee directory, job titles, departments, direct managers) - GET /v1/Auth (exchange the API token for a temporary token) ## References - [Eurecia documentation](https://help.eurecia.com/hc/fr/articles/115000666829-Acc%C3%A9der-%C3%A0-l-API-Eur%C3%A9cia-Web-Services) - [Eurecia API reference (Swagger)](https://api.eurecia.com/eurecia/fw/swagger/index.html) - [Eurecia interoperability help center](https://help.eurecia.com/hc/en-gb/categories/115000151565-Interoperability) --- # Figma + Lutril: setup guide > Lutril connects to Figma with a personal access token. Generate it from your Figma account security settings and grant it the read scopes Lutril needs to list members. Source: https://www.lutril.com/integrations/figma Category: Design Auth: api_key Last verified: 2026-06-17 --- ## Setup 1. In Figma, open the account menu (top-left of the file browser) → Settings. 2. Open the Security tab and find the ‘Personal access tokens’ section. 3. Click Generate new token, set an expiration, and select the read scopes for the data Lutril should access. 4. Click Generate token and copy it immediately; it is shown only once. 5. In Lutril, connect Figma and paste the token into the ‘API Token’ field (add your Org/Team ID if prompted). ## Access requested - current_user:read - org:read / team membership read (to list members) ## References - [Figma documentation](https://developers.figma.com/docs/rest-api/personal-access-tokens/) - [Figma console](https://www.figma.com/settings) - [Token scopes reference](https://developers.figma.com/docs/rest-api/scopes) --- # GitHub + Lutril: setup guide > GitHub connects through OAuth. You enter the organization Lutril should manage, then authorize the Lutril app, which requests read access to org membership and email so it can sync members. Source: https://www.lutril.com/integrations/github Category: Developer tools Auth: oauth Last verified: 2026-06-17 --- ## Setup 1. In Lutril, open Settings → Integrations and select GitHub. 2. Enter the GitHub organization Lutril should manage, then click Connect. 3. You are redirected to GitHub to authorize the Lutril app for that organization. 4. Review the requested scopes and click Authorize. An organization owner may need to approve org access. 5. GitHub redirects you back to Lutril and the connection is established. ## Access requested - read:org (read org and team membership) - admin:org (manage org membership) - user:email (read email addresses) ## References - [GitHub documentation](https://docs.github.com/en/apps/oauth-apps/building-oauth-apps/scopes-for-oauth-apps) - [GitHub console](https://github.com/settings/tokens) - [Authorizing OAuth apps](https://docs.github.com/en/apps/oauth-apps/using-oauth-apps/authorizing-oauth-apps) --- # GitLab + Lutril: setup guide > GitLab connects through OAuth. For self-managed instances you set the base URL first, then authorize the Lutril app, which requests api and read_user access to read your users and projects. Source: https://www.lutril.com/integrations/gitlab Category: Developer tools Auth: oauth Last verified: 2026-06-17 --- ## Setup 1. In Lutril, open Settings → Integrations and select GitLab. 2. For a self-managed instance, enter your GitLab base URL (skip for gitlab.com), then click Connect. 3. You are redirected to GitLab to authorize the Lutril app with the api and read_user scopes. 4. Click Authorize; GitLab redirects you back to Lutril and the connection is established. 5. Alternatively, paste a personal access token with the api and read_user scopes into the manual field. ## Access requested - api (read and write API access) - read_user (read the authenticated user’s profile) ## References - [GitLab documentation](https://docs.gitlab.com/user/profile/personal_access_tokens/) - [GitLab console](https://gitlab.com/-/user_settings/personal_access_tokens) - [Access token scopes reference](https://docs.gitlab.com/security/tokens/access_token_scopes/) --- # Google Cloud + Lutril: setup guide > Lutril needs one service account carrying one organization-level custom role to inventory every Google Cloud service account and key, tell you when each was last used, and let you disable the dormant ones. No stack of predefined roles: the custom role below is the complete permission list, verified by creating it. Lutril never deletes service accounts, never creates, rotates or deletes keys, and never edits IAM policies. Source: https://www.lutril.com/integrations/gcp Category: Infrastructure Auth: service_account Last verified: 2026-08-25 --- ## Setup 1. [object Object] 2. [object Object] 3. [object Object] 4. [object Object] 5. [object Object] 6. In Lutril, open Settings, then Integrations, then Google Cloud. Paste the Service Account JSON. Set the Organization ID for an organization-wide scan (recommended) or a Project ID to scan a single project. Keep the stale key threshold at 90 days unless your policy says otherwise. Turn the Impersonation lens on to list who can impersonate each service account; it costs one extra IAM read per account. 7. Open Non-Human Identities and click Refresh. The sync runs in the background and takes a few minutes on large organizations; the page reports any missing API or permission as a warning. Last used showing Unknown everywhere means Policy Analyzer is not enabled in the Lutril project or its permissions are missing. Projects marked Not synced lack the resourcemanager permissions. Disable failing with a permission error means the role lacks iam.serviceAccounts.disable. Rate limits (429) are retried automatically and previously known data is kept. ## Access requested - Inventory: iam.serviceAccounts.list, iam.serviceAccounts.get, iam.serviceAccounts.getIamPolicy, iam.serviceAccountKeys.list, resourcemanager.organizations.get, resourcemanager.folders.get, resourcemanager.folders.list, resourcemanager.projects.get, resourcemanager.projects.list, resourcemanager.projects.getIamPolicy - Organization-wide search: cloudasset.assets.searchAllResources, cloudasset.assets.searchAllIamPolicies - Dormancy (last authentication): policyanalyzer.serviceAccountLastAuthenticationActivities.query, policyanalyzer.serviceAccountKeyLastAuthenticationActivities.query, serviceusage.services.use - Remediation (optional): iam.serviceAccounts.disable, iam.serviceAccounts.enable. Without them the inventory still works and the Disable button reports a permission error. - Just-in-time grants (optional): resourcemanager.projects.setIamPolicy. Used only to add and remove one time-boxed binding per approved access request. - Last used values come from Policy Analyzer, which aggregates authentications per day (Pacific time). Google states results may not include very recent authentication events; a lag of several days is common. Google also does not track requests authenticated with bound API keys, Cloud Storage HMAC keys, or Google APIs outside Cloud (for example Workspace domain-wide delegation, as used by GAM): such accounts can show as never used while active. This is why Lutril treats no observed authentication as a warning signal, never as proof of non-use. ## References - [Google Cloud documentation](https://docs.cloud.google.com/iam/docs/creating-custom-roles) - [Google Cloud console](https://console.cloud.google.com/iam-admin/serviceaccounts) - [Service account keys](https://docs.cloud.google.com/iam/docs/keys-create-delete) - [Policy Analyzer: service account authentication activity](https://docs.cloud.google.com/policy-intelligence/docs/activity-analyzer-service-account-authentication) - [Cloud Asset Inventory search](https://docs.cloud.google.com/asset-inventory/docs/searching-resources) --- # Google Workspace + Lutril: setup guide > Lutril authenticates as a Google Cloud service account with domain-wide delegation, so it can read and manage your Workspace directory on behalf of a Workspace admin. You provide the service account JSON key and the admin email. Source: https://www.lutril.com/integrations/google Category: Identity (IDP) Auth: service_account Last verified: 2026-06-17 --- ## Setup 1. [object Object] 2. Select the new service account, open Keys, click Add key, choose Create new key, and pick JSON. Paste the entire downloaded JSON file into Lutril. 3. On the service account, open advanced settings and copy its Client ID (a numeric Unique ID used for delegation). 4. [object Object] 5. Click Add new, paste the Client ID, enter the comma delimited list of OAuth scopes shown above, then click Authorize. If an entry for this Client ID already exists, edit it to include every scope above and click Authorize again. Adding a scope to an existing entry does not take effect until it is re-authorized, and a missing admin.datatransfer scope is what silently blocks the offboarding data transfer. 6. Enter a Workspace admin email (a super admin authorized for these scopes) in Lutril so calls are made on that admin's behalf. ## Access requested - https://www.googleapis.com/auth/admin.directory.user - https://www.googleapis.com/auth/admin.directory.user.alias - https://www.googleapis.com/auth/admin.directory.user.security - https://www.googleapis.com/auth/admin.directory.group.member - https://www.googleapis.com/auth/admin.directory.group.readonly - https://www.googleapis.com/auth/admin.reports.audit.readonly - https://www.googleapis.com/auth/admin.reports.usage.readonly - https://www.googleapis.com/auth/admin.datatransfer - https://www.googleapis.com/auth/gmail.send ## References - [Google Workspace documentation](https://developers.google.com/admin-sdk/directory/v1/guides/delegation) - [Google Workspace console](https://console.cloud.google.com/iam-admin/serviceaccounts) - [Domain-wide delegation guide](https://developers.google.com/admin-sdk/directory/v1/guides/delegation) - [Control API access with domain-wide delegation](https://support.google.com/a/answer/162106) --- # Grafana + Lutril: setup guide > Lutril governs Grafana in one of two provisioning modes, and you choose it when you connect. In JIT mode your SSO creates the account at first sign-in and Lutril manages the organization role, the team memberships and the account state. In SCIM mode Lutril provisions the user through Grafana's SCIM API, which needs Grafana Enterprise or Grafana Cloud. No password is ever generated: a SCIM user is created federated with no password at all, and in JIT mode Grafana's admin create endpoint requires one, so Lutril waits for the first SSO sign-in instead of creating an account. Either way a leaver is disabled rather than deleted, so dashboards, permissions and ownership survive and the same account can be switched back on for a returning employee. Source: https://www.lutril.com/integrations/grafana Category: Monitoring Auth: service_account Last verified: 2026-08-10 --- ## Setup 1. Decide the provisioning mode. Choose jit if your users reach Grafana through SAML, OIDC or OAuth and Grafana creates their account on first sign-in. Choose scim if you run Grafana Enterprise or Grafana Cloud and want Grafana provisioned from your identity provider. Lutril never falls back from scim to jit: if SCIM turns out to be unavailable the connection is refused, so nothing silently changes which system owns the lifecycle. 2. For a service account token, go to Administration, then Users and access, then Service accounts. Click Add service account, give it a role covering the permissions listed above, then Add service account token and copy the token straight away. 3. For basic authentication on a self-hosted Grafana in jit mode, use a Grafana user holding the server administrator role. This is normally required, because the disable, enable and logout endpoints sit under global user administration. 4. In Lutril, connect Grafana and paste your Grafana URL, for example https://grafana.example.com or https://mystack.grafana.net. It must be https. 5. Set Provisioning Mode to jit or scim. In scim mode also set the SCIM Namespace: default for self-hosted Grafana, or stacks-{stackId} for Grafana Cloud. 6. Optionally set the Organization ID, for example 1. With it Lutril addresses that organization explicitly; without it Lutril acts on whichever organization the credential is signed into, which is ambiguous if you run more than one. 7. If Grafana already syncs team membership from your identity provider through Team Sync or SCIM group sync, set Team Membership Owner to team_sync or scim_groups. Lutril then refuses to write team rows that the next sign-in would revert, rather than reporting a change that did not stick. Grafana itself does not allow SCIM group sync and Team Sync at the same time. 8. Name your access levels after Grafana's own organization roles, Viewer, Editor and Admin, and the mapping needs no further configuration. A request with no level sends no role at all and Grafana applies its own auto_assign_org_role, so nobody is granted a role they did not ask for. Note that in scim mode Grafana's SCIM user provisioning does not set roles: those come from Role Sync at sign-in, so configure Role Sync if you want SCIM to drive them. 9. Save. Lutril runs a capability check that discovers your Grafana version, confirms the credential, verifies the organization exists and tests whether soft disable is genuinely available. A jit connection that cannot disable accounts is refused rather than accepted with a revocation it could not perform. ## Access requested - JIT mode, self-hosted: basic authentication as a Grafana server administrator. Grafana's global user administration (disable, enable, revoke sessions) is only available to a server administrator, and an organization-scoped service account cannot be one. - JIT mode, Grafana Cloud or Enterprise with RBAC: a service account token whose role grants users:read, users:disable, users:enable, users:logout, org.users:write and teams.permissions:write. - SCIM mode: a service account token with the User administration role, plus the Teams role if you enable SCIM group sync. - Never requested and never used by a lifecycle workflow: users:delete. Permanent deletion is a separate, opt-in operation that no expiry or offboarding can reach. ## References - [Grafana documentation](https://grafana.com/docs/grafana/latest/developers/http_api/admin/) - [Grafana console](https://grafana.com/docs/grafana/latest/administration/service-accounts/) - [Service accounts and tokens](https://grafana.com/docs/grafana/latest/administration/service-accounts/) - [User HTTP API (lookup, teams, orgs)](https://grafana.com/docs/grafana/latest/developers/http_api/user/) - [SCIM provisioning (Enterprise and Cloud)](https://grafana.com/docs/grafana/latest/setup-grafana/configure-security/configure-scim-provisioning/) - [Organization roles and permissions](https://grafana.com/docs/grafana/latest/administration/roles-and-permissions/) --- # Gravitee AM + Lutril: setup guide > Lutril reads and manages your Gravitee AM organization users (the operators who administer AM) via its Management REST API. It authenticates with an account access token minted for an organization user, sent as a Bearer token. Source: https://www.lutril.com/integrations/graviteeam Category: Security Auth: service_account Last verified: 2026-07-15 --- ## Setup 1. Sign in to your Gravitee AM Console as an administrator. For automation, first create a dedicated service account: in the navigation menu click Organization, then under User Management click Users, and add a user to act as the integration identity. Give it a role with organization user permissions. 2. [object Object] 3. Copy the token immediately: Gravitee AM shows it only once and it cannot be retrieved later. 4. In Lutril, connect Gravitee AM. Set the Management API URL to your AM management base up to (but not including) /management, including any context path (for example https://am.example.com/am). A quick way to find it: open your AM console at /am/ui/constants.json and copy the baseURL value, dropping the trailing /management. Paste the token into Account Access Token, and set the Organization ID if it is not DEFAULT. ## Access requested - Organization user with permission to read organization users (to list them) - Add write and delete permission on organization users to create and remove them from Lutril ## References - [Gravitee AM documentation](https://documentation.gravitee.io/am/guides/user-management/users) - [AM API reference](https://documentation.gravitee.io/am/reference/am-api-reference) - [Configure the AM API](https://documentation.gravitee.io/am/getting-started/configuration/configure-am-api) - [User, role, and group mapping](https://documentation.gravitee.io/am/guides/identity-providers/user-and-role-mapping) --- # Gravitee APIM + Lutril: setup guide > Lutril reads and manages your Gravitee APIM organization users (the operators who administer the platform) via its Management REST API. It authenticates with a personal access token minted for an organization service account, sent as a Bearer token. Source: https://www.lutril.com/integrations/graviteeapim Category: Security Auth: service_account Last verified: 2026-07-15 --- ## Setup 1. Sign in to the Gravitee APIM Console as an administrator. Open Organization settings, then under User Management click Users, click Add user, and choose the Service Account type. Give it a service name. 2. [object Object] 3. On the service account page, scroll to the Tokens section, click Generate a personal token, name it, and generate it. Copy the token immediately: it is shown only once and cannot be retrieved later. 4. In Lutril, connect Gravitee APIM. Set the Management API URL to your APIM management base up to (but not including) /management (for example https://apim.example.com). A quick way to find it: open your APIM console constants.json and copy the baseURL value, dropping the trailing /management. Paste the token into Personal Access Token, and set the Organization ID if it is not DEFAULT. ## Access requested - Organization service account with the ORGANIZATION ADMIN role (grants read on organization users to list them) - The ADMIN role also covers creating and removing organization users from Lutril ## References - [Gravitee APIM documentation](https://documentation.gravitee.io/apim/configure-and-manage-the-platform/manage-organizations-and-environments/user-management) - [Management API reference](https://documentation.gravitee.io/apim/management-api-reference) - [Define an APIM service account](https://documentation.gravitee.io/apim/terraform/define-an-apim-service-account-for-terraform) --- # Harvest + Lutril: setup guide > Lutril connects to Harvest with a personal access token. When you create it, Harvest also shows your Account ID, which Lutril needs. Source: https://www.lutril.com/integrations/harvest Category: Time tracking Auth: api_key Last verified: 2026-06-17 --- ## Setup 1. Go to id.getharvest.com/developers. 2. Click Create new personal access token and name it. 3. Click Create personal access token; copy the token and note the Account ID shown. 4. In Lutril, connect Harvest and enter the Account ID and the access token. ## Access requested - Acts with your Harvest account’s permissions ## References - [Harvest documentation](https://help.getharvest.com/api-v2/authentication-api/authentication/authentication/) - [Harvest console](https://id.getharvest.com/developers) --- # HubSpot + Lutril: setup guide > HubSpot connects through OAuth. You authorize the Lutril app for a HubSpot account and grant scopes that let it read and provision users and teams. Granting the user scopes requires a Super Admin. Source: https://www.lutril.com/integrations/hubspot Category: Sales & CRM Auth: oauth Last verified: 2026-06-17 --- ## Setup 1. In Lutril, open Settings → Integrations and click Connect on HubSpot. 2. You are redirected to HubSpot to choose the account to connect. 3. Sign in as a Super Admin and review the requested scopes (user and team read/write). 4. Click Connect app to grant access; HubSpot redirects you back to Lutril. 5. Alternatively, paste a private app token with the same scopes into the manual field. ## Access requested - crm.objects.users.read / write - settings.users.read / write - settings.users.teams.read - crm.objects.owners.read - account-info.security.read ## References - [HubSpot documentation](https://developers.hubspot.com/docs/guides/apps/authentication/scopes) - [Create a private app (token fallback)](https://developers.hubspot.com/docs/guides/apps/private-apps/overview) --- # Intercom + Lutril: setup guide > Intercom connects through OAuth. You authorize the Lutril app for your workspace; access follows the app’s configured permissions for reading and managing teammates. An access token is supported as a manual fallback. Source: https://www.lutril.com/integrations/intercom Category: Support Auth: oauth Last verified: 2026-06-17 --- ## Setup 1. In Lutril, open Settings → Integrations and click Connect on Intercom. 2. You are redirected to Intercom to authorize the Lutril app for your workspace. 3. Review the requested access and click Authorize; Intercom redirects you back to Lutril. 4. Fallback: in the Intercom Developer Hub, open your app → Configure → Authentication and copy the Access Token. 5. Paste the token into Lutril’s manual field (add the SCIM base URL and token if you need teammate create or delete). ## Access requested - Read and write workspace teammates and admins (governed by the Lutril app’s configured permissions) ## References - [Intercom documentation](https://developers.intercom.com/docs/build-an-integration/learn-more/authentication) - [Create an access token](https://developers.intercom.com/docs/build-an-integration/learn-more/authentication/setting-up-oauth) --- # Jenkins + Lutril: setup guide > Lutril connects to Jenkins with a user API token. You provide your Jenkins base URL, the username, and the token. Source: https://www.lutril.com/integrations/jenkins Category: Developer tools Auth: api_key Last verified: 2026-06-17 --- ## Setup 1. Log in to Jenkins as the user Lutril should act as. 2. Click your name (top right) → Configure (or Security). 3. Under API Token, click Add new Token, name it, and click Generate. 4. Copy the token immediately; Jenkins shows it only once. 5. In Lutril, connect Jenkins and enter the base URL, username, and API token. ## Access requested - Acts with the token owner’s Jenkins permissions ## References - [Jenkins documentation](https://www.jenkins.io/doc/book/system-administration/authenticating-scripted-clients/) - [Remote access API](https://www.jenkins.io/doc/book/using/remote-access-api/) - [API token system](https://www.jenkins.io/blog/2018/07/02/new-api-token-system/) --- # lemlist + Lutril: setup guide > Lutril connects to lemlist with an API key generated in your lemlist team settings. Source: https://www.lutril.com/integrations/lemlist Category: Sales & CRM Auth: api_key Last verified: 2026-06-17 --- ## Setup 1. In lemlist, open Settings → Integrations and scroll to the API section. 2. Click Generate to create a new API key. 3. Copy the key immediately; you can only view it once. 4. In Lutril, connect lemlist and paste the key into the API Key field. ## Access requested - Full access to your lemlist team data ## References - [lemlist documentation](https://help.lemlist.com/en/articles/4452694-find-and-use-the-lemlist-api) - [lemlist console](https://app.lemlist.com/settings/integrations) --- # Loom + Lutril: setup guide > Lutril provisions and deprovisions Loom members over SCIM (Directory Sync). A Loom workspace admin retrieves the SCIM endpoint and bearer token from the Directory Sync setup, then pastes both into Lutril. Source: https://www.lutril.com/integrations/loom Category: Communication Auth: api_key Last verified: 2026-06-17 --- ## Setup 1. In Loom, open Workspace settings from the Library left navigation and select the Security tab (requires the Enterprise plan and admin rights). 2. Click Configure Directory Sync to launch the SCIM setup console. 3. Copy the Endpoint (SCIM base URL) and the Bearer Token shown in the setup console. 4. In Lutril, paste the Endpoint as the SCIM Base URL and the Bearer Token as the API Token, then save. ## Access requested - SCIM v2: push new users, push profile updates, push groups (unique identifier set to email) ## References - [Loom documentation](https://support.atlassian.com/loom/docs/configure-sso-and-directory-sync-scim/) - [Configure SSO and Directory Sync (SCIM)](https://support.atlassian.com/loom/docs/configure-sso-and-directory-sync-scim/) --- # Lucca + Lutril: setup guide > Lutril reads your Lucca directory using the OAuth 2.0 client credentials flow. You create an integration key in Lucca to get a Client ID and Client Secret, and supply your Lucca host. Source: https://www.lutril.com/integrations/lucca Category: Identity (IDP) Auth: api_key Last verified: 2026-06-17 --- ## Setup 1. Sign in to your Lucca account with an administrator who can manage integrations. 2. Open the integration keys admin page at the path /identity/admin/integration-keys on your Lucca host (for example https://yourcompany.ilucca.net/identity/admin/integration-keys). 3. Create a new client application: enter a technical contact email and an application name. 4. Select the OAuth scopes listed above and the business establishments the app may access, then save. 5. Copy the generated Client ID and Client Secret (the secret is shown once) and enter them in Lutril. 6. Enter your Lucca host in Lutril (for example yourcompany.ilucca.net). ## Access requested - employees.readonly - job-positions.readonly - departments.readonly - legal-entities.readonly ## References - [Lucca documentation](https://developers.luccasoftware.com/documentation/using-api/authentication) - [Authentication guide](https://developers.luccasoftware.com/documentation/using-api/authentication) - [Generating an API key](https://support.luccasoftware.com/s/article/generating-an-api-key?language=en_US) --- # Microsoft Entra ID + Lutril: setup guide > Lutril connects to Microsoft Entra ID (Azure AD) as a registered app using the OAuth 2.0 client credentials flow. You provide the Tenant ID, Client ID, and a Client Secret, and grant Microsoft Graph application permissions. Source: https://www.lutril.com/integrations/azure Category: Identity (IDP) Auth: service_account Last verified: 2026-06-17 --- ## Setup 1. [object Object] 2. On the app Overview page, copy the Application (client) ID and the Directory (tenant) ID into Lutril. 3. Open Certificates and secrets, click New client secret, set an expiry, then copy the secret Value (shown only once) into Lutril. 4. Open API permissions, click Add a permission, choose Microsoft Graph, then Application permissions, and add the permissions listed above. 5. Click Grant admin consent for your tenant and confirm that each permission shows Granted under Status. ## Access requested - Microsoft Graph: User.Read.All (application) - Microsoft Graph: Directory.Read.All (application) - Microsoft Graph: AuditLog.Read.All (application) - Microsoft Graph: User.ReadWrite.All (application, required to create or update users) ## References - [Microsoft Entra ID documentation](https://learn.microsoft.com/en-us/entra/identity-platform/quickstart-register-app) - [Microsoft Entra ID console](https://entra.microsoft.com/#view/Microsoft_AAD_RegisteredApps/ApplicationsListBlade) - [Register an application](https://learn.microsoft.com/en-us/entra/identity-platform/quickstart-register-app) - [Get access without a user (client credentials)](https://learn.microsoft.com/en-us/graph/auth-v2-service) --- # Microsoft Teams + Lutril: setup guide > Connect Microsoft Teams through Microsoft Entra admin consent so Lutril can read directory users and send proactive messages via Microsoft Graph. No secret is pasted manually; a Microsoft 365 administrator grants tenant-wide consent. Source: https://www.lutril.com/integrations/teams Category: Communication Auth: oauth Last verified: 2026-06-17 --- ## Setup 1. In Lutril, open the Microsoft Teams integration and click Connect Microsoft Teams. 2. Lutril redirects you to the Microsoft Entra admin consent screen at login.microsoftonline.com. 3. Sign in as a Microsoft 365 (Entra) administrator who can grant tenant-wide consent. 4. Review the requested Microsoft Graph permissions (User.Read.All, TeamsAppInstallation.ReadWriteSelfForUser.All, offline_access) and accept. 5. Microsoft redirects you back to Lutril and the Teams connection becomes active for your tenant. ## Access requested - https://graph.microsoft.com/User.Read.All (read the full profile of all users in the directory) - https://graph.microsoft.com/TeamsAppInstallation.ReadWriteSelfForUser.All (install and manage the Lutril Teams app for users so they can be messaged) - offline_access (obtain a refresh token to keep the connection active) ## References - [Microsoft Teams documentation](https://learn.microsoft.com/en-us/graph/permissions-reference) - [Microsoft Graph permissions reference](https://learn.microsoft.com/en-us/graph/permissions-reference) - [Overview of Microsoft Graph permissions](https://learn.microsoft.com/en-us/graph/permissions-overview) --- # Mintlify + Lutril: setup guide > Lutril connects to Mintlify through its SCIM directory, which is backed by Stytch. It uses the connection Base URL and Bearer Token to list, provision, and deprovision your Mintlify organization members. Source: https://www.lutril.com/integrations/mintlify Category: Developer tools Auth: api_key Last verified: 2026-07-16 --- ## Setup 1. SCIM and SSO are Enterprise features, so first confirm your Mintlify organization is on an Enterprise plan. 2. [object Object] 3. Enable SCIM provisioning for the organization. Mintlify generates a SCIM connection through Stytch and shows a connector Base URL (it looks like https://api.stytch.com/v1/b2b/scim/) and a Bearer Token. 4. Copy the SCIM Base URL and the Bearer Token. The token is shown once, so store it safely. 5. In Lutril, connect Mintlify and paste the SCIM Base URL and the Bearer Token into their fields. ## Access requested - SCIM 2.0 /Users: read, create, and deactivate organization members ## References - [Mintlify documentation](https://www.mintlify.com/docs/dashboard/sso) - [Mintlify console](https://app.mintlify.com/settings/organization/sso) - [Mintlify for Enterprise](https://www.mintlify.com/enterprise) - [Single sign-on (SSO) guide](https://www.mintlify.com/docs/dashboard/sso) --- # Mixpanel + Lutril: setup guide > Lutril provisions and deprovisions Mixpanel users over SCIM. You generate a SCIM token in your Mixpanel Organization Settings and paste it into Lutril; the SCIM base URL is optional. Source: https://www.lutril.com/integrations/mixpanel Category: Analytics Auth: api_key Last verified: 2026-06-17 --- ## Setup 1. [object Object] 2. Open the Access Security tab, then the SCIM menu. Generating SCIM tokens requires Organization Owner or Admin and an Enterprise plan. 3. Generate the SCIM token and copy it immediately (Mixpanel shows it only once). 4. In Lutril, paste the token as the SCIM Token. Optionally set the SCIM Base URL to https://mixpanel.com/api/app/scim/v2, then save. ## Access requested - SCIM v2: create, update, and deactivate org users (applies only to verified claimed email domains) ## References - [Mixpanel documentation](https://docs.mixpanel.com/docs/access-security/single-sign-on) - [Mixpanel console](https://mixpanel.com/settings/org) - [Single Sign-On and SCIM](https://docs.mixpanel.com/docs/access-security/single-sign-on) --- # Monday.com + Lutril: setup guide > Lutril connects to monday.com through the GraphQL API (api.monday.com/v2) with a personal API token: it lists members, guests, and viewers, invites users for approved access requests (monday.com emails the invitation itself), and deactivates accounts on offboarding. Source: https://www.lutril.com/integrations/monday Category: Project management Auth: api_key Last verified: 2026-08-04 --- ## Setup 1. Sign in to monday.com as an account admin: inviting and deactivating users are admin-only API operations, and a personal token carries its owner's permissions. 2. [object Object] 3. Copy the token. Admins can also find an account-level token under Administration, then Connections, then the API tab. 4. In Lutril, open the Monday.com integration and paste the API token. The API version defaults to 2026-04 and the endpoint to https://api.monday.com/v2; both can be overridden if needed. ## Access requested - users query: list account users, their role, guest status, and last activity - invite_users mutation: invite users on approved requests (admins only) - deactivate_users mutation: deactivate users on offboarding (admins only) ## References - [Monday.com documentation](https://developer.monday.com/api-reference/reference/users) - [Users API reference (queries and mutations)](https://developer.monday.com/api-reference/reference/users) - [Authentication and tokens](https://developer.monday.com/api-reference/docs/authentication) --- # Netlify + Lutril: setup guide > Lutril connects to Netlify with a personal access token. You also provide the account slug Lutril should manage. Source: https://www.lutril.com/integrations/netlify Category: Infrastructure Auth: api_key Last verified: 2026-06-17 --- ## Setup 1. In Netlify, go to User settings → Applications → Personal access tokens. 2. Click New access token, enter a descriptive name, and set an expiration. 3. Click Generate token and copy it; you cannot view it again after leaving the page. 4. In Lutril, connect Netlify, paste the token, and enter your account slug. ## Access requested - Acts with your Netlify account’s permissions (enable SAML team access if your team uses SSO) ## References - [Netlify documentation](https://docs.netlify.com/api-and-cli-guides/api-guides/get-started-with-api/) - [Netlify console](https://app.netlify.com/user/applications#personal-access-tokens) --- # New Relic + Lutril: setup guide > Lutril needs a New Relic User API key to list users through NerdGraph, compare them against your directory, and (optionally) create or remove users. The key must be a User key, not a license or ingest key. Source: https://www.lutril.com/integrations/newrelic Category: Monitoring Auth: api_key Last verified: 2026-07-10 --- ## Setup 1. [object Object] 2. Click Create a key, choose User for the key type, give it a name, and click Save. 3. Copy the full key immediately. Only the first characters are shown afterward. 4. In Lutril, connect New Relic and paste the User API key. 5. Set the Region to eu if your New Relic account is in the EU data center, otherwise leave it as us. A US key only works on the US endpoint and vice versa. ## Access requested - User key (not a license or ingest key) - To create, update, or remove users the key owner needs the Authentication Domain Manager role ## References - [New Relic documentation](https://docs.newrelic.com/docs/apis/intro-apis/new-relic-api-keys/) - [New Relic console](https://one.newrelic.com/api-keys) - [Manage users with NerdGraph](https://docs.newrelic.com/docs/apis/nerdgraph/examples/nerdgraph-manage-users/) - [EU vs US data center](https://docs.newrelic.com/docs/accounts/accounts-billing/account-setup/choose-your-data-center/) --- # Notion + Lutril: setup guide > Notion connects through OAuth at the workspace level. After you authorize the Lutril app, you choose which pages and databases it can access; Notion never grants blanket access. Source: https://www.lutril.com/integrations/notion Category: Productivity Auth: oauth Last verified: 2026-06-17 --- ## Setup 1. In Lutril, open Settings → Integrations and click Connect on Notion. 2. You are redirected to Notion to authorize the Lutril connection for your workspace. 3. Select the pages and databases the connection should access, then click Allow access. 4. Notion redirects you back to Lutril and the connection is established. 5. To share more pages later, open a page’s ••• menu → Connections → add the Lutril connection. ## Access requested - Workspace-level access, limited to the pages and databases you explicitly share with the connection ## References - [Notion documentation](https://www.notion.com/help/create-integrations-with-the-notion-api) - [Notion console](https://www.notion.so/my-integrations) - [Add and manage connections](https://www.notion.com/help/add-and-manage-connections-with-the-api) --- # Odoo + Lutril: setup guide > Lutril connects to Odoo through the External JSON-2 API with a bearer API key: it lists internal and portal users, creates accounts for approved access requests (Odoo emails the invitation itself), and archives accounts on offboarding. Source: https://www.lutril.com/integrations/odoo Category: ERP Auth: api_key Last verified: 2026-08-04 --- ## Setup 1. Sign in to Odoo as a user with Settings (administration) access. A dedicated service account is recommended so the key survives employee offboarding. 2. Open your avatar menu, then Preferences, then the Account Security tab, and click New API Key. 3. Enter a description (for example Lutril) and a duration, confirm your password, then copy the key: Odoo shows it only once. 4. In Lutril, open the Odoo integration and paste your base URL (for example https://mycompany.odoo.com), the database name if your server hosts several, and the API key. 5. Note: the external API requires an Odoo Custom pricing plan and the JSON-2 endpoint requires Odoo 19 or newer. ## Access requested - res.users: search_read (list users and their status) - res.users: create (provision users on approved requests) - res.users: write (archive users on offboarding, never deleted) ## References - [Odoo documentation](https://www.odoo.com/documentation/19.0/developer/reference/external_api.html) - [External JSON-2 API reference](https://www.odoo.com/documentation/19.0/developer/reference/external_api.html) - [Odoo pricing (external API requires the Custom plan)](https://www.odoo.com/pricing) --- # OpenAI + Lutril: setup guide > Lutril connects to OpenAI with an organization Admin API key so it can read and manage users and projects. Only an Organization Owner can create one. Source: https://www.lutril.com/integrations/openai Category: AI Auth: api_key Last verified: 2026-06-17 --- ## Setup 1. As an Organization Owner, open platform.openai.com/settings/organization/admin-keys. 2. Click Create new admin key and give it a name. 3. Click Create and copy the key; it is shown only once. 4. In Lutril, connect OpenAI and paste the key into the Admin API Key field. 5. Optional: add the SCIM base URL and SCIM token if you provision users through SCIM. ## Access requested - Organization Admin API key (manages users, invites, projects, and keys; Org Owner only) ## References - [OpenAI documentation](https://platform.openai.com/docs/api-reference/administration) - [OpenAI console](https://platform.openai.com/settings/organization/admin-keys) --- # PayFit + Lutril: setup guide > Lutril connects to PayFit with a Partner API key to read your employee directory (collaborators and their job titles). You generate the key in PayFit's integrations hub; Lutril resolves your company automatically. Source: https://www.lutril.com/integrations/payfit Category: Identity (IDP) Auth: api_key Last verified: 2026-06-17 --- ## Setup 1. [object Object] 2. Click Create a key, give it an explicit label, and grant the collaborators:read and collaborators:contracts:read scopes (both are required; collaborators:contracts:read is needed to read job titles). 3. Copy the key immediately; PayFit shows it only once. 4. In Lutril, connect PayFit and paste the API key. Your company is detected automatically from the key. ## Access requested - collaborators:read (read general collaborator information) - collaborators:contracts:read (read job titles) ## References - [PayFit documentation](https://developers.payfit.io/docs/authentication-via-api-key) - [PayFit console](https://app.payfit.com/integrations/hub/api) - [Scopes for partners](https://developers.payfit.io/docs/scopes-for-partners) - [Start with the PayFit API](https://developers.payfit.io/docs/start-with-payfit-api) --- # Probo + Lutril: setup guide > Lutril connects to Probo with a bearer API token, your organization ID, and your instance base URL so it can read and manage compliance data. Source: https://www.lutril.com/integrations/probo Category: Security Auth: api_key Last verified: 2026-06-17 --- ## Setup 1. Sign in to your Probo instance as an administrator. 2. [object Object] 3. Generate an API token and copy it (store it securely as a bearer token). 4. Note your instance base URL and your organization ID (the org_ identifier). 5. In Lutril, connect Probo, then enter the base URL, the organization ID, and the API token. ## Access requested - Bearer API token sent in the Authorization header, with the organization ID passed per request ## References - [Probo documentation](https://www.probo.com/docs/api/mcp/overview) - [Probo documentation](https://www.probo.com/docs) --- # Productboard + Lutril: setup guide > Lutril connects to Productboard with a Public API access token so it can read and manage your workspace. Source: https://www.lutril.com/integrations/productboard Category: Product Auth: api_key Last verified: 2026-06-17 --- ## Setup 1. Sign in to Productboard as a Maker with Admin Access. 2. Open Workspace Settings, Integrations, Public API, Access Token. 3. Click the plus button to generate a new access token and copy it. 4. In Lutril, connect Productboard and paste the API key. ## Access requested - Public API access (requires a Maker with Admin Access to create the token) ## References - [Productboard documentation](https://developer.productboard.com/) - [Productboard public API reference](https://developer.productboard.com/) --- # Redmine + Lutril: setup guide > Lutril connects to your self-hosted Redmine through OAuth: you enter your Redmine base URL, then authorize Lutril from inside the app. A personal REST API key is supported as a manual fallback. Source: https://www.lutril.com/integrations/redmine Category: Project management Auth: oauth Last verified: 2026-06-17 --- ## Setup 1. Enter your Redmine base URL in Lutril (for example https://redmine.yourcompany.com). 2. Click Connect Redmine in Lutril and complete the OAuth authorize prompt on your Redmine instance. 3. Fallback: a Redmine administrator enables the REST API under Administration, then Settings, then the API tab, by checking Enable REST API and saving. 4. Fallback: each user opens My account at /my/account and copies the API access key from the right-hand pane. 5. Fallback: paste that API key into Lutril instead of using OAuth. ## References - [Redmine documentation](https://www.redmine.org/projects/redmine/wiki/Rest_api) - [Redmine REST API reference](https://www.redmine.org/projects/redmine/wiki/Rest_api) - [OAuth2 provider tracking issue](https://www.redmine.org/issues/24808) --- # Scaleway + Lutril: setup guide > Lutril connects to Scaleway with an IAM API key (secret key) scoped to your Organization, plus your Organization ID, so it can read and manage IAM members. Source: https://www.lutril.com/integrations/scaleway Category: Infrastructure Auth: api_key Last verified: 2026-06-17 --- ## Setup 1. [object Object] 2. Click + Generate API key and choose the bearer (yourself or an IAM application). 3. Set an optional description and expiration, then generate the key. 4. Copy the secret key (it is shown only once). Find your Organization ID on the Organization Settings page. 5. In Lutril, connect Scaleway, then enter the Organization ID and the secret key. ## Access requested - IAM API key (access key and secret key) scoped to one Organization, bearing the permissions of its IAM user or application ## References - [Scaleway documentation](https://www.scaleway.com/en/docs/iam/how-to/create-api-keys/) - [Scaleway console](https://console.scaleway.com/iam/api-keys) - [Manage API keys](https://www.scaleway.com/en/docs/iam/how-to/manage-api-keys/) - [IAM API reference](https://www.scaleway.com/en/developers/api/iam) --- # Slack + Lutril: setup guide > Slack connects through OAuth, so there is no API key to paste. When you click Connect, Slack asks you to approve the scopes Lutril requests for reading members and posting access notifications. Source: https://www.lutril.com/integrations/slack Category: Communication Auth: oauth Last verified: 2026-06-17 --- ## Setup 1. In Lutril, open Settings → Integrations and click Connect on Slack. 2. You are redirected to Slack to authorize the Lutril app for your workspace. 3. Review the requested bot and user scopes, then click Allow. 4. Slack redirects you back to Lutril and the connection is established automatically. ## Access requested - Bot: users:read, users:read.email, team:read, app_mentions:read, channels:history, chat:write, im:history, im:write - User: admin, channels:read, channels:history, chat:write, users:read, users:read.email ## References - [Slack documentation](https://docs.slack.dev/authentication/installing-with-oauth/) - [OAuth scopes reference](https://docs.slack.dev/reference/scopes) --- # Smallstep + Lutril: setup guide > Lutril connects to Smallstep with a bearer API token so it can read and manage your devices and accounts. You can optionally set the API base URL. Source: https://www.lutril.com/integrations/smallstep Category: Infrastructure Auth: api_key Last verified: 2026-06-17 --- ## Setup 1. [object Object] 2. Open the Settings section in the bottom left menu. 3. Click Add a Token, give it a descriptive title, and choose the validity period and scopes. 4. Copy the API Token Secret (it is shown only once). In Lutril, connect Smallstep, paste the token, and optionally set the API base URL. ## Access requested - Bearer API token with the scopes you select at creation, so Lutril can read and manage account data ## References - [Smallstep documentation](https://support.smallstep.com/getting-started-with-the-customer-api) - [Platform API reference](https://smallstep.com/docs/platform/smallstep-api/) --- # Snowflake + Lutril: setup guide > Lutril needs your account identifier and a programmatic access token to list, create, disable and grant roles to Snowflake users through the REST API. Every statement below runs in a Snowsight worksheet and takes about five minutes end to end. Snowflake scopes roles and users per account, so a token only ever reaches the one account it was made in: run this once per environment you want governed. Source: https://www.lutril.com/integrations/snowflake Category: Infrastructure Auth: api_key Last verified: 2026-08-11 --- ## Setup 1. [object Object] 2. [object Object] 3. [object Object] 4. [object Object] 5. [object Object] 6. [object Object] 7. [object Object] 8. In Lutril, connect Snowflake and paste the account identifier and the token. Set a calendar reminder to rotate before the expiry you chose: when a token lapses, listing and provisioning stop and any access review covering this account goes stale. ## Access requested - SECURITYADMIN, granted to the service user and set as the token's ROLE_RESTRICTION - A network policy covering the service user (Snowflake requires one before a service token works) - REST API v2: GET /users, GET /roles, POST /users, PUT /users/{name}, POST /users/{name}/grants ## References - [Snowflake documentation](https://docs.snowflake.com/en/user-guide/programmatic-access-tokens) - [Snowflake console](https://app.snowflake.com) - [Account identifiers](https://docs.snowflake.com/en/user-guide/admin-account-identifier) - [CREATE USER reference](https://docs.snowflake.com/en/sql-reference/sql/create-user) - [Network policies](https://docs.snowflake.com/en/user-guide/network-policies) - [REST API user reference](https://docs.snowflake.com/en/developer-guide/snowflake-rest-api/reference/user) - [REST API authentication](https://docs.snowflake.com/en/developer-guide/snowflake-rest-api/authentication) --- # Sonatype Nexus Repository + Lutril: setup guide > Lutril connects to your self-hosted Nexus Repository with a user token used as Basic auth. You provide the base URL, the token name code as the username, and the token passcode as the password. Source: https://www.lutril.com/integrations/nexus Category: Developer tools Auth: api_key Last verified: 2026-06-17 --- ## Setup 1. In Nexus Repository, select your username at the top right of the toolbar to manage your account. 2. Open the User Token tab in the left navigation, then click Access User Token. 3. Re-enter your credentials and Authenticate; copy the token name code (username) and token passcode (password). 4. In Lutril, connect Nexus, enter your Nexus base URL, then the token name code as the username and the passcode as the password. ## Access requested - The permissions of the Nexus user the token belongs to (an administrator role is needed to manage users) ## References - [Sonatype Nexus Repository documentation](https://help.sonatype.com/en/user-tokens.html) - [User tokens API reference](https://help.sonatype.com/en/user-tokens-api.html) --- # Sybill + Lutril: setup guide > Lutril connects to Sybill with an API token plus the API base URL so it can read and provision the people in your Sybill workspace. Source: https://www.lutril.com/integrations/sybill Category: Sales & CRM Auth: api_key Last verified: 2026-06-17 --- ## Setup 1. [object Object] 2. Generate a new API token and copy it immediately; Sybill shows the value only once. 3. Note the API base URL (the production REST host is https://api.sybill.ai). 4. In Lutril, connect Sybill, paste the API token, and enter the base URL. ## Access requested - Workspace access (read and manage members) tied to the token's role ## References - [Sybill documentation](https://api.sybill.ai/docs/introduction.html) - [Sybill console](https://app.sybill.ai) - [Sybill help center](https://help.sybill.ai/en/) --- # Teamtailor + Lutril: setup guide > Lutril connects to Teamtailor with an API key so it can read and manage users and recruitment data. You can optionally set a base URL for your region. Source: https://www.lutril.com/integrations/teamtailor Category: Recruiting Auth: api_key Last verified: 2026-06-17 --- ## Setup 1. Sign in to Teamtailor as a user with Company Admin access. 2. [object Object] 3. Click + New API Key at the top right. 4. Choose the key type: pick Admin permissions with Read/Write for full management. 5. Copy the API key (it cannot be edited later, only deleted). In Lutril, connect Teamtailor, paste the key, and optionally set the base URL. ## Access requested - Admin (full account access) with Read/Write, so Lutril can list and manage users and account data ## References - [Teamtailor documentation](https://support.teamtailor.com/en/articles/5963369-use-our-teamtailor-api) - [Teamtailor API documentation](https://docs.teamtailor.com/) --- # TeamViewer + Lutril: setup guide > Lutril needs a TeamViewer script token with User management permissions. It lists your company members with their roles, two-factor status, and last access date, provisions new users, and deactivates accounts when people leave. Source: https://www.lutril.com/integrations/teamviewer Category: Security Auth: api_key Last verified: 2026-08-04 --- ## Setup 1. [object Object] 2. Click your username in the upper right corner, then select Edit profile, then Apps. 3. Click Create script token, name it (for example "Lutril"), and under User management select view, create, and edit users. Also allow viewing user roles if available on your plan. 4. Click Create and copy the token; TeamViewer shows it only once (tokens cannot be edited later, only deleted and recreated). 5. In Lutril, open Integrations, choose TeamViewer, and paste the token as the Script Token. ## Access requested - User management: View, create, and edit users (directory sync, joiner provisioning, leaver deactivation) - User role management: View user roles (fills the role picker when granting access; optional) ## References - [TeamViewer documentation](https://www.teamviewer.com/en/global/support/knowledge-base/teamviewer-remote/for-developers/use-the-teamviewer-api/) - [TeamViewer console](https://login.teamviewer.com/nav/api) - [TeamViewer Web API reference (User Management)](https://webapi.teamviewer.com/api/v1/docs/index) - [Build a TeamViewer integration](https://www.teamviewer.com/en/global/support/knowledge-base/teamviewer-remote/for-developers/build-a-teamviewer-integration/) --- # TrackingTime + Lutril: setup guide > Lutril connects to TrackingTime with an App Password used as the access token, plus a client ID that identifies the application. With these, Lutril can read and manage your account data. Source: https://www.lutril.com/integrations/trackingtime Category: Time tracking Auth: api_key Last verified: 2026-06-17 --- ## Setup 1. Sign in to TrackingTime. 2. [object Object] 3. Create a new App Password and copy the generated value (it is your access token). 4. In Lutril, connect TrackingTime, paste the App Password as the access token, and enter the client ID that names your application. ## Access requested - App Password used as the access token over Basic Auth, granting Lutril access to your TrackingTime account data ## References - [TrackingTime documentation](https://support.trackingtime.co/en/articles/6329119-apps-integrations) - [Public API documentation](https://developers.trackingtime.co/) - [API guidelines](https://api.trackingtime.co/doc/index.html) --- # Userflow + Lutril: setup guide > Lutril connects to Userflow with a personal API key so it can manage members and invites in your account. You also provide your Account ID. Source: https://www.lutril.com/integrations/userflow Category: Product Auth: api_key Last verified: 2026-06-17 --- ## Setup 1. [object Object] 2. Create a new personal API key and copy it; keep it secret. 3. Find the Account ID for the account you want Lutril to manage (it appears in the API account endpoints, for example /accounts/{account_id}). 4. In Lutril, connect Userflow, paste the personal access token, and enter the Account ID. ## Access requested - Access to the accounts you belong to, based on your Userflow role (Owner is required to add team members) ## References - [Userflow documentation](https://docs.userflow.com/docs/api) - [Userflow console](https://app.userflow.com) - [Userflow Accounts API reference](https://docs.userflow.com/docs/dev/api-reference) - [Managing teams in Userflow](https://docs.userflow.com/docs/guides/team) --- # Zapier + Lutril: setup guide > Lutril provisions and deprovisions Zapier members over SCIM. You enable user provisioning in Zapier, copy the generated bearer token, and paste it (with the SCIM base URL) into Lutril. Source: https://www.lutril.com/integrations/zapier Category: Automation Auth: api_key Last verified: 2026-06-17 --- ## Setup 1. [object Object] 2. Click Enable to turn on user provisioning. Zapier generates an authentication token (user provisioning requires a Zapier Enterprise plan). 3. Copy the generated token. You can regenerate it from the same page if it is ever lost or compromised. 4. In Lutril, paste https://zapier.com/scim/v3 as the SCIM Base URL and the token as the API Token, then save. ## Access requested - SCIM v2: push new users, push profile updates, deactivate and reactivate users ## References - [Zapier documentation](https://help.zapier.com/hc/en-us/articles/8496291497741-Provision-user-accounts-with-SCIM) - [Zapier console](https://zapier.com/app/settings/user-provisioning) - [Provision user accounts with SCIM](https://help.zapier.com/hc/en-us/articles/8496291497741-Provision-user-accounts-with-SCIM) --- # Zendesk + Lutril: setup guide > Zendesk connects through OAuth with read and write access. You enter your Zendesk subdomain, then authorize the Lutril app. An API token is supported as a manual fallback. Source: https://www.lutril.com/integrations/zendesk Category: Support Auth: oauth Last verified: 2026-06-17 --- ## Setup 1. In Lutril, open Settings → Integrations, select Zendesk, and enter your subdomain (the part before .zendesk.com). 2. Click Connect; you are redirected to Zendesk to authorize the Lutril app with read and write access. 3. Click Allow; Zendesk redirects you back to Lutril and the connection is established. 4. Fallback: in Zendesk Admin Center → Apps and integrations → APIs → Zendesk API, enable Token access and Add API token. 5. Then paste your admin email and the API token into Lutril’s manual fields. ## Access requested - read (read users and organizations) - write (provision and update users) ## References - [Zendesk documentation](https://support.zendesk.com/hc/en-us/articles/4408889192858-Managing-API-token-access-to-the-Zendesk-API) - [Managing OAuth token access](https://support.zendesk.com/hc/en-us/articles/8889508417946-Managing-OAuth-token-access-to-the-API) --- # Version française --- # Empêchez les données personnelles de fuir dans les prompts. > Inspectez chaque prompt, détectez les données personnelles et les secrets, et masquez-les avant qu’ils n’atteignent le modèle, avec la trace complète de ce qui a été intercepté. Source: https://www.lutril.com/fr/ai-governance/dlp --- Lutril inspecte chaque prompt à destination d’un LLM, détecte les données personnelles, les secrets et les clés, et les masque avant même que le modèle ne les voie, sans bloquer le travail. - Détection des données et secrets - Masquage à la volée - Politique par modèle - **Détecter** Données personnelles, secrets, clés d’API et motifs sur mesure. - **Masquer à la volée** Remplacez les passages sensibles avant que le modèle ne les reçoive. - **Politique par modèle** Des règles différentes pour les modèles publics et pour vos points d’accès privés. - **Audit inaltérable** Chaque masquage est enregistré, rien n’est conservé en clair. ## Un point de contrôle sur la route de chaque modèle. La DLP s’exécute sur la couche qui gouverne déjà vos agents, elle s’applique donc aussi bien au chat qu’aux copilotes et aux appels d’outils MCP. - **Une détection adaptée à vos données** Détecteurs intégrés pour les e-mails, les cartes bancaires, les numéros d’identité et les secrets, plus vos propres motifs par expression régulière ou mot-clé. - **Masquer, anonymiser ou bloquer** À choisir par politique : masquer le passage, le remplacer par un jeton sur lequel le modèle peut raisonner, ou refuser la requête. - **Valable sur tous les modèles** Une seule politique couvre ChatGPT, Claude, Gemini et vos modèles auto-hébergés, appliquée de la même façon partout. - **Une conformité démontrable** Un journal inaltérable de ce qui a été détecté et masqué fournit la preuve aux auditeurs sans exposer les données d’origine. --- # Voyez tous les outils et agents IA que vos équipes utilisent vraiment. > Une extension Chrome, l’analyse des e-mails, les journaux de connexion et l’analyse de code font remonter chaque outil et agent IA non validé dans votre entreprise, avant qu’il ne devienne un incident. Source: https://www.lutril.com/fr/ai-governance/shadow-ai --- Une extension Chrome, l’analyse des boîtes mail, les journaux de connexion et l’analyse de code font remonter tous les outils et agents IA que vos équipes font tourner, validés ou non, pour que rien ne manipule vos données dans l’ombre. - Extension navigateur - Signaux de connexion IdP - Découverte des agents - **Extension Chrome** Repère les outils IA au moment de l’usage, même quand ils contournent le SSO. - **Analyse des e-mails** Parcourt les messageries Google et Microsoft à la recherche des e-mails d’inscription et de facturation des éditeurs d’IA. - **OAuth et SSO** Récupère les autorisations et les journaux de connexion directement depuis votre fournisseur d’identité. - **Score de risque** Classe chaque outil selon ses utilisateurs, l’exposition des données et sa politique d’entraînement. ## D’où vient le signal. Trois sources indépendantes. Chacune attrape des outils que les autres manquent, la photo reste donc complète même quand les équipes contournent l’IT. - **Extension Chrome** Déployée par votre MDM. Signale les domaines IA que les collaborateurs ouvrent dans le navigateur, y compris les outils qui ne passent jamais par le SSO. - **Analyse des e-mails** Parcourt les messageries Google Workspace et Microsoft 365 à la recherche des confirmations d’inscription, reçus et avis de période d’essai qu’envoient les éditeurs d’IA. - **OAuth et SSO** Lit les autorisations OAuth et les journaux de connexion SSO pour montrer quelles applications d’IA détiennent un accès permanent via un compte Google ou Microsoft d’entreprise. - **Analyse de code** Trouve les agents qui vivent dans vos dépôts GitHub et GitLab, branchés sur des clés d’API que personne ne suit. --- # Une seule source de vérité pour chaque agent. > Enregistrez chaque agent IA avec un propriétaire, un modèle et des scopes. Renouvelez les identifiants, passez les accès en revue et retirez un agent comme vous le feriez pour un collaborateur. Source: https://www.lutril.com/fr/ai-governance/agent-registry --- Chaque agent IA dispose d’une fiche : un propriétaire, le modèle sur lequel il tourne, les scopes qu’il détient et son activité. Gouvernez vos agents avec le cycle de vie que vous appliquez déjà à vos collaborateurs. - Propriétaire et scopes - Rotation des identifiants - Retrait en un clic - **Propriétaire et scopes** Aucun agent anonyme ; chacun a un propriétaire responsable. - **Rotation des identifiants** Renouvelez ou faites expirer les clés d’un agent selon un calendrier. - **Revues d’accès** Intégrez les agents aux mêmes campagnes que les comptes humains. - **Retrait en un clic** Révoquez instantanément tout ce qu’un agent peut atteindre. ## Le cycle de vie de l’agent, de bout en bout. Un agent est une identité. Le gouverner comme un compte collaborateur comble l’écart entre ce que vos agents peuvent atteindre et ce que quiconque peut voir. 1. **Enregistrer** Intégrez un agent avec un propriétaire, son modèle et un rôle cadré, tiré de la même bibliothèque que celle de vos collaborateurs. 2. **Renouveler** Programmez la rotation des identifiants et des jetons éphémères pour qu’une clé divulguée ait un rayon d’action réduit. 3. **Passer en revue** Faites remonter les agents inactifs ou surdotés dans les revues d’accès et resserrez-les par une décision qui s’exécute. 4. **Retirer** À la fin d’un projet, mettez l’agent hors service et révoquez chacune de ses autorisations sur vos SaaS en une seule action. --- # Chaque appel d’outil passe par la politique. > Le serveur MCP de Lutril se place entre vos agents et vos SaaS. Chaque appel est confronté à une politique, autorisé ou refusé, et inscrit dans un journal d’audit inaltérable. Source: https://www.lutril.com/fr/ai-governance/mcp-proxy --- Le serveur MCP de Lutril se place entre vos agents et vos SaaS. Chaque appel d’outil est confronté à une politique, autorisé ou refusé, et inscrit dans un journal d’audit inaltérable, sur l’ensemble de vos outils. - Un seul point d’accès MCP - Politique par rôle - Audit inaltérable - **Un seul point d’accès MCP** N’importe quel SaaS. Sans attendre un support natif. - **Politique par rôle** Les mêmes rôles que pour vos collaborateurs. - **Audit inaltérable** Chaque prompt, chaque appel d’outil, chaque réponse. - **Coupe-circuit global** Mettez un agent en pause sur tous les outils, instantanément. ## Une clé d’API brute ne sait pas faire respecter cela. Confiez une clé d’API brute à un agent et plus rien ne contrôle ce qu’il atteint. Le proxy rend chaque appel inspectable, gouvernable et réversible. - **Une politique sur chaque appel** Confrontez le rôle de l’agent, le scope de l’outil, les paramètres et les limites de débit avant qu’une seule requête ne quitte votre périmètre. - **N’importe quel outil, un seul point d’accès** Exposez les actions de vos SaaS comme des outils MCP sans attendre que chaque éditeur livre un support natif. - **Audit inaltérable** Prompts, appels et réponses atterrissent dans un journal WORM : la piste de preuves que réclament les auditeurs. - **Coupe-circuit** Mettez un agent en pause, ou tous, sur chaque outil connecté dès que quelque chose cloche. ## Questions fréquentes ### Comment contrôler ce à quoi les agents IA accèdent via MCP ? Placez une passerelle entre l’agent et les serveurs d’outils. L’agent s’authentifie avec sa propre identité enregistrée, la passerelle vérifie chaque appel d’outil selon une politique (quel agent, quel outil, quels paramètres), journalise l’appel et peut mettre l’agent en pause. Le proxy MCP de Lutril est cette passerelle pour chaque outil SaaS que vous connectez. ### Qu’est-ce qu’une passerelle MCP, et pourquoi ne pas simplement donner une clé API à l’agent ? Une passerelle MCP est un proxy qui parle le Model Context Protocol avec l’agent et applique une politique à chaque appel d’outil avant de le transmettre. Une clé API accorde tout ce que la clé permet, tant qu’elle existe, sans décision par appel ni journal que vous contrôlez. Un identifiant n’est pas un contrôle. ### La politique peut-elle s’appliquer à chaque appel, et pas seulement à la connexion ? Oui. Lutril évalue chaque appel selon le rôle de l’agent, l’outil, les paramètres et les limites de débit avant qu’il ne quitte votre périmètre. Les lectures peuvent être autorisées tandis que les écritures exigent une approbation humaine dans Slack, Teams ou l’application, et la décision est journalisée avec l’appel. ### Le proxy MCP fonctionne-t-il avec des outils SaaS sans serveur MCP ? Oui. Lutril expose les actions de ses intégrations SaaS sous forme d’outils MCP via un seul point d’entrée, de sorte qu’un agent obtient un accès gouverné à un outil dont l’éditeur n’a jamais publié de serveur MCP. ### Que contient le journal d’audit ? Chaque prompt, appel d’outil et réponse, avec l’identité de l’agent, la décision de politique et l’horodatage, écrits dans un stockage WORM. C’est la piste de preuve que demandent les auditeurs, et le même journal sert aux revues d’accès des agents. --- # Just-in-Time Access: Standing Privilege Is the Breach Path > Des faiblesses d’identité ont joué un rôle déterminant dans près de 90% des incidents investigués par Unit 42 l’an dernier. L’accès juste-à-temps réduit ce qu’un identifiant fuité peut atteindre, en faisant expirer chaque attribution d’elle-même. Voici ce que disent réellement les rapports 2026, pourquoi les agents IA ont changé le calcul, et comment fonctionne le moteur de politique de Lutril. Source: https://www.lutril.com/fr/blog/just-in-time-access Published: 2026-08-07 Topic: Access Control --- ## Ce que veut vraiment dire l’accès juste-à-temps Dans la plupart des entreprises, l’essentiel des accès est **permanent**. Quelqu’un a eu besoin d’une permission une fois, un administrateur l’a accordée, et elle est restée. Personne n’a programmé son retrait, parce que le retrait n’a jamais fait partie de l’attribution. Trois ans plus tard, cette permission est toujours attachée au compte, toujours valide, et toujours invisible jusqu’à ce qu’un auditeur ou un attaquant la trouve. L’accès juste-à-temps inverse le réglage par défaut. La permission est accordée pour un motif énoncé, pour une fenêtre bornée, et elle est reprise quand la fenêtre se referme. Palo Alto Networks décrit l’état d’arrivée, les [privilèges permanents à zéro](https://www.paloaltonetworks.com/cyberpedia/zero-standing-privileges), comme « l’élimination de tous les droits d’accès permanents, pour chaque identité, humaine ou machine ». Le JIT est le mécanisme qui y mène : élever pour une tâche, pour une durée définie, puis redescendre. L’idée n’est pas neuve. Ce qui a changé, c’est que le coût de l’accès permanent est devenu mesurable, et que le nombre d’identités qui en détiennent a cessé d’être à l’échelle humaine. ## L’accès permanent, c’est là que la brèche se produit vraiment Le [rapport Verizon DBIR 2026](https://www.verizon.com/business/resources/reports/dbir/) constate un vrai basculement à la porte d’entrée : 31% des violations démarrent désormais par une vulnérabilité logicielle, détrônant pour la première fois les identifiants volés comme premier vecteur d’accès initial. On pourrait y lire une bonne nouvelle pour les équipes identité. Ce n’en est pas une. Les identifiants n’ont pas cessé de compter. Ils se sont déplacés. Comptés sur l’ensemble de la violation, et pas seulement sur la première étape, [l’abus d’identifiants apparaît encore dans 39% des violations](https://spycloud.com/blog/top-takeaways-from-the-2026-verizon-data-breach-investigations-report/), et 73% des victimes de rançongiciel avaient connu une infection par infostealer ou une fuite d’identifiants dans l’année précédant l’attaque. L’exploit fait entrer l’attaquant. Ce sont les permissions permanentes attachées à l’identité sur laquelle il atterrit qui décident jusqu’où il ira. Unit 42 mesure la même chose côté réponse à incident. Sur [plus de 750 incidents majeurs](https://www.paloaltonetworks.com/resources/research/unit-42-incident-response-report) traités entre octobre 2024 et septembre 2025, des faiblesses d’identité ont joué un rôle déterminant dans près de 90% des investigations, et 65% des accès initiaux reposaient sur des techniques fondées sur l’identité. - **~90%**: des investigations Unit 42 où une faiblesse d’identité a été déterminante - **39%**: des violations impliquant un abus d’identifiants (DBIR 2026) - **73%**: des victimes de rançongiciel avec une fuite d’identifiants antérieure Voilà l’argument honnête en faveur du JIT, et il est plus étroit que ce que le marketing prétend d’ordinaire. Limiter les accès dans le temps n’arrêtera pas un hameçonnage et ne corrigera pas une faille. Ce que cela fait, c’est réduire le rayon d’action de chaque identifiant qui finira par fuiter, parce que la plupart des permissions dont un attaquant voudrait hériter n’existent plus au moment où il arrive. ## Le nombre d’identités a cessé d’être à l’échelle humaine Il y a une seconde raison à l’urgence de 2026. Le [livre blanc de la Cloud Security Alliance sur les identités non humaines et la gouvernance de l’IA agentique](https://labs.cloudsecurityalliance.org/research/csa-whitepaper-nonhuman-identity-agentic-ai-governance-v1-cs/) le dit sans détour : comptes de service, clés d’API, jetons OAuth, certificats machine et identifiants maniés par les agents IA « dépassent désormais les utilisateurs humains dans un rapport moyen de 45 pour 1, et dans les environnements cloud-natifs ce rapport peut atteindre 144 pour 1 ». D’autres estimations de 2026 vont encore plus haut. L’écart entre elles est en soi le constat. Personne n’a de décompte fiable, parce que la plupart de ces identités ont été créées par celui qui en avait besoin, dans l’outil qui en avait besoin, sans aucun cycle de vie attaché. Le même document rapporte que **78% des organisations n’ont aucune politique documentée pour créer ou retirer des identités d’IA**, et que seulement 8% sont pleinement confiantes dans la capacité de leur IAM actuel à gérer le risque lié aux identités d’IA et non humaines. La revue manuelle ne passe pas à cette échelle. Une campagne trimestrielle qui fonctionne raisonnablement pour 400 collaborateurs ne fonctionne pas pour 18 000 jetons, et encore moins pour un agent monté un mardi pour un flux de travail et jamais éteint. Nous avons traité la version structurelle de ce problème dans [La faille de gouvernance de l’IA](/blog/the-ai-governance-gap) et [Qu’est-ce que la couche d’accès pour les agents IA ?](/blog/ai-agent-access-layer). En résumé : si un accès n’a pas d’expiration, il faut bien que quelque chose le retire, et à cette échelle ce quelque chose ne peut pas être une personne. ## Pourquoi les projets JIT s’enlisent Presque toutes les équipes sécurité adhèrent au principe. Beaucoup moins l’ont en production. Les échecs sont récurrents, et ce n’est pas une question d’adhésion. **Ce qui casse** - Une date d’expiration est notée mais rien ne l’applique. L’attribution est « temporaire » dans un tableur et permanente dans l’outil SaaS. - Chaque demande part vers un humain. Les approbateurs en reçoivent vingt par jour, cessent de les lire, et approuvent par réflexe. - Les conditions sont écrites sur des attributs que personne ne synchronise, si bien que la règle ne correspond jamais, ou correspond toujours, en silence. - Les demandes vivent dans un portail que personne n’ouvre, alors les gens contournent le système et sollicitent un administrateur directement. **Ce qui doit être vrai** - Le système qui accorde l’accès est celui qui le retire, selon un calendrier dont il est maître. - Les demandes à faible risque et bien comprises se résolvent sans humain, pour que celles qui atteignent un approbateur méritent d’être lues. - L’éditeur de politique indique quels attributs il sait réellement résoudre, et refuse de faire semblant pour les autres. - Demander et approuver se font là où le travail se fait : Slack, Teams, et l’application. ## Comment Lutril s’y prend Dans Lutril, le JIT se configure par application, sur la page **Politiques**. Chaque politique vise un public, soit les **collaborateurs**, soit les **agents IA**, et peut être limitée à un niveau d’accès précis. Une politique écrite pour un niveau donné l’emporte sur le réglage par défaut de l’application, si bien que « Admin sur Notion » et « Membre sur Notion » peuvent se comporter très différemment. Chaque public dispose de trois réglages : ce qui se passe à la demande, la durée maximale, et des conditions facultatives. | À la demande | Ce qui se passe | À utiliser pour | | --- | --- | --- | | Approbation automatique | Accordé instantanément, sans humain dans la boucle, et malgré tout limité dans le temps. | Les accès que le rôle de la personne justifie déjà, où le risque tient à la durée, pas à la décision. | | Approbation requise | Passe par le flux d’approbation, puis expire. | Les niveaux à privilèges, les systèmes de production, tout ce qu’un auditeur nommera explicitement. | | Refus | Refusé d’emblée, avec le motif consigné. | Les accès qui ne doivent jamais être libre-service, quel que soit le demandeur. | ### La durée est un plafond, pas une valeur figée La durée maximale se règle en heures sur la politique. On demande au demandeur « De combien de temps avez-vous besoin ? » et il choisit dans une échelle de 1 heure, 4 heures, 8 heures, 1 jour, 3 jours ou 7 jours, filtrée par ce que la politique autorise. La même question s’affiche en menu déroulant dans Slack, en jeu de choix dans Teams, et en liste dans l’application Lutril. Un approbateur peut raccourcir une attribution au moment de décider. Il ne peut pas l’allonger. La fenêtre effective est le plus petit des trois nombres en présence : **le maximum de la politique, ce que le demandeur a demandé, et ce que l’approbateur a accordé**. Aucun chemin dans le parcours ne produit un accès plus long que ce que la politique autorise. Le compte à rebours démarre au moment de la décision, pas au dépôt de la demande. Si un approbateur met six heures à répondre, le demandeur dispose quand même de toute sa fenêtre. ### Les conditions décident de qui saute la file C’est la fatigue d’approbation qui tue les programmes JIT : la question intéressante n’est donc pas « qui a le droit » mais « qui ne devrait pas avoir besoin d’un humain ». L’éditeur de conditions pose exactement cette question, en une phrase : **Accorder automatiquement quand**. Vous construisez une règle, puis vous répondez à une seconde question sur tous ceux qui ne correspondent pas : un approbateur décide et l’accès expire quand même, ou un approbateur décide et l’accès n’expire jamais. Les attributs résolus aujourd’hui incluent le service, l’intitulé de poste, le manager, le statut RH, l’état du MFA, interne ou externe, le statut dans l’IdP, les formations de sécurité en retard, le fait que la personne ait déjà accès à l’application, la sensibilité de l’application, et la demande elle-même : durée demandée, niveau d’accès et motif énoncé. Tout attribut qui dépend d’une source que vous n’avez pas encore connectée est affiché comme indisponible, avec la raison écrite à côté. Vous ne construisez jamais une règle sur un signal qui n’arrivera pas, et vous savez toujours quelle connexion la débloquerait. Cela paraît anodin. C’est le troisième mode d’échec ci-dessus, refermé. **Un essai à blanc avant d’appliquer** À côté de l’éditeur se trouve un panneau intitulé « Qui cela concerne-t-il ? ». Saisissez un e-mail réel et Lutril évalue la politique contre cette personne, immédiatement, en indiquant si elle est dans le périmètre, si elle serait approuvée automatiquement, et une trace règle par règle. Chaque règle revient comme satisfaite, non satisfaite, invérifiable ou non comprise. La distinction compte : « non satisfaite » signifie que la règle s’est exécutée et que la réponse est non, tandis qu’« invérifiable » signifie qu’un fait manquait, ce qui est un problème de données et non de politique. ### Les échecs se résolvent vers l’approbation, jamais vers le silence Un moteur de politique qui ne parvient pas à résoudre un fait a trois options : autoriser, refuser, ou demander à un humain. Lutril demande toujours à un humain. Une condition non satisfaite ou invérifiable se dégrade en « approbation requise », jamais en attribution silencieuse ni en refus silencieux. Une règle de refus est évaluée avant le périmètre, si bien que resserrer une politique ne peut jamais l’assouplir par accident. Au moment de la décision, les termes de la politique sont figés sur l’attribution. Modifier la politique demain ne réécrit pas ce qui a été autorisé aujourd’hui, et c’est ce qui rend le relevé utilisable comme [preuve d’audit](/blog/access-reviews-soc2-iso27001) plutôt que comme instantané de la configuration courante. Chaque expiration que Lutril fixe est une expiration qu’il peut honorer. La limitation dans le temps est câblée à un vrai chemin de retrait, que Lutril gère le compte via le provisionnement propre à l’application ou via les groupes Google Workspace et Microsoft Entra. L’échéance n’est pas un rappel dans l’agenda de quelqu’un. C’est le retrait. ## Ce qui se passe à l’échéance Une tâche de fond vérifie toutes les quelques minutes les attributions qui expirent et celles qui ont expiré. Trois choses peuvent survenir. **Un avertissement part d’abord.** Le préavis est proportionnel à l’attribution, environ un quart de la fenêtre, plafonné à 24 heures. Une attribution de 7 jours est signalée un jour à l’avance. Une attribution d’1 heure n’est pas signalée du tout, parce qu’un avertissement sur une heure n’est que du bruit. Le message arrive dans Slack ou Teams, avec des boutons pour prolonger ou pour laisser expirer. **Les prolongations sont bornées.** Une attribution peut être prolongée jusqu’à trois fois, et chaque prolongation est réévaluée contre la politique vivante, pas contre l’instantané figé. Si vous avez resserré la politique depuis l’attribution initiale, la prolongation respecte la nouvelle limite. Il n’y a pas de nouveau tour d’approbation, puisque l’approbateur avait déjà autorisé « jusqu’au maximum de la politique », et chaque prolongation est journalisée. **Le retrait passe d’abord par le déprovisionnement.** L’accès est retiré à la source avant que l’attribution ne soit marquée comme expirée. Si le retrait échoue, l’attribution reste vivante et l’échec est journalisé pour le passage suivant. Un relevé qui affiche « expiré » alors que la permission est toujours attachée est pire que pas de relevé du tout. ``` 09:14:02 ACCESS_REQUEST_CREATED notion / admin 8 h demandées, motif : incident 4471 09:16:48 ACCESS_REQUEST_DECIDED accordé approbateur plafonne à 4 h, maximum politique 8 h 12:16:48 ACCESS_GRANT_EXPIRY_WARNED message slack expire dans 1 h 12:31:10 ACCESS_GRANT_EXTENDED +2 h prolongation 1 sur 3, relue depuis la politique vivante 15:20:05 ACCESS_GRANT_EXPIRED notion / admin déprovisionné, ttl_expired ``` **Vous choisissez la façon dont cela atterrit** Le retrait est précis. Lutril reprend exactement ce que l’attribution avait ajouté, en le confrontant à ce qu’il a consigné avoir accordé, et il laisse l’accès en place si la personne détient encore l’application par une autre voie. Avant que l’application des règles ne change quoi que ce soit, vous voyez la liste complète des attributions déjà passées d’échéance : le premier passage ne réserve donc aucune surprise. Les équipes qui veulent un atterrissage en douceur peuvent n’activer que les avertissements pendant un cycle, puis brancher le retrait une fois l’arriéré nettoyé. ## Le même moteur, appliqué aux agents IA Les politiques d’agents utilisent le même tableau, les mêmes conditions et la même logique de durée. Quatre choses diffèrent, et toutes les quatre existent parce qu’un agent n’est pas une personne. - **Le sujet est l’humain qui pilote l’agent.** Le service, le statut RH et les conditions de formation s’évaluent contre cette personne, pas contre un compte de service sans attribut à évaluer. - **Un agent ne peut jamais dépasser les accès de son propriétaire.** Cette vérification s’exécute avant même la consultation de la politique. Si le propriétaire n’a pas l’intégration, aucune politique ne peut la donner à l’agent. - **Lecture et écriture sont deux politiques distinctes.** La portée est appariée exactement, si bien qu’une politique de lecture n’implique jamais l’écriture. Un agent qui peut fouiller votre CRM n’obtient pas pour autant le droit de le modifier. - **Les attributions à usage unique existent.** Certains agents reçoivent une permission pour exactement un appel, consommée à la première utilisation réussie, avec une courte expiration de sécurité derrière au cas où l’appel n’arriverait jamais. L’application se fait au niveau de l’appel d’outil, via le proxy MCP auquel l’agent se connecte. Si vous voulez la mécanique de cette couche, nous l’avons traitée dans [La gouvernance MCP](/blog/mcp-governance). Le point qui compte ici, c’est que limiter un agent dans le temps n’est pas un produit différent de limiter un collaborateur. C’est la même politique, avec le sujet remplacé. ## Ce qu’il faut exiger de toute implémentation JIT Que vous le construisiez ou l’achetiez, voici les propriétés qui séparent un JIT qui fonctionne d’une colonne « expiration » dans une base de données. - Celui qui accorde est celui qui révoque. Si un autre système, une autre équipe ou une autre file de tickets est responsable du retrait, le retrait n’aura pas lieu de façon fiable. - La durée est un plafond qu’aucun rôle ne peut relever. Demandez explicitement si un approbateur peut accorder plus longtemps que la politique. La réponse doit être non. - Les faits inconnus partent vers un humain. Un moteur de politique qui échoue vers l’autorisation est un passif. Un moteur qui échoue vers le refus sera désactivé en une semaine. - Vous pouvez essayer une politique à blanc contre une personne réelle avant qu’elle ne décide de quoi que ce soit, et voir pourquoi chaque règle est passée ou non. - Les termes sont figés sur l’attribution. Modifier une politique ne doit pas réécrire l’historique de ce qui a été autorisé sous l’ancienne. - La couverture est honnête. Si l’outil ne sait pas révoquer une application, il doit le dire plutôt que de proposer une expiration qu’il ne peut pas appliquer. Le JIT ne réparera pas votre processus de départ à lui seul, et il ne remplace ni les [revues d’accès](/blog/access-reviews-soc2-iso27001) ni un vrai [traitement des départs](/blog/employee-offboarding-security). Ce qu’il fait, c’est changer le réglage par défaut. Un accès que personne n’a renouvelé cesse d’exister, sans que personne n’ait à penser à le retirer. À 45 identités non humaines par collaborateur, et ce chiffre grimpe, c’est la seule version du moindre privilège qui survive au contact du nombre réel d’identités que vous avez. --- # OAuth Finds the SaaS Employees Sign Into. Our Chrome Extension Finds the Rest. > La découverte OAuth fait remonter chaque application qu’un collaborateur a autorisée via Google ou Microsoft, avec les scopes exacts et l’identité de l’autorisateur. Elle ne voit pas les outils auxquels les gens s’inscrivent avec un e-mail professionnel et un mot de passe. Nous lançons aujourd’hui une extension de navigateur pour combler cet écart, la confidentialité d’abord. Source: https://www.lutril.com/fr/blog/chrome-extension-shadow-it Published: 2026-06-22 Topic: Shadow IT --- ## Pourquoi la découverte OAuth est la bonne fondation Lutril découvre déjà les SaaS en lisant les autorisations OAuth de Google Workspace et de Microsoft Entra ID. Chaque fois qu’un collaborateur clique sur « Se connecter avec Google » ou « Se connecter avec Microsoft » pour commencer à utiliser un nouvel outil, le fournisseur d’identité enregistre une autorisation : quelle application a été autorisée, quels scopes lui ont été accordés, quel utilisateur a autorisé, et quand. Nous lisons ces autorisations par consentement administrateur et les transformons en inventaire vivant. C’est une base solide, et nous voulons dire pourquoi. Elle n’exige aucun agent sur les postes. Elle repose sur un consentement administrateur, donc elle couvre toute l’organisation depuis une seule connexion, sans attendre qu’un logiciel atterrisse sur chaque ordinateur. Et elle est précise sur ce qui compte le plus pour le risque : les scopes. Pour chaque application découverte, vous voyez exactement ce qu’elle peut lire ou écrire (agenda, messagerie, fichiers, accès complet au Drive), qui a accordé cet accès, quand elle a été vue pour la première fois, et qui l’a autorisée en premier. C’est toute la différence entre savoir qu’une application existe et savoir ce qu’elle peut réellement faire de vos données. - **0**: agent à installer sur les postes - **1**: connexion administrateur, à l’échelle de l’organisation - **Scopes**: l’accès exact aux données, par application Pour la plupart des équipes, connecter Google et Microsoft fait remonter plus d’applications en une heure que la dernière année passée à poser la question autour de soi. C’est peu contraignant, c’est exact, et cela devrait être la première chose que vous activez. ## L’angle mort structurel La découverte OAuth a une frontière, et il est important de la nommer précisément. Ce n’est pas un défaut de l’approche. C’est une limite de couverture qui découle directement de la façon dont la donnée est produite. Une autorisation OAuth n’existe que si un collaborateur a autorisé une application via votre fournisseur d’identité. Si un outil propose « Se connecter avec Google », l’autorisation est créée et nous la voyons. Mais une part importante du SaaS ne s’adopte pas ainsi. Un collaborateur trouve un outil, s’inscrit avec son **e-mail professionnel et un mot de passe**, et s’en sert. Aucune poignée de main OAuth n’a lieu. Aucune autorisation n’est enregistrée. L’application est, par construction, invisible pour une découverte fondée sur les autorisations. **Pourquoi cela compte spécifiquement pour le shadow IT** Le chemin e-mail et mot de passe, c’est exactement par là que commencent les expérimentations discrètes : l’outil qu’on essaie une semaine, l’offre gratuite qu’une équipe adopte avant que quiconque n’ouvre un ticket, l’utilitaire de niche qui n’apparaît sur aucune liste d’achats. Comme nous l’avons vu dans Votre équipe IT connaît 40 applications SaaS. Vous en avez 130., cette longue traîne constitue l’essentiel du shadow IT réel. L’OAuth voit les applications auxquelles les gens se sont connectés. Il ne voit pas celles auxquelles ils se sont inscrits. On peut combler une partie de cet écart avec des journaux réseau ou un proxy, mais ces approches sont lourdes : elles demandent des changements d’infrastructure, elles manquent souvent les appareils hors du réseau d’entreprise, et elles ont tendance à noyer les équipes sous du trafic brut sans rapport avec le SaaS. Nous voulions quelque chose de plus léger, de plus précis, et conçu pour ne remonter que l’usage de SaaS connus, rien d’autre. ## Le lancement : une extension de navigateur Lutril Nous lançons aujourd’hui une extension de navigateur Lutril, d’abord sur Chrome, Firefox ensuite. Elle comble l’écart de l’e-mail et du mot de passe en remontant les **domaines de SaaS connus** qu’un collaborateur visite. Si quelqu’un utilise un outil dans son navigateur, l’extension peut vous dire que l’outil est en usage, même si aucune autorisation OAuth n’a jamais été créée. Parce qu’une extension de navigateur est la chose la plus sensible que l’on puisse déployer sur la machine d’un collaborateur, nous commencerons par la confidentialité, puisque c’est la première objection, et la plus légitime. Les choix de conception ci-dessous ne sont pas des options ajoutées. Ce sont le cœur du sujet. ### Elle est installée d’office, et les collaborateurs n’ont rien à faire L’extension est poussée vers les navigateurs gérés par votre MDM, la console d’administration Google Workspace ou Microsoft Intune. Aucune étape d’installation pour le collaborateur, aucune connexion, aucune fenêtre, aucun compte à créer. Les administrateurs génèrent un jeton d’enrôlement et le poussent par la configuration managée. Du côté du collaborateur, rien ne change dans sa façon de naviguer. C’est ce déploiement sans friction qui rend une couverture à l’échelle de l’organisation réaliste, plutôt qu’un projet de déploiement qui s’enlise à 30 pour cent. ## Ce qu’elle envoie, et ce qu’elle ne voit jamais La propriété la plus importante de l’extension est ce qu’elle ne transmet pas. Le filtrage se fait sur l’appareil, avant que quoi que ce soit ne le quitte. **Ne quitte jamais la machine** - La navigation générale : banque, vie privée, intranet, actualités - Les URL complètes, les chemins et les paramètres de requête - Le contenu des pages : rien n’est lu ni extrait - Tout domaine absent du catalogue SaaS constitué **Transmis à Lutril** - Un nom d’hôte, uniquement s’il figure au catalogue SaaS - Le nom d’hôte seul : jamais le chemin ni la requête - Quel utilisateur (ou anonymisé, si vous le choisissez) - Les navigations de premier niveau, pas l’activité dans la page Point par point, concrètement : - **Filtrage sur l’appareil.** L’extension embarque un catalogue constitué de domaines SaaS connus. Elle ne transmet un nom d’hôte que si ce domaine y figure. Une visite sur votre banque, votre messagerie personnelle, un wiki interne ou un site d’actualités ne correspond à rien et ne quitte jamais la machine. Il n’existe aucun journal de navigation générale, ni sur vos serveurs ni sur les nôtres. - **Noms d’hôtes uniquement.** Quand un domaine SaaS connu correspond, l’extension remonte le nom d’hôte, par exemple `notion.so`, et rien de plus. Pas d’URL complète, pas de chemin, pas de paramètre de requête, pas de contenu de page. Le signal est « cette personne utilise Notion », pas « voici la page où elle se trouvait ». - **Permissions minimales.** L’extension observe les navigations de premier niveau pour savoir quel site s’est chargé. Elle ne demande pas la permission de lire le contenu des pages, et n’extrait rien. La surface de permissions est délibérément réduite, pour qu’un relecteur en sécurité puisse la comprendre vite. - **Jetons d’enrôlement par appareil.** Chaque installation s’enrôle avec un jeton propre à l’appareil, révocable individuellement : vous pouvez couper un poste sans toucher au reste du parc. - **Mode anonymisé facultatif.** Si vous opérez dans un contexte de comité social et économique ou de RGPD où l’attribution nominative est sensible, vous pouvez faire tourner l’extension en mode anonymisé, qui remonte l’usage des applications au niveau de l’organisation sans l’attribuer à des individus. Vous voyez toujours quels outils sont utilisés, sans nommer qui les utilise. ## Un seul inventaire, deux points de vue Les applications découvertes par l’extension n’atterrissent pas dans un rapport séparé. Elles alimentent le **même inventaire de shadow IT** que vos applications découvertes par OAuth, avec une source « Extension de navigateur ». Lutril corrèle ensuite les deux signaux par éditeur, et c’est là que le tableau devient utile. - Une application vue **à la fois** par le SSO et par l’extension affiche les deux sources. C’est votre inventaire à haute confiance, réellement utilisé : autorisé via votre IdP et observé en usage. - Une application vue **par OAuth seul** a été autorisée en SSO. Vous disposez des scopes et de l’autorisateur, ce qui est la bonne vue pour le risque de portée et d’accès. - Une application vue **par l’extension seule** est le shadow IT en e-mail et mot de passe, que la découverte par autorisations ne pouvait pas faire remonter. C’est la catégorie qui était jusqu’ici invisible. L’attribution par utilisateur montre qui a utilisé quoi, pour qu’un constat devienne actionnable plutôt qu’un simple décompte. Voici un aperçu de la façon dont les deux sources se résolvent dans un inventaire unique : - Notion 21 Autorisation SSO + usage observé Les deux - Figma 34 Connexion avec Google OAuth - Linear 9 Inscription e-mail + mot de passe Extension - Typeform 6 Inscription e-mail + mot de passe Extension - Calendly 18 Autorisation SSO + usage observé Les deux Ce sont les lignes « Extension » qui comptent pour ce lancement. Linear et Typeform ont été adoptés avec un e-mail professionnel et un mot de passe. Aucune autorisation OAuth n’existe pour l’un ni pour l’autre, donc aucun des deux ne serait apparu dans un inventaire fondé sur les autorisations. C’est l’extension qui les rend visibles, et l’attribution par utilisateur vous dit exactement quelles sont les neuf personnes présentes dans cet espace Linear. ## Le déploiement en pratique Tout le déploiement est une tâche d’administration. On ne demande jamais rien aux collaborateurs. En version courte : 1. **Connectez Google et Microsoft.** Cela active la base OAuth et vous donne immédiatement l’inventaire des applications autorisées en SSO, avec leurs scopes. 2. **Générez le jeton d’enrôlement de l’extension.** Dans les paramètres, créez le jeton que Lutril utilise pour associer les installations à votre espace de travail. 3. **Poussez l’extension par votre MDM.** Installez-la d’office via la console Google Workspace ou Microsoft Intune, et joignez la configuration managée : le jeton d’enrôlement, l’identifiant de votre espace de travail, et l’e-mail de l’utilisateur (substitué par appareil par le MDM, pour que chaque installation remonte la bonne personne). 4. **Regardez l’inventaire se remplir.** Les domaines découverts remontent automatiquement dans le même inventaire de shadow IT, étiquetés par source et corrélés à vos autorisations OAuth. **La configuration managée, en bref** Trois valeurs sont poussées avec l’extension : le jeton d’enrôlement (par appareil, révocable), l’identifiant de l’espace de travail (à quel espace Lutril remonter), et l’e-mail de l’utilisateur (renseigné par la variable de substitution du MDM, donc défini une fois pour tout le parc). Ensuite, l’extension s’enrôle seule au premier lancement, sans aucune interaction du collaborateur. ## Quand utiliser quoi Ce ne sont pas des approches concurrentes. Elles couvrent des surfaces différentes, et la valeur vient de les faire tourner toutes les deux. En version courte, voici où chacune gagne sa place : | Approche | Ce qu’elle fait le mieux | Ce qu’elle ne peut pas voir | | --- | --- | --- | | Découverte OAuth | Les applications validées et en SSO, avec leurs scopes exacts, l’autorisateur et la date de première apparition | Tout ce qui a été atteint avec un e-mail professionnel et un mot de passe | | Extension de navigateur | La longue traîne des inscriptions par e-mail et mot de passe, plus un vrai signal d’usage | Les scopes et les permissions accordées (aucune autorisation OAuth à lire) | | Les deux ensemble | Une couverture complète : ce qui a été autorisé, ce qui est réellement utilisé, et par qui | Les outils réellement hors ligne, qui ne touchent jamais un navigateur géré | L’OAuth vous dit ce qu’une application a le droit de faire de vos données. L’extension vous dit que l’application est utilisée, tout court. Aucune ne remplace l’autre. Faites tourner la base OAuth pour le risque de portée, ajoutez l’extension pour la longue traîne des inscriptions par e-mail et le signal d’usage, et l’inventaire du shadow IT cesse d’être une estimation pour devenir un relevé. Si vous avez déjà connecté Google et Microsoft, générer le jeton de l’extension et la pousser par votre MDM est l’affaire d’un après-midi, et cela fait remonter une catégorie de shadow IT que vous n’aviez jamais pu voir. Si vous n’avez pas encore connecté de fournisseur d’identité, commencez par là : c’est la base sur laquelle tout le reste se construit. --- # MCP Governance: How to Control What AI Agents Can Do in Your SaaS > Les agents IA appellent désormais vos outils SaaS via le Model Context Protocol. La gouvernance MCP, c’est la façon dont vous décidez de ce qu’ils ont le droit de faire, prouvez ce qu’ils ont fait, et les coupez en quelques secondes. Voici le modèle. Source: https://www.lutril.com/fr/blog/mcp-governance Published: 2026-06-18 Topic: AI Governance --- ## Qu’est-ce que la gouvernance MCP ? **La gouvernance MCP est la pratique consistant à contrôler, autoriser et auditer ce que les agents IA ont le droit de faire lorsqu’ils appellent vos outils via le Model Context Protocol (MCP).** Concrètement, cela signifie donner à chaque agent une identité enregistrée, cadrer son accès à des outils précis, confronter chaque appel d’outil à une politique avant qu’il n’atteigne votre SaaS, journaliser l’appel, et pouvoir révoquer cet accès instantanément. C’est la discipline que vous appliquez déjà à vos collaborateurs, appliquée au logiciel qui agit désormais à leurs côtés. Les humains ont le SSO, des rôles, des journaux d’audit et un processus de départ. Les agents, jusqu’à récemment, avaient une clé d’API collée dans un fichier de configuration, et rien d’autre. La gouvernance MCP comble cet écart. ## Pourquoi MCP change le problème d’accès Le Model Context Protocol, publié par Anthropic fin 2024, s’est imposé comme la façon standard de connecter les agents IA à des outils externes. Plutôt que de livrer une intégration sur mesure pour chaque application SaaS, les agents appellent les outils via des serveurs MCP : un intermédiaire standardisé qui arbitre la connexion. Claude, et une liste croissante d’autres clients, le parlent nativement. Cette standardisation coupe des deux côtés. Elle rend les agents nettement plus capables, puisqu’un seul protocole débloque tous les outils connectés. Et elle concentre le risque, puisqu’un seul agent mal doté peut désormais lire, écrire et agir sur l’ensemble de votre parc SaaS par un seul canal. La propriété qui rend MCP utile, une couche de connexion unique, est exactement ce qui en fait le bon endroit où poser des contrôles. ## Pourquoi une clé d’API n’est pas de la gouvernance Aujourd’hui, la façon par défaut dont un agent obtient un accès est simple : quelqu’un génère une clé d’API, la colle dans la configuration de l’agent, et l’agent se met à appeler des API. Cette clé est un identifiant brut. Elle hérite en général de tous les droits de son créateur, elle expire rarement, et rien n’enregistre ce que l’agent en a réellement fait. **Clé d’API brute** - Aucune identité : les appels apparaissent comme un jeton anonyme - Hérite de tout ce que son créateur pouvait faire ; aucun moindre privilège - Aucune politique par appel : tous les outils sont accessibles - N’expire jamais ; survit au départ de son créateur - Aucune piste d’audit des prompts, paramètres ou résultats **Accès MCP gouverné** - Identité d’agent enregistrée, avec un propriétaire nommé - Cadré sur des outils précis par des rattachements explicites - Chaque appel confronté à une politique avant exécution - Accès limité dans le temps ; signalé automatiquement au départ du propriétaire - Journal inaltérable et exportable de chaque appel d’outil Le problème n’est pas que les clés d’API soient mauvaises, c’est qu’un identifiant n’est pas un contrôle. La gouvernance, c’est ce que vous enroulez autour de l’identifiant pour qu’il puisse être raisonné, revu et révoqué. Pour comprendre pourquoi l’outillage d’identité traditionnel manque totalement les agents, lisez [La faille de gouvernance de l’IA](/blog/the-ai-governance-gap). ## Gouvernance ou autorisation Ces deux termes s’emploient indifféremment, et ils ne devraient pas. **L’autorisation MCP** La décision prise à chaque appel : cet agent a-t-il le droit d’invoquer cet outil avec ces paramètres, maintenant ? C’est une barrière oui/non évaluée à chaque requête. **La gouvernance MCP** Le programme qui entoure cette barrière : enregistrer les agents comme des identités, leur attribuer rôles et portées, journaliser chaque appel, revoir les accès à intervalles réguliers, et les révoquer au départ. L’autorisation est un contrôle à l’intérieur de la gouvernance, le moment de l’application, mais c’est la gouvernance qui rend ce moment auditable et réversible. On peut avoir de l’autorisation sans gouvernance : une passerelle qui autorise ou bloque des appels, mais ne garde aucune trace durable et n’est jamais revue. Cela réussit une démonstration et rate un audit. La gouvernance, c’est ce dont un auditeur, un régulateur ou votre vous-même futur a réellement besoin. ## Le motif de la passerelle MCP La façon la plus propre de gouverner les agents est de cesser de leur confier des identifiants. À la place, placez un serveur entre vos agents et vos outils SaaS. Les agents appellent les outils à travers lui ; c’est lui qui détient les identifiants, prend les décisions et garde la trace. C’est la **passerelle MCP** (parfois appelée proxy MCP), l’équivalent de ce que fait une passerelle d’API pour des services, ou un reverse proxy pour le trafic web. Une passerelle MCP gouvernante fait cinq choses à chaque requête : - Elle authentifie l’agent appelant et le rattache à une identité et un rôle enregistrés - Elle confronte l’appel d’outil à la politique **avant** de le transmettre au SaaS cible - Elle transmet les appels autorisés, avec des identifiants que l’agent ne voit jamais - Elle bloque les appels qui violent la politique, et peut ouvrir une demande d’accès pour revue - Elle écrit une entrée de journal inaltérable : quel agent, quel outil, quels paramètres, quelle issue À quoi cette application ressemble en pratique : ``` 2026-06-18 09:14:03 agt_7fRxP2 ALLOW slack.list_channels (24 canaux, 41 ms · rattachement : slack:read) 2026-06-18 09:14:38 agt_7fRxP2 ALLOW hubspot.read_deals (25 lignes, 88 ms · politique : ai.sales.read) 2026-06-18 09:15:02 agt_7fRxP2 DENY hubspot.export_contacts (aucun rattachement · export en masse hors périmètre) 2026-06-18 09:15:19 agt_3kQmost DENY notion.delete_page (agent suspendu · coupe-circuit actif) ``` Les deux lignes DENY sont tout l’enjeu. Journaliser ce qui s’est passé est le minimum ; la gouvernance consiste à empêcher la mauvaise chose de se produire, et à pouvoir le prouver. Pour une mise en pratique complète du branchement d’un agent à travers une passerelle avec un accès cadré, voyez [comment connecter Claude à Slack via MCP avec des contrôles d’accès](/blog/connect-claude-slack-mcp-lutril). ## Les cinq contrôles de la gouvernance MCP Quel que soit l’outil retenu, un modèle complet de gouvernance MCP repose sur cinq contrôles. S’il en manque un, vous avez une faille qu’un auditeur, ou un incident, trouvera. ### 1. L’identité Chaque agent est enregistré comme une identité de plein droit : un nom, un propriétaire, une finalité déclarée et une expiration. Pas un compte de service, pas une clé anonyme. Quand un appel d’outil a lieu, vous savez quel agent l’a fait et qui en répond. ### 2. Une portée en moindre privilège Un agent reçoit des rattachements explicites aux seuls outils dont il a besoin, et rien de plus. Un résumeur qui lit Slack et publie dans un canal n’obtient pas l’écriture sur votre CRM. Les portées sont étroites par défaut ; les élargir est un acte délibéré et journalisé. ### 3. Une autorisation fondée sur la politique Chaque appel d’outil est confronté à la politique en temps réel. Lecture ou écriture, limites de débit, contraintes de paramètres et règles sur les données personnelles sont évaluées avant que l’appel n’atteigne le SaaS. Tout ce qui sort de la politique est bloqué, pas simplement journalisé après coup. ### 4. Une piste d’audit inaltérable Chaque appel, autorisé ou refusé, est écrit dans un journal infalsifiable avec tout son contexte : agent, outil, paramètres, réponse, et politique appliquée. Ce journal est exportable comme preuve pour SOC 2, ISO 27001 et les exigences de journalisation du règlement européen sur l’IA. ### 5. La révocation et la revue Vous pouvez suspendre un agent globalement en une action, un coupe-circuit qui arrête l’accès sur tous les outils d’un coup, sans partir à la chasse aux identifiants. L’accès est limité dans le temps (l’expiration force une décision périodique de renouvellement), revu selon un calendrier, et signalé automatiquement au départ du propriétaire de l’agent. Un agent dont le créateur est parti ne devrait jamais continuer de tourner en silence ; voyez [quand le collaborateur part mais que l’agent reste](/blog/ai-agent-offboarding). ## Shadow MCP : la partie que personne ne surveille Il existe un problème de gouvernance situé un cran au-dessus de la politique : les agents et serveurs MCP dont vous ignorez l’existence. Un développeur monte un connecteur MCP vers un outil SaaS pour un projet annexe. Une équipe branche un agent interne sur votre entrepôt de données. Rien de tout cela ne passe par une revue de sécurité. C’est le **shadow MCP**, le cousin natif de l’IA du shadow IT : il détient des identifiants vivants vers des systèmes de production tout en restant invisible pour ceux qui en répondent. On ne gouverne pas ce qu’on ne voit pas. La découverte, c’est-à-dire trouver les serveurs MCP et connecteurs d’agents non gouvernés puis les ramener sous les contrôles ci-dessus, est la condition préalable à tout le reste. C’est le même muscle que la [découverte du shadow AI](/blog/shadow-ai-risks), braqué sur une nouvelle surface. La plupart des outils de gouvernance des accès supposent que les agents arrivent déjà enregistrés ; l’étape la plus difficile, et la plus utile, est de faire remonter ceux qui ne le sont pas. ## Une checklist de gouvernance MCP Un point de départ pratique. Si vous pouvez répondre oui à chaque point, vous avez de la gouvernance, pas seulement de la connectivité : - Chaque agent est-il enregistré avec un propriétaire nommé, une finalité et une date d’expiration ? - Chaque agent dispose-t-il de rattachements explicites en moindre privilège plutôt que d’une clé large ? - Chaque appel d’outil est-il autorisé par la politique *avant* d’atteindre le SaaS ? - Les agents appellent-ils les outils via une passerelle, plutôt que de détenir des identifiants bruts ? - Existe-t-il un journal inaltérable et exportable de chaque appel, avec tout son contexte ? - Pouvez-vous suspendre n’importe quel agent sur tous les outils en une seule action ? - Les droits d’accès des agents sont-ils revus selon un calendrier et révoqués au départ de leur propriétaire ? - Cherchez-vous activement les serveurs et agents MCP non gouvernés (shadow) ? Les cadres évoqués ici ne sont pas nouveaux : nous avons passé vingt ans à les mettre au point pour les humains. Ce qui est nouveau, c’est l’urgence de les appliquer aux agents avant que les déploiements ne dépassent le point où l’on peut encore greffer des contrôles. Le point de contrôle existe déjà : c’est la couche MCP. La question est de savoir ce que vous y faites respecter. ## Questions fréquentes ### Qu’est-ce que la gouvernance MCP ? La gouvernance MCP est la pratique consistant à contrôler, autoriser et auditer ce que les agents IA peuvent faire lorsqu’ils appellent des outils via le Model Context Protocol. Elle donne à chaque agent une identité enregistrée, cadre son accès à des outils précis, confronte chaque appel d’outil à une politique avant qu’il n’atteigne votre SaaS, journalise l’appel, et vous permet de révoquer l’accès instantanément. ### Quelle différence entre autorisation MCP et gouvernance MCP ? L’autorisation MCP est la décision, prise appel par appel, de savoir si un agent donné peut invoquer un outil donné. La gouvernance MCP est le programme plus large qui l’entoure : enregistrer les agents comme des identités, leur attribuer rôles et portées, journaliser chaque appel, revoir périodiquement les accès, et les révoquer au départ. L’autorisation est un contrôle à l’intérieur de la gouvernance. ### Pourquoi une clé d’API ne suffit-elle pas à gouverner les agents IA ? Une clé d’API est un identifiant brut, sans identité, sans politique par appel, sans expiration par défaut, et sans piste d’audit de ce que l’agent a réellement fait. Elle hérite en général de tous les droits de son créateur, survit à son départ, et ne peut pas être révoquée sans retrouver et faire tourner la clé partout où elle a été collée. ### Qu’est-ce qu’une passerelle MCP ? Une passerelle MCP est un serveur placé entre vos agents IA et vos outils SaaS. Les agents appellent les outils à travers elle plutôt que de détenir directement des identifiants. Elle authentifie l’agent, confronte chaque appel d’outil à la politique, transmet les appels autorisés, bloque les autres, et écrit un journal d’audit inaltérable. C’est le point d’application naturel de la gouvernance MCP. ### Qu’est-ce que le shadow MCP ? Le shadow MCP désigne les serveurs MCP et connecteurs d’agents IA déployés sans revue de sécurité ni gouvernance centrale, souvent par des développeurs ou des équipes isolées. Comme le shadow IT, ils détiennent des identifiants vivants vers des SaaS de production et restent invisibles pour l’équipe sécurité jusqu’à ce qu’ils soient découverts et ramenés sous gouvernance. --- # Shadow AI: 80% of Your Employees Use It. You Approved 23%. > Le shadow AI, c’est du shadow IT qui lit vos données et agit sur vos systèmes. Les collaborateurs adoptent des outils d’IA plus vite que la sécurité ne peut les examiner, et les plus récents ne se contentent plus de répondre, ils agissent. Voici pourquoi il se répand, ce qu’il coûte réellement, et comment l’encadrer plutôt que d’espérer qu’une interdiction tienne. Source: https://www.lutril.com/fr/blog/shadow-ai-risks Published: 2026-06-16 Topic: Shadow AI --- ## Ce qu’est réellement le shadow AI Le shadow AI, c’est l’usage, dans votre organisation, d’outils d’IA que vos équipes sécurité et IT n’ont jamais validés, jamais configurés, et qu’elles ne voient pas. C’est la même forme que le [shadow IT](/blog/shadow-it-risks), ces outils SaaS que les collaborateurs adoptent seuls, avec deux différences qui l’aiguisent : ces outils ingèrent vos données pour fonctionner, et les plus récents ne se contentent plus de lire, ils agissent. Vu de l’intérieur, ça ne ressemble pas à une infraction. Ça ressemble à un commercial qui colle le contrat d’un client dans un chatbot gratuit pour le résumer. À un ingénieur support qui branche un assistant IA sur la base de connaissances pour traiter les tickets plus vite. À un analyste financier qui téléverse un export trimestriel pour qu’un modèle y repère des anomalies. Chaque décision, isolément, est raisonnable. Leur somme est une surface vaste et non gérée, où les données de l’entreprise s’écoulent vers des systèmes avec lesquels vous n’avez ni contrat ni journal. - **80%**: des collaborateurs utilisent des outils d’IA non validés - **23%**: n’utilisent que l’IA encadrée par leur organisation - **37%**: ont une politique permettant de le détecter L’écart entre les deux premiers chiffres, c’est tout le problème. L’essentiel de l’IA présente dans votre organisation tourne en dehors de la gouvernance que vous croyez avoir. Et à peine un tiers des entreprises disposent d’une politique qui la ferait ne serait-ce qu’apparaître, encore moins la contrôlerait. ## Pourquoi il se répand plus vite que le shadow IT Le shadow IT a mis des années à s’accumuler, parce que chaque outil supposait encore une inscription, un espace de travail, un minimum de configuration. Le shadow AI saute presque tout cela. Pas d’installation, pas d’espace à provisionner, souvent pas de compte au-delà d’un identifiant personnel. Un collaborateur ouvre un onglet, colle son travail, et obtient de la valeur en quelques secondes. Trois dynamiques le font avancer plus vite que n’importe quelle vague d’adoption SaaS avant lui : - **L’écart de productivité est réel et immédiat.** La panoplie validée est presque toujours en retard sur ce qu’un collaborateur peut atteindre seul. Quand l’option officielle est plus lente ou absente, les gens la contournent. Le shadow AI prospère précisément là où la gouvernance manque et où les outils officiels traînent derrière ce qui est librement disponible. - **Les comptes personnels contournent tous les contrôles.** Une part importante de l’usage de l’IA générative passe par des comptes personnels non gérés, donc jamais par votre SSO, votre DLP ou vos journaux d’audit. L’activité est invisible par construction, pas par accident. - **Les outils se recrutent entre eux.** Une personne trouve un flux de travail qui marche, le partage avec son équipe, et l’adoption s’emballe. Quand quelqu’un en sécurité en entend parler, il y a déjà de vraies données métier à l’intérieur et un flux dont les équipes dépendent. On ne se sort pas de cela par une note de service. La friction d’un processus de validation dépasse toujours celle d’ouvrir un onglet, et tant que ce sera vrai, le comportement continuera. ## Les vrais risques Le shadow AI est généralement présenté comme un problème de fuite de données, et c’en est un. Mais le coût se manifeste sur trois surfaces distinctes, et l’impact financier est désormais mesurable. - **+670 k$**: de surcoût par violation impliquant du shadow AI - **20%**: des violations impliquaient du shadow AI - **47%**: de l’usage de l’IA via des comptes personnels non gérés **Des données dont vous ne pouvez pas rendre compte** Quand un collaborateur colle des fiches clients dans un outil d’IA en offre gratuite, ces données quittent votre environnement et atterrissent dans un système tiers avec lequel vous n’avez ni contrat, ni accord de traitement, ni moyen de récupération. L’article 28 du RGPD impose un accord de traitement avec chaque sous-traitant manipulant des données personnelles. Le shadow AI crée des sous-traitants dont vous ignoriez l’existence, et « nous ne savions pas que nos équipes l’utilisaient » n’est pas une défense qu’un régulateur accepte. **Des décisions que vous ne pouvez pas expliquer** Quand un modèle non gouverné rédige un tri de candidatures, une décision de crédit ou un contenu destiné aux clients, vous héritez de la responsabilité d’un processus que vous ne savez pas reconstituer. Le règlement européen sur l’IA attend une supervision humaine et une journalisation pour les décisions automatisées à conséquences. Un outil que personne n’a déclaré ne produit aucun journal et ne permet aucune supervision : vous ne pouvez pas montrer comment une décision a été prise. **Des preuves d’audit que vous ne pouvez pas produire** SOC 2 et ISO 27001 vous demandent de démontrer que l’accès aux systèmes contenant des données sensibles est maîtrisé. Les outils de shadow AI sont des systèmes contenant des données sensibles, avec zéro contrôle d’accès. Un auditeur qui échantillonne l’usage réel trouvera des services d’IA qui ne figurent sur aucun inventaire ni aucune revue d’accès. ## Quand le shadow AI obtient le droit d’écrire Jusqu’ici, cela décrit le shadow AI comme une boîte de dialogue : les données entrent, une réponse sort, le dommage est une exposition. C’était la version 2024. La version actuelle est pire, parce que les outils ne se contentent plus de lire. Les agents IA se connectent à vos systèmes et y posent des actes. Via des connecteurs et le Model Context Protocol (MCP), un agent peut lire un CRM, publier dans Slack, ouvrir des pull requests, déplacer de l’argent ou mettre à jour des fiches, tout seul, en boucle. Quand un collaborateur branche l’un de ces agents sans revue, vous n’avez pas un outil clandestin qui a vu passer des données. Vous avez un acteur clandestin doté d’un accès en écriture permanent à des systèmes de production, sans propriétaire, sans permissions cadrées et sans piste d’audit. C’est la partie que la plupart des articles sur le « shadow AI » manquent. Le traitement médiatique en fait une histoire de confidentialité, alors que la version agentique est une histoire de contrôle d’accès. Les enquêtes montrent déjà qu’une majorité d’organisations accordent aux systèmes d’IA plus d’accès qu’à l’humain occupant le poste équivalent. Un agent qui survit au projet pour lequel il a été construit est l’équivalent IA d’un [collaborateur parti qui a gardé ses clés](/blog/ai-agent-offboarding), à ceci près qu’il tourne en continu et que personne ne se souvient de son existence. **Pourquoi votre IdP ne le voit pas** Okta et Azure AD gouvernent des connexions humaines. Un agent qui se connecte à un outil SaaS avec un jeton d’API ou une autorisation OAuth n’est pas une connexion humaine : il n’apparaît donc pas dans la vue de votre fournisseur d’identité sur les accès. C’est la raison structurelle pour laquelle le shadow AI agentique est invisible au socle auquel vous faites déjà confiance, et pourquoi l’encadrer demande une couche conçue pour des appelants non humains. Nous détaillons cette couche dans La faille de gouvernance de l’IA et Qu’est-ce que la couche d’accès pour les agents IA. ## Ce que révèle une analyse de shadow AI On ne gouverne pas ce qu’on ne voit pas : le premier geste est donc la découverte. Les signaux existent déjà dans des systèmes que vous maîtrisez. Les autorisations OAuth dans Google Workspace et Microsoft 365, les événements de connexion et les registres d’applications connectées révèlent tous quels services d’IA vos équipes ont branchés. La plupart des équipes sont surprises par leur première analyse, non parce que les outils sont exotiques, mais à cause du volume et de ce que ces outils peuvent atteindre. - ChatGPT (personnel) 52 Documents collés, données clients Élevé - Claude + connecteur CRM 6 Lecture/écriture sur HubSpot Élevé - Cursor / agent de code IA 18 Dépôt + écriture GitHub Élevé - Otter / prise de notes de réunion 34 Agenda, transcriptions d’appels Moyen - Gamma / générateur de présentations 11 Drive, contenus internes Moyen Ce sont les deux lignes agentiques qui doivent vous arrêter. Un connecteur CRM en écriture et un agent de code capable de pousser sur GitHub ne sont pas des risques d’exposition, ce sont des risques d’action. Six personnes ont branché une IA sur votre système client et lui ont donné le pouvoir de modifier des fiches : jusqu’à l’analyse, c’était vrai et invisible à la fois. ## Encadrer, pas interdire Le réflexe après une analyse de shadow AI est d’interdire : bloquer les domaines, supprimer les autorisations OAuth, envoyer la note. Ça ne marche pas, pour la même raison que ça n’a jamais marché avec le shadow IT. Les gens contournent l’interdiction, et vous perdez la visibilité que vous veniez de gagner, parce que l’usage migre vers des appareils et des comptes personnels que vous ne voyez plus du tout. Les données le confirment par l’autre bout : les organisations qui ont proposé à leurs équipes une alternative d’IA encadrée ont réduit l’usage non autorisé d’environ 89%. Les gens ne tiennent pas à l’outil clandestin. Ils tiennent à la capacité. Offrez-leur un chemin officiel vers cette capacité et l’essentiel de l’usage clandestin s’évapore de lui-même. Une approche praticable trie les outils par risque et par intention, plutôt que de dégainer une interdiction générale : | Catégorie | Approche | Pourquoi | | --- | --- | --- | | Agent avec accès en écriture à un système central | Le faire passer par une couche d’accès gouvernée | Des permissions cadrées, un propriétaire et un journal d’audit transforment un acteur clandestin en acteur géré | | Chatbot à risque élevé, usage métier avéré | Passer en priorité sur une offre entreprise officielle | Les équipes l’utiliseront de toute façon ; autant avec un accord de traitement, du SSO et des contrôles sur les données | | Risque élevé, aucun usage métier | Bloquer et expliquer pourquoi | Réduire la surface d’exposition là où aucun besoin légitime n’existe | | Risque moyen, usage très répandu | Adopter et encadrer | Bloquer un outil dont la moitié de l’entreprise dépend crée plus de friction que de risque | L’objectif n’est pas le zéro shadow AI, hors d’atteinte sans tuer aussi la productivité pour laquelle il a été adopté. L’objectif, c’est **une IA connue** : une photo continue et à jour des outils et agents d’IA qui existent, de qui les utilise, des données et systèmes qu’ils peuvent atteindre, et la capacité de cadrer ou de couper n’importe lequel d’entre eux. Pour les chatbots, cela veut dire une offre officielle avec de vrais contrôles sur les données. Pour les agents, cela veut dire une couche d’accès qui confronte chaque appel à une politique, rattache chaque agent à un propriétaire nommé, journalise ce qu’il fait et offre un coupe-circuit, pour qu’une IA agissant sur vos systèmes soit gouvernée exactement comme un humain doté de la même portée. --- # The AI Governance Gap > Votre socle de sécurité contrôle qui accède à vos outils SaaS. Il ignore jusqu’à l’existence de vos agents IA. Source: https://www.lutril.com/fr/blog/the-ai-governance-gap Published: 2026-06-03 Topic: AI Governance --- ## L’hypothèse qui a cédé L’infrastructure d’identité moderne force le respect. SAML, OIDC, SCIM, MFA, provisionnement à la volée. L’IT d’entreprise a passé vingt ans à bâtir un système qui sait qui est chaque collaborateur, ce à quoi il doit accéder, et quand lui couper les vivres. Ce système repose sur une hypothèse centrale : les demandes d’accès viennent de personnes. Un collaborateur s’authentifie en SSO. Votre IdP émet un jeton cadré sur ses groupes et ses rôles. À son départ, SCIM le déprovisionne automatiquement. À son changement de poste, ses appartenances de groupe se mettent à jour. Tout le système est fondé sur l’identité. Et c’est parce qu’il l’est qu’il fonctionne. Cette hypothèse a cédé sans bruit ces deux dernières années. La plupart des organisations n’ont pas encore rattrapé le retard. ## Comment les agents obtiennent un accès aujourd’hui Les agents IA comme Claude, ChatGPT, Copilot ou Gemini font désormais du vrai travail dans de vraies organisations. Pas seulement répondre à des questions : lire des pipelines commerciaux, écrire des e-mails, interroger des bases de données, et poser des actes qui ont des conséquences. Pour cela, ils ont besoin d’accéder à vos outils SaaS. Et la façon dont ils l’obtiennent aujourd’hui est simple : **quelqu’un génère une clé d’API, la colle dans la configuration de l’agent, et l’agent se met à appeler des API.** C’est tout. Pas de SSO. Pas d’appartenance à un groupe. Pas de jeton de session rattaché à une identité. Un identifiant brut qui donne accès à tout ce que la portée de la clé permet, c’est-à-dire en général tout ce que le développeur qui l’a générée avait le droit de faire. - **50+** - **41%** - **0** ## Trois failles que l’outillage actuel ne comble pas **Faille 1 : pas d’identité** Quand Claude lit 500 opportunités du CRM, qui a fait cela ? Pas le développeur qui a généré la clé : il n’a peut-être rien fait ce jour-là. L’action apparaît dans les journaux de votre SaaS comme un appel d’API brut depuis un jeton. Ce jeton n’a ni nom, ni rôle, ni propriétaire dans votre IdP. Quand le développeur part, vous désactivez peut-être son compte SSO, mais la clé d’API qu’il a générée reste active et continue d’appeler des API. **Faille 2 : aucune application de la portée** Une clé d’API HubSpot générée par un directeur commercial donne en général les mêmes accès que ce directeur. Pas seulement read_deals, mais aussi write_deals, delete_contacts, export_all. Aucun « moindre privilège » ne s’applique aux agents par défaut. En pratique, les agents tournent surdotés en droits, non par conception mais parce que des portées serrées créent de la friction et que la valeur métier passe d’abord. **Faille 3 : aucune piste d’audit** Qu’a fait votre agent IA mardi dernier ? À moins que quelqu’un n’ait construit une couche d’instrumentation à part, vous n’en savez rien de précis. Vous avez des journaux d’accès dans vos outils SaaS, mais ils vous disent qu’un jeton a été utilisé : ni quel prompt a déclenché l’appel, ni ce que l’agent cherchait à accomplir, ni si l’appel était autorisé par une quelconque politique. Comparez avec la façon dont un analyste humain fait le même travail : **Analyste humain** - Authentifié en SSO, identité vérifiée - Basé sur le rôle : « sales-analyst » lit, n’écrit pas - La session expire, l’accès suit le contrat de travail - Déprovisionné en quelques secondes à son départ - Chaque accès journalisé avec tout son contexte **Agent IA aujourd’hui** - Une clé d’API. Pas de SSO, absent de votre IdP. - Hérite de tout ce que la clé permet - La clé n’expire jamais, sauf rotation manuelle - Survit au départ, sauf si la clé est retrouvée - Jeton utilisé. Aucun prompt, aucun motif, aucune politique. ## Le volet réglementaire est plus proche qu’il n’y paraît Le règlement européen sur l’IA est pleinement entré en application en 2025. Ses exigences pour les systèmes d’IA à haut risque incluent des mesures de supervision humaine (article 14) et la journalisation automatique des événements (article 12). Le périmètre de ce qui compte comme « haut risque » est plus large que ne l’anticipent la plupart des directions juridiques, et l’application monte en puissance. En parallèle, les auditeurs SOC 2 commencent à poser des questions précises sur la gouvernance de l’IA. La réponse habituelle est un document de politique vague assorti de bonnes intentions. Elle ne suffit plus. Un rapport de Type II est censé démontrer l’efficacité opérationnelle dans la durée. **On ne démontre pas cela pour des contrôles qui n’existent pas.** Le principe de minimisation des données du RGPD (article 5) entre aussi en jeu. Si votre agent lit 10 000 fiches clients pour répondre à une question portant sur une seule opportunité, vous avez un problème de minimisation. Les architectures d’agents actuelles rendent la sur-extraction accidentelle facile, sans mécanisme pour restreindre l’accès au niveau de chaque appel d’outil. ## À quoi ressemble vraiment la gouvernance des agents La bonne nouvelle : nous savons résoudre cela sur le principe, parce que nous l’avons déjà résolu pour les humains. Le bon modèle mental est simple. **Les agents doivent être des identités de plein droit dans votre système de contrôle d’accès.** Pas des comptes de service. Pas des clés d’API. Des identités dotées de : - Un **identifiant d’agent enregistré**, rattaché à une définition : qu’est-ce que cet agent, qui l’a construit, que doit-il faire - Un **rôle** issu du même cadre RBAC que celui de vos collaborateurs : « sales-analyst » lit les opportunités sans pouvoir écrire ; « hr-ops » accède aux données RH ; « finance-viewer » est en lecture seule partout - Un **jeu de politiques** déterminant quels appels d’outils sont autorisés, avec quels paramètres et à quelle cadence - Un **journal d’audit inaltérable** capturant chaque appel avec tout son contexte : identifiant de l’agent, outil appelé, paramètres, réponse et issue - Un **coupe-circuit** qui suspend un agent globalement, sur tous les outils qu’il touche, en quelques secondes, sans révoquer les identifiants sous-jacents À quoi ce journal d’audit ressemble en pratique : ``` 2026-06-03 14:02:11 clde_7fRxP2 ALLOW hubspot.read_deals (25 lignes, 41 ms · politique : ai.sales.read) 2026-06-03 14:02:41 clde_7fRxP2 DENY hubspot.export_contacts (violation de la politique données personnelles · export en masse hors du rôle) 2026-06-03 14:03:15 clde_7fRxP2 ALLOW notion.read_page (doc : « Revue du pipeline T2 », 1,2 ko) 2026-06-03 14:05:02 clde_9mWkQ1 DENY salesforce.delete_record (écritures désactivées pour ce rôle d’agent · coupe-circuit actif) ``` C’est le DENY de la ligne 2 qui compte le plus. La gouvernance ne consiste pas seulement à journaliser ce qui s’est passé. Elle consiste à empêcher les mauvaises choses de se produire. ## L’opportunité MCP Le Model Context Protocol (MCP), publié par Anthropic fin 2024, s’impose comme la façon standard de connecter les agents IA à des outils externes. Plutôt que de développer des intégrations sur mesure entre chaque agent et chaque outil SaaS, les agents appellent les outils via des serveurs MCP, un intermédiaire standardisé qui arbitre la connexion. Cela crée un point de contrôle naturel. Un serveur MCP placé entre vos agents et vos outils SaaS peut : - Authentifier l’agent appelant et le rattacher à une identité et un rôle enregistrés - Confronter chaque appel d’outil à une politique avant de le transmettre au SaaS cible - Journaliser chaque appel avec tout son contexte : ce qui a été demandé, ce qui a été renvoyé, quelle politique s’est appliquée - Bloquer les appels qui violent la politique, sans que l’agent ait besoin d’en connaître la raison - Offrir un coupe-circuit global qui suspend un agent sur tous les outils simultanément C’est l’équivalent de ce que fait un reverse proxy pour le trafic web, ou une passerelle d’API pour des services. La couche d’application existe naturellement. La question est de savoir quelles politiques vous y faites respecter. ## La fenêtre, c’est maintenant La plupart des organisations en sont encore, sur les agents IA, au stade « on verra la gouvernance plus tard ». C’est compréhensible. Les cas d’usage sont convaincants, l’outillage est neuf, et les implications de sécurité paraissent abstraites jusqu’à ce qu’elles ne le soient plus. Les organisations qui bâtissent leur infrastructure de gouvernance maintenant, tant que les déploiements d’agents restent maîtrisables, se retrouveront dans une position très différente de celles qui devront greffer des contrôles sur un système devenu trop vaste pour être audité. Le contrôle d’accès pour les humains a mis des décennies à devenir juste. La fenêtre pour le réussir du premier coup avec les agents, avant que le désordre ne devienne irréversible, se referme. Les cadres existent déjà. Le point de contrôle existe déjà. Ce qui manque, c’est la volonté de l’appliquer avant que quelque chose ne tourne mal. --- # What Is the Access Layer for AI Agents? > Les agents IA ont besoin d’une identité, d’une application de politique, de journaux d’audit et d’un coupe-circuit avant de toucher à votre stack SaaS. Cette infrastructure a un nom. Voici ce qu’elle est et comment elle fonctionne. Source: https://www.lutril.com/fr/blog/ai-agent-access-layer Published: 2026-06-03 Topic: AI Governance --- ## Le concept : ce qu’est une couche d’accès Une **couche d’accès pour agents IA** est le plan de contrôle entre un agent et les outils SaaS qu’il peut atteindre. Elle se place sur le chemin de chaque appel d’outil et fait respecter quatre choses : qui est l’agent, ce qu’il a le droit de faire, ce qu’il a réellement fait, et s’il doit continuer de tourner. Deux analogies rendent le rôle concret. Une passerelle d’API se place entre des microservices et impose authentification, limitation de débit et routage avant tout appel en amont. Un système IAM se place entre les humains et les ressources de l’entreprise et impose identité, politique et contrôle d’accès avant toute connexion ou tout appel d’API. La couche d’accès pour agents IA est les deux à la fois, conçue pour des acteurs non humains qui opèrent par des API d’outils, à la vitesse de la machine. Les quatre composants qui définissent la catégorie : Identité Chaque agent a un identifiant unique et stable, rattaché à sa définition. Pas une clé d’API partagée. Pas un identifiant humain. Une identité persistante, qui survit aux exécutions et se révoque indépendamment. Politique Des règles qui définissent quels outils un agent peut appeler, quels paramètres il peut transmettre, et à quelle fréquence. Un agent chargé de conclure des ventes peut lire les contacts HubSpot. Il ne peut pas les supprimer. Cette limite est appliquée, pas supposée. Audit Un enregistrement inaltérable de chaque appel d’outil : quel agent, quel outil, quels paramètres, quelle réponse, et quand. Écrit une fois. Non modifiable a posteriori. Disponible pour la revue de sécurité et les preuves de conformité. Contrôle La capacité d’arrêter un agent immédiatement, de suspendre une capacité précise, ou de réattribuer un accès sans toucher aux identifiants SaaS sous-jacents. Un point de révocation unique, quel que soit le nombre d’outils auxquels l’agent était connecté. ## Pourquoi cette infrastructure n’existait pas avant Des agents IA opérant par API d’outils à l’échelle de la production, c’est un phénomène de 2024. Avant cela, les automatisations branchées sur des outils SaaS étaient des scripts étroits et déterministes : un flux Zapier, un gestionnaire de webhook, une tâche planifiée. Ces scripts étaient écrits par des humains, relus par des humains, et suivaient des chemins prévisibles. Ils avaient besoin d’identifiants, pas de gouvernance. Les systèmes IAM existants ont été bâtis pour des humains. Okta, Azure AD et leurs pairs gèrent des identités qui correspondent à des collaborateurs. Ils prennent en charge la connexion, la gestion de session, le MFA et les événements de cycle de vie comme les arrivées et les départs. Ils ne sont pas conçus pour une entité sans écran de connexion, qui ne crée aucun cookie de session, et qui peut appeler 400 outils au cours d’une seule tâche. Quand les équipes ont commencé à déployer des agents fondés sur des LLM avec accès à de vrais outils, en 2023 et 2024, l’approche standard consistait à créer un compte de service, à mettre une clé d’API dans une variable d’environnement, et à passer à autre chose. Cela fonctionne pour un prototype. Pour des agents en production ayant accès aux données clients, aux systèmes financiers ou aux canaux de communication, cela crée un accès non gouverné, sans piste d’audit ni coupe-circuit. La catégorie de la couche d’accès existe parce que cet écart est devenu trop grand pour être ignoré. Les équipes sécurité ont demandé comment auditer les actions des agents. Les équipes conformité, comment cadrer leurs permissions. Les équipes d’ingénierie, comment révoquer un accès sans casser les déploiements. La réponse exigeait une infrastructure qui n’existait pas encore. ## Les quatre composants d’une couche d’accès Chaque composant traite un mode de défaillance précis créé par un accès d’agent non géré. **L’identité** résout le problème d’attribution. Quand un agent modifie une fiche dans Salesforce, qui a fait cela ? Avec des identifiants de compte de service partagés, la réponse est « le compte de service », ce qui peut désigner n’importe lequel d’une dizaine d’agents ou de scripts. Avec une identité d’agent, la réponse est une version d’agent précise, exécutant une tâche précise, déclenchée par un utilisateur ou un système précis. L’attribution rend la révocation ciblée plutôt que nucléaire. **La politique** résout le problème du surdimensionnement des droits. Une clé d’API est binaire : son porteur peut tout ce que la clé permet, ou rien. L’application d’une politique apporte de la granularité. Un agent peut être autorisé à lire les données du CRM sans les écrire, à envoyer des messages Slack dans un canal précis sans en créer de nouveaux, à interroger une base sans exécuter d’instructions destructrices. La couche de politique traduit un accès large à l’API en permissions étroites, adaptées à la tâche. **L’audit** résout le problème de visibilité. Sans lui, les actions d’un agent sont opaques. Vous savez ce qu’on lui a demandé, pas ce qu’il a réellement fait. Un journal d’audit complet consigne l’appel d’outil, les paramètres envoyés, la réponse reçue et l’horodatage. Cet enregistrement fait toute la différence entre « on pense que l’agent n’a fait que lire les données » et « on peut le prouver ». **Le contrôle** résout le problème de la réponse à incident. Quand un agent se comporte de façon inattendue, la question est : comment l’arrêter, et en combien de temps ? Avec des identifiants intégrés à la configuration de déploiement, arrêter un agent signifie faire tourner des clés et redéployer, ce qui prend du temps et peut casser d’autres systèmes partageant la même clé. Un plan de contrôle dédié permet d’arrêter l’agent sur tous les outils connectés d’un seul appel de révocation, immédiatement. ## Pourquoi MCP est le bon point de contrôle Le Model Context Protocol (MCP) est un standard qui définit comment les agents IA appellent des outils. Un agent envoie une requête structurée à un serveur MCP ; le serveur exécute l’outil et renvoie un résultat. Chaque appel d’outil franchit cette frontière protocolaire. Cette frontière est le point d’application naturel d’une couche d’accès. Quand le serveur MCP traite une requête d’outil, il dispose déjà de tout ce qu’il faut pour appliquer une politique : l’agent demandeur, l’outil appelé, et les paramètres transmis. Ajouter la vérification d’identité, l’évaluation de politique et la journalisation d’audit à cette couche n’exige aucun changement dans l’agent ni dans l’outil SaaS en aval. Le point de contrôle est déjà là. Comparez avec l’alternative : appliquer la gouvernance au niveau de l’API SaaS. Il faudrait s’intégrer au système de contrôle d’accès natif de chaque outil, chacun avec son modèle, ses API et ses capacités d’audit propres. Une politique d’accès HubSpot n’a rien à voir avec une politique GitHub. Une couche d’accès au niveau MCP applique un modèle de politique unique et uniforme à tous les outils connectés. **Le serveur MCP comme couche d’accès** Quand un serveur MCP impose l’identité de l’agent, évalue la politique avant d’exécuter un appel d’outil, écrit une trace d’audit inaltérable pour chaque appel et expose une API de contrôle pour la révocation et la mise en pause, c’est une couche d’accès. Le protocole a été conçu pour être ce point de contrôle. La plupart des implémentations d’aujourd’hui sautent purement et simplement l’étape d’application. ## À quoi cela ressemble en pratique Un exemple concret : un agent commercial construit sur Claude a reçu un accès à HubSpot via un serveur MCP. Il reçoit une tâche : résumer les 10 dernières affaires conclues dans la région EMEA. Voici ce qui se passe à chaque étape de la couche d’accès : Trace de la couche d’accès · Agent : sales-assistant-v2 · Outil : HubSpot - 1 Vérification d’identité Le serveur MCP reçoit l’appel d’outil et vérifie l’identifiant de l’agent dans le registre. L’agent est sales-assistant-v2, empreinte de version a4f91c, déclenché par l’utilisateur marie@acme.com. Identité confirmée. Vérifié - 2 Évaluation de la politique La couche d’accès confronte l’appel à la politique de l’agent. Celui-ci dispose de la permission hubspot:deals:read, limitée au pipeline EMEA. L’appel demande une lecture de liste filtrée. La politique l’autorise. Autorisé - 3 Écriture d’audit Avant l’exécution de l’outil, la couche d’accès écrit une entrée de journal : identifiant de l’agent, nom de l’outil, charge utile complète des paramètres, horodatage. L’entrée est inaltérable. Si l’appel est réexaminé plus tard, cet enregistrement fait foi. Journalisé - 4 Exécution de l’outil et résultat Le serveur MCP appelle l’API HubSpot, récupère les 10 affaires, et renvoie le résultat à l’agent. La réponse est journalisée à côté de la requête. L’agent ne touche jamais directement aux identifiants HubSpot. Terminé L’aller-retour complet ajoute environ 2 à 5 ms de latence. L’agent n’y voit aucune différence. L’équipe sécurité dispose désormais d’un relevé complet de ce à quoi l’agent a accédé, de qui a déclenché la tâche, et des paramètres envoyés. Si le comportement de l’agent change ou si une politique doit être resserrée, la couche d’accès est le seul endroit à modifier. Agents IA Claude ChatGPT Copilot Couche d’accès Identité Registre des identifiants d’agents. Chaque agent a une identité unique et persistante, liée à sa définition et à sa version. Politique Des permissions cadrées par agent. Quels outils, quelles opérations, quels paramètres sont autorisés. Audit Journal inaltérable de chaque appel d’outil. Agent, outil, paramètres, réponse, horodatage. Contrôle Coupe-circuit, mise en pause et réattribution. Un point de révocation unique pour tous les outils connectés. Outils SaaS HubSpot Slack GitHub Notion ## Lutril comme couche d’accès Lutril met en œuvre ces quatre composants sous la forme d’un serveur MCP. Chaque agent qui se connecte via Lutril reçoit une identité stable. Les permissions se définissent par agent, avec le même cadre de rôles que celui utilisé pour les accès humains. Chaque appel d’outil est journalisé avec tout son contexte. La révocation est une opération unique qui prend effet immédiatement sur tous les outils connectés. La conception suit le modèle de l’IAM d’entreprise, appliqué à des acteurs non humains. Si votre équipe sécurité sait auditer aujourd’hui les accès SaaS d’un humain, elle saura auditer ceux d’un agent via Lutril de la même façon. Les revues d’accès, le flux de départ, les preuves de conformité : mêmes processus, mêmes outils, étendus aux agents. Aucune clé d’API séparée à faire tourner. Aucun compte de service partagé entre agents. Aucun angle mort à la mise hors service d’un agent. --- # When the Employee Leaves but the Agent Stays > Les agents IA construits par des collaborateurs partis continuent de tourner longtemps après la désactivation de leur compte Okta. Ils ont encore accès. Personne n’en est propriétaire. Voici quoi faire. Source: https://www.lutril.com/fr/blog/ai-agent-offboarding Published: 2026-06-03 Topic: AI Governance --- ## Le problème des agents orphelins Votre processus de départ attrape l’évident. Compte Okta désactivé. Ordinateur rendu. Slack désactivé. La personne est partie. Ce qu’il n’attrape pas : les trois agents IA qu’elle a construits dans l’année. L’un lit le CRM et envoie une synthèse hebdomadaire du pipeline. L’un surveille le dépôt GitHub et publie des alertes dans Slack. L’un tourne chaque nuit sur les données de facturation et produit des rapports. Les trois tournent encore le lundi matin. Les trois ont encore accès. Aucun n’apparaît sur la checklist de départ. C’est le problème des agents orphelins. Il est récent, il grandit, et presque aucun processus de départ standard ne le prend en compte. ## Pourquoi un départ standard passe à côté Le traitement traditionnel des départs a été conçu pour un monde où l’accès signifiait un compte. Désactiver le compte SSO, déprovisionner les applications fédérées, révoquer le VPN. Terminé. Les agents IA cassent ce modèle de deux façons. D’abord, les agents s’authentifient en général avec des clés d’API ou des jetons OAuth, pas en SSO. Quand vous désactivez le compte SSO d’une personne, ces identifiants ne sont pas révoqués pour autant. L’agent continue d’appeler les API avec le jeton qu’il a toujours utilisé, avec les mêmes permissions, sans qu’aucun journal n’indique que son propriétaire ne travaille plus là. Ensuite, les agents ne sont pas dans votre fournisseur d’identité. Il n’y a pas de fiche utilisateur à désactiver, pas d’appartenance de groupe à retirer, pas d’événement SCIM à déclencher. L’agent n’existe tout simplement pas dans les systèmes qui gèrent les départs. Résultat : un agent construit par une personne partie est fonctionnellement indiscernable d’un agent construit par quelqu’un encore en poste, jusqu’au jour où quelque chose tourne mal. ## Trois scénarios aux issues très différentes Scénario A : l’agent continue de tourner en silence La responsable des opérations commerciales part. Elle avait construit un agent qui lit les opportunités HubSpot chaque lundi et envoie une synthèse dans un canal Slack. Personne ne sait qu’elle l’a construit. Il continue de tourner. Six mois plus tard, le canal reçoit un message avec des noms d’opportunités et des montants. Son successeur n’a aucune idée d’où cela vient ni comment l’arrêter. Le risque n’est pas immédiat, mais il s’accumule. Un agent sans propriétaire, avec un accès vivant à des données métier, sans référent pour l’audit et sans personne sachant le modifier ou l’arrêter, représente une exposition qui grandit tranquillement. Scénario B : les identifiants de l’agent étaient liés au compte personnel du collaborateur Un développeur avait construit un agent avec son propre jeton OAuth Google pour accéder à Google Drive. Son compte Google est désactivé le dernier jour. Le jeton de l’agent est invalidé. Tous les traitements en aval qui en dépendaient échouent en silence ou se mettent à renvoyer des erreurs. L’IT est saisie, personne ne sait ce que faisait l’agent ni comment il était configuré, et la remise en route prend des jours. Ce scénario est en réalité le moins mauvais. Au moins, l’accès a disparu. Le problème est la perturbation opérationnelle, pas l’exposition en sécurité. Scénario C : l’agent utilisait un compte de service créé par le collaborateur Un ingénieur avait construit un agent et l’avait provisionné avec un compte de service créé pour l’occasion. Ce compte de service n’est pas rattaché à son identité SSO. Quand il part, son compte SSO est désactivé. Le compte de service persiste. L’agent persiste. Six mois plus tard, on découvre que cet ingénieur a toujours accès aux systèmes de production via ce compte de service, qui n’a jamais figuré dans le périmètre du ticket de départ. C’est la pire issue. Un accès persistant, aucune trace d’audit de sa propriété, et un incident de sécurité potentiellement en germe. ## Que faire au moment du départ Quand une personne part, la question pour les agents IA n’est pas seulement « désactiver » ou « laisser tourner ». Elle dépend de l’utilité de l’agent pour l’entreprise. 1 Découvrir Retrouver chaque agent que la personne possédait ou avait provisionné. Cela suppose un registre d’agents, pas une recherche manuelle. 2 Évaluer L’agent est-il encore nécessaire ? Examinez ce qu’il fait, ce à quoi il accède, et si l’activité en dépend. 3 Réattribuer ou suspendre Si vous le gardez : attribuez un nouveau propriétaire et confirmez que la portée d’accès reste appropriée. Sinon : suspendez et révoquez. 4 Documenter Consignez la décision avec le nom du relecteur et l’horodatage. C’est votre preuve d’audit que l’agent a bien été traité au départ. L’étape d’évaluation saute souvent sous la pression du temps. Le réflexe est de tout suspendre immédiatement. C’est le choix sûr côté sécurité, mais il peut casser des flux opérationnels sans prévenir. Une brève fenêtre de revue de 24 à 48 heures avant suspension laisse à l’équipe le temps d’identifier les agents critiques qui méritent une réattribution plutôt qu’un retrait. ## Le modèle de propriété qui évite le problème Les scénarios ci-dessus partagent une cause racine : les agents ont été créés sans fiche de propriété formelle sur laquelle le processus de départ puisse s’appuyer. Le correctif consiste à traiter la propriété d’un agent comme vous traitez l’attribution d’un rôle à un humain. À son enregistrement, un agent reçoit un propriétaire. Ce propriétaire est une personne nommée dans votre système d’identité, pas une équipe ni un service. Quand cette personne est signalée pour un départ, chacun de ses agents est signalé avec elle. Agents à examiner · Propriétaire : m.santos@entreprise.com (départ) 3 agents nécessitent une action Agent Propriétaire État Score de risque pipeline-summarizer agt_3kPqRx · HubSpot lecture m.santos (départ) Signalé 42 / 100 repo-watchdog agt_9mTvLw · GitHub lecture, Slack écriture m.santos (départ) Signalé 58 / 100 billing-reporter agt_2nHcBp · Stripe lecture m.santos (départ) Signalé 74 / 100 L’agent billing-reporter affiche un score de risque de 74 parce qu’il a un accès en lecture à Stripe. C’est celui qui demande une attention immédiate. Le résumeur de pipeline et le surveillant de dépôt peuvent sans doute être réattribués avec une revue minimale. Sans un registre qui fait remonter tout cela automatiquement, les trois restent invisibles pour le processus de départ. Pour chaque agent signalé, la décision se ramène à trois options : A **Réattribuer à un nouveau propriétaire** L’agent est encore utile. Un nouveau propriétaire en prend la responsabilité, revoit les rattachements d’accès en place, et confirme que la portée reste adaptée au travail qu’il effectue. B **Suspendre en attendant l’évaluation** L’agent est peut-être utile mais demande plus d’examen que le temps disponible. Suspendez-le immédiatement pour couper l’accès, puis évaluez dans une fenêtre définie (48 heures est raisonnable). C **Révoquer définitivement** L’agent était propre à la personne qui part, ou personne n’accepte de le prendre en charge. Révoquez l’accès, documentez la décision, et mettez-le hors service. ## Le volet conformité Le contrôle SOC 2 CC6.3 exige que l’accès soit retiré dès qu’il n’est plus nécessaire. Un agent dont le propriétaire est parti et dont l’accès n’a pas été revu est, par définition, un accès qui n’est peut-être plus nécessaire. Si un auditeur demande « comment vous assurez-vous que l’accès est retiré au départ d’un collaborateur » et que la réponse ne couvre pas les agents IA, c’est une faille dans le contrôle. Le règlement européen sur l’IA ajoute une couche. Son article 14 impose que les systèmes d’IA à haut risque intègrent des mécanismes permettant à des humains de superviser et d’intervenir. Un agent sans propriétaire et jamais découvert, qui tourne sur des données de production, n’a aucun humain dans la boucle. C’est une faille de responsabilité, pas seulement de sécurité. **La question que les auditeurs commencent à poser** Quand une personne qui a déployé des agents IA dans votre environnement s’en va, comment garantissez-vous que ces agents n’ont plus accès aux systèmes métier ? Si votre réponse est « on vérifie manuellement » ou « on ne sait pas trop », c’est là qu’est la faille. Le contrôle doit être systématique, pas au mieux de nos efforts. L’exigence pratique est simple : chaque agent IA de votre environnement doit avoir un propriétaire nommé dans votre système d’identité. Quand ce propriétaire fait l’objet d’un départ, l’agent est automatiquement signalé pour revue. La décision prise, quelle qu’elle soit, est consignée avec un horodatage et le nom du relecteur. Voilà à quoi ressemble un contrôle défendable. Ce qui rend l’exercice difficile, c’est l’étape de découverte. Vous ne pouvez signaler les agents d’une personne qui part que si vous savez quels agents existent. Un registre qui capte la création d’un agent dès l’origine est ce qui rend l’étape de départ traitable. Sans lui, vous faites toujours de l’archéologie : chercher les agents après coup, sans registre faisant autorité sur ce qui a été construit. --- # Okta, Azure AD, and Lutril: Who Manages Access When AI Agents Enter the Picture? > Okta et Azure AD sont excellents pour gérer l’identité humaine. Ni l’un ni l’autre n’a été conçu pour les agents IA. Voici la place de chacun, où sont les failles, et pourquoi il vous faut probablement les trois. Source: https://www.lutril.com/fr/blog/okta-azure-ad-vs-lutril-ai-agents Published: 2026-06-03 Topic: AI Governance --- ## La question que l’IT commence à poser La plupart des entreprises du mid-market et des grands comptes ont investi du temps pour bien faire leur IAM. Elles ont Okta ou Azure AD configuré en SSO sur tous leurs outils SaaS majeurs, le provisionnement SCIM branché sur leur SIRH, le MFA imposé partout, et des politiques de cycle de vie qui révoquent les accès quelques minutes après un événement de départ. Ce travail est réel, il compte, et il fonctionne bien. Puis l’équipe d’ingénierie ou d’exploitation déploie un agent IA. L’agent doit lire et écrire dans Salesforce. Il doit créer des tickets Jira, publier dans Slack, puiser dans une base de connaissances. Les demandes d’accès arrivent sur le bureau de l’IT, et le manuel habituel ne colle pas. L’agent n’est pas un humain. Il n’a pas de manager. Il n’a pas de cycle de vie qui corresponde à une embauche et à un départ. Il passe des dizaines ou des centaines d’appels d’outils par heure, guidé par la sortie d’un LLM plutôt que par une intention délibérée d’utilisateur. La question que l’IT commence à poser est : mon IAM actuel couvre-t-il cela, ou me faut-il autre chose ? La réponse honnête : votre IAM actuel est la bonne fondation, mais il ne couvre pas nativement les agents. Voici précisément ce que chaque produit prend en charge, et où se situe la frontière. ## Ce que fait Okta (et ce qu’il ne fait pas) Okta excelle réellement dans ce pour quoi il a été bâti. Ses capacités centrales sont profondes et éprouvées sur des milliers de déploiements en entreprise. - **L’authentification unique.** Le catalogue SSO d’Okta couvre des milliers d’intégrations SaaS. Les collaborateurs s’authentifient une fois et accèdent à toutes les applications connectées sans ressaisir d’identifiants. La couverture et la fiabilité sont ici parmi les meilleures du marché. - **La gestion du cycle de vie avec SCIM.** Quand une personne arrive ou part, Okta propage automatiquement le changement à toutes les applications connectées. Le déprovisionnement au départ est fiable et rapide, à condition que SCIM soit correctement configuré. - **Le MFA adaptatif.** L’authentification fondée sur le risque évalue des signaux comme la posture de l’appareil, le réseau et la localisation avant de décider de challenger une connexion. Cela attrape des attaques par identifiants qui passeraient à travers une politique de mots de passe statique. - **Les politiques d’accès par groupes.** Les attributions de rôles découlent des groupes, qui découlent de votre SIRH. Une nouvelle recrue en ingénierie reçoit automatiquement les bons outils. Une promotion d’analyste à manager déclenche les changements de rôle sans ticket manuel. Là où Okta s’arrête, c’est au concept d’identité d’agent. Son annuaire est un annuaire d’humains et, dans une moindre mesure, de comptes de service. Quand vous ajoutez un agent IA, le contournement courant consiste à créer un compte de service dans Okta, à lui donner un identifiant machine, et à l’affecter aux groupes applicatifs pertinents. Cela fonctionne au premier degré. L’agent peut s’authentifier. Il peut accéder aux outils SaaS que vous lui accordez. Ce qu’Okta n’a pas : un concept d’identité d’agent de plein droit, aucun mécanisme pour définir quels appels d’outils précis un agent peut effectuer au sein d’une application connectée, aucun journal d’audit consignant les séquences d’appels pilotées par un LLM, et aucun coupe-circuit capable d’arrêter une session d’agent en cours quand quelque chose dérape. Le contournement par compte de service a été conçu pour l’automatisation d’infrastructure, pas pour un agent piloté par LLM qui décide seul des actions à poser en fonction d’une tâche qu’on lui a confiée. **La faille du compte de service** Un compte de service dans Okta a un identifiant, un jeu d’appartenances à des groupes et une affectation applicative. Il n’a aucune notion du type « cet agent peut lire les contacts Salesforce mais pas modifier l’étape d’une opportunité ». Cette granularité n’existe nulle part dans le modèle de données actuel d’Okta. Il n’a pas non plus de piste d’audit reliant chaque appel d’outil à l’exécution d’agent qui l’a produit. ## Ce que fait Azure AD (Entra ID), et ce qu’il ne fait pas Microsoft a renommé Azure Active Directory en Microsoft Entra ID en 2023. Les capacités sous-jacentes sont solides, en particulier pour les organisations qui exploitent des charges Microsoft 365, de l’infrastructure Azure, ou les deux. - **Les politiques d’accès conditionnel.** L’accès conditionnel d’Entra ID est l’un des moteurs de politique les plus granulaires de l’IAM d’entreprise. Vous pouvez exiger des appareils conformes, des conditions réseau précises, ou une force d’authentification donnée selon la sensibilité de l’application et les signaux de risque de l’utilisateur. - **Les identités managées pour les charges Azure.** Pour les applications et services qui tournent dans Azure, les identités managées suppriment purement et simplement le besoin d’identifiants stockés. Une fonction Azure ou une VM reçoit une identité gérée par Azure, à laquelle vous attribuez des rôles RBAC. C’est bien conçu pour l’infrastructure native Azure. - **L’intégration Microsoft 365.** Pour les organisations déjà dans l’écosystème Microsoft, Entra ID offre avec SharePoint, Teams, Exchange et Dynamics une intégration profonde qu’Okta ne peut pas égaler nativement. - **Privileged Identity Management (PIM).** PIM permet l’activation de rôles juste-à-temps, avec des flux d’approbation et un accès limité dans le temps. Cela réduit les privilèges permanents sur les rôles sensibles. Pour les agents IA, le tableau ressemble à celui d’Okta. Les identités managées fonctionnent bien si vos agents sont hébergés dans Azure et n’appellent que des API Azure. Dès qu’un agent doit appeler des API SaaS hors de l’écosystème Azure, comme Salesforce, Notion, Slack ou n’importe quel service connecté en MCP, les identités managées ne s’y étendent pas. L’agent a besoin d’un identifiant ou d’un jeton OAuth distinct, géré en dehors d’Entra ID. Entra ID n’a pas de couche de politique pour les appels d’outils MCP. Il ne peut pas imposer qu’un agent ait le droit d’envoyer un message Slack sans pouvoir supprimer un canal. Il ne capte pas les séquences d’appels au niveau de l’agent. Ses journaux d’audit consignent les événements d’authentification et l’accès aux ressources au niveau du RBAC Azure, pas la sémantique de ce qu’un agent piloté par LLM a décidé de faire de l’accès qu’on lui a accordé. **Identité managée ou identité d’agent** Une identité managée prouve que « cette ressource de calcul Azure est bien celle qu’elle prétend être ». C’est un problème résolu pour les charges Azure. Ce qu’elle n’offre pas, c’est un modèle de gouvernance du comportement du code qui tourne sur cette ressource : quels outils il appelle, dans quel ordre, sous quelle autorisation, et avec quelle piste d’audit sur l’ensemble de l’exécution. ## La faille que les deux laissent ouverte Okta et Azure AD ont été bâtis avant que les agents LLM n’existent comme réalité déployée. Ces failles ne sont pas des défauts d’exécution. Elles reflètent une frontière de périmètre qui avait tout son sens jusqu’à récemment. Aucun des deux produits ne prend aujourd’hui en charge : - **L’identité d’agent dans l’annuaire.** Il n’existe pas de type d’objet de plein droit « agent IA », avec des propriétés comme l’équipe propriétaire, la finalité, les outils autorisés et la durée de session. Le compte de service est un contournement, pas une réponse adaptée. - **L’application d’une politique par appel d’outil.** Ni Okta ni Azure AD ne savent exprimer ni faire respecter une politique du type « cet agent peut lire les fiches du CRM mais pas modifier l’étape d’une opportunité ». Les permissions au niveau applicatif sont grossières. La granularité requise pour gouverner des agents n’existe pas dans le modèle IAM actuel. - **Des journaux d’audit inaltérables pour les appels d’outils d’un LLM.** Quand un agent exécute une tâche en plusieurs étapes et appelle dix API à la suite, les journaux d’audit IAM existants consignent l’événement d’authentification. Ils ne consignent ni la séquence d’appels, ni la décision du LLM qui a précédé chaque appel, ni les données renvoyées. Cette trace disparaît à la fin de la session. - **Des coupe-circuits pour les agents en cours d’exécution.** Si un agent se comporte de façon inattendue en pleine tâche, il n’existe aucun mécanisme dans Okta ou Azure AD pour arrêter cette session précise sans révoquer l’accès de tout le compte de service, ce qui peut affecter des systèmes sans rapport. - **La parité de rôles entre humains et agents.** Dans un environnement bien gouverné, un humain disposant d’un accès en lecture seule à un système devrait se traduire par un agent doté du même accès en lecture seule. Cette correspondance n’existe pas. L’accès de l’agent se configure indépendamment des définitions de rôles humains qu’il est censé refléter. Ce ne sont pas des cas marginaux. Ce sont les exigences de gouvernance de base pour toute organisation qui veut étendre sa posture de sécurité existante aux agents IA. ## Comment ils se comparent Sur les dimensions qui comptent pour une gouvernance des accès complète : | Dimension | Okta | Azure AD / Entra ID | Lutril | | --- | --- | --- | --- | | SSO humain | Excellent | Excellent | Sans objet | | Cycle de vie humain (SCIM) | Excellent | Excellent | Via intégration | | MFA / accès adaptatif | Excellent | Excellent | Sans objet | | Identité d’agent IA | Non | Non | Oui | | Application de politique native MCP | Non | Non | Oui | | Journal d’audit par appel d’outil | Non | Non | Oui | | Coupe-circuit d’agent | Non | Non | Oui | | Parité de rôles (humains et agents) | Non | Non | Oui | La bonne façon de lire ce tableau : les cases « Sans objet » de la colonne Lutril, sur les lignes d’identité humaine, ne sont pas des manques. Lutril ne cherche pas à remplacer Okta ou Azure AD pour le SSO et le cycle de vie des humains. Ce travail est déjà fait, et le refaire ne crée aucune valeur. Le tableau reflète un périmètre, pas une concurrence. ## Pourquoi il vous faut les trois La bonne architecture est en couches. Okta ou Azure AD prend en charge ce pour quoi il a été bâti : authentification des humains, gestion du cycle de vie, MFA, accès par groupes. Cette couche est solide et doit rester en place. Lutril se pose par-dessus, comme couche de gouvernance des agents. Plutôt que de remplacer votre IdP, Lutril lit les définitions de rôles et de groupes de votre Okta ou Azure AD existant et s’en sert comme source de vérité pour déterminer ce que les agents ont le droit de faire. Si un analyste Salesforce n’a qu’un accès en lecture dans votre IdP, un agent agissant en son nom hérite du même accès en lecture. La parité est appliquée automatiquement, pas configurée à la main agent par agent. Au-dessus de cette source de vérité, Lutril applique une politique par appel d’outil via MCP. Quand un agent tente un appel, la politique est vérifiée avant exécution : cet agent a-t-il le droit d’exécuter cet outil précis, à ce moment, dans ce contexte de tâche ? Si non, l’appel est bloqué et journalisé. Si oui, l’appel se poursuit et tout le contexte est inscrit dans une trace d’audit inaltérable. L’intégration fonctionne aussi dans l’autre sens. Quand une personne fait l’objet d’un départ dans votre IdP, Lutril voit le changement et révoque ou suspend tout agent qui opérait en son nom. Vous n’avez pas besoin de construire un flux de départ distinct pour les agents. Le cycle de vie humain existant déclenche celui des agents. ## Quand ajouter une couche d’accès pour les agents Quelques déclencheurs précis indiquent le moment où le contournement par compte de service cesse d’être suffisant : - **Le premier agent IA avec accès à un SaaS.** Dès qu’un agent peut écrire dans un système de production, le profil de risque change. Un accès en lecture seule à de la documentation interne n’engage pas grand-chose. Un accès en écriture à Salesforce, à Jira ou à tout système contenant des données clients demande une gouvernance qu’un compte de service ne peut pas fournir. - **La première question d’audit SOC 2 ou ISO 27001 sur les agents.** Les auditeurs commencent à interroger les contrôles d’accès des agents IA. « Nous avons un compte de service » ne satisfait pas les critères de contrôle d’accès du CC6.1 ou de l’A.9 quand cet accès est exercé par un comportement autonome piloté par un LLM. Il faut une trace de politique, un journal d’audit, et la preuve d’une limitation de portée. - **Le premier départ d’une personne qui avait provisionné des agents.** Quand l’ingénieur qui a monté l’agent s’en va, qui sait ce que cet agent peut faire ? Si la réponse est personne, l’agent survit à celui qui le comprenait. C’est le problème du shadow IT, appliqué à des systèmes autonomes. - **Plus d’une équipe qui déploie des agents.** Quand plusieurs équipes ont des agents en production, la surface de gouvernance grandit plus vite que la capacité à la suivre manuellement. Une couche de politique centrale devient nécessaire à ce stade, et non plus optionnelle. Si aucun de ces cas ne s’applique encore, l’approche par compte de service peut suffire pour l’instant. Dès que l’un d’eux se présente, c’est le bon moment pour ajouter une gouvernance d’agents dédiée, plutôt que d’étirer un modèle d’identité humaine au-delà de ce pour quoi il a été conçu. --- # How to Connect Claude to Slack via MCP with Access Controls > Enregistrez un agent Claude dans Lutril, connectez Slack comme application MCP, rattachez l’intégration avec la bonne portée, et configurez Claude pour l’utiliser. Chaque appel d’outil journalisé dès le départ. Source: https://www.lutril.com/fr/blog/connect-claude-slack-mcp-lutril Published: 2026-06-03 Topic: Tutorial --- ## Vue d’ensemble Lutril se place entre Claude et Slack comme proxy MCP. Claude appelle les outils à travers Lutril plutôt que de détenir directement un jeton Slack. Lutril vérifie que l’agent appelant dispose d’un rattachement à Slack, transmet l’appel, et inscrit une trace inaltérable au journal d’activité. La configuration comporte quatre pièces : la connexion de l’application MCP Slack (OAuth), l’enregistrement de l’agent, le rattachement qui donne à l’agent l’accès à Slack, et la configuration de Claude qui pointe vers le serveur MCP de Lutril. Ce guide les parcourt une par une. ## Prérequis **Un compte Lutril** avec un accès administrateur ou membre **Un espace Slack** où vous pouvez autoriser une nouvelle application **Claude Desktop** ou un projet utilisant l’API Claude avec la prise en charge MCP - 1Connecter Slack comme application MCP ## Connecter Slack comme application MCP Avant qu’un agent puisse appeler des outils Slack, votre espace de travail doit autoriser Lutril à accéder à Slack en son nom. C’est une étape OAuth unique, effectuée par un administrateur. Dans Lutril, allez dans **MCP Apps**. Vous y voyez les intégrations disponibles : Slack, HubSpot, Notion, Mixpanel et d’autres. Trouvez la carte Slack et cliquez sur **Connecter**. Vous êtes redirigé vers le parcours OAuth de Slack. Lutril demande ces scopes : - `channels:read` : lister les canaux publics - `channels:history` : lire l’historique des messages des canaux publics - `chat:write` : publier des messages en tant que bot Lutril - `users:read` : résoudre les identifiants d’utilisateurs en noms dans les journaux d’activité Après autorisation, la carte Slack affiche un badge **Connecté** avec la date de connexion. Lutril détient désormais l’identifiant Slack. Les agents, eux, ne le détiennent pas : ils demandent l’accès par des rattachements, que vous ajoutez à l’étape suivante. - 2Enregistrer l’agent ## Enregistrer l’agent dans le registre Allez dans le **Registre des agents** et cliquez sur **Enregistrer un agent**. Remplissez le formulaire : Enregistrer un agent Nom de l’agent claude-slack-assistant Propriétaire vous@entreprise.com Finalité Lit les canaux Slack et publie des synthèses dans #ai-updates Expire le dans 90 jours (maximum) Étiquettes slack, comms Cliquez sur **Enregistrer**. Lutril crée l’agent à l’état `draft` et génère un jeton MCP. **Ce jeton n’est affiché qu’une seule fois.** Copiez-le avant de fermer la fenêtre. Jeton MCP : à copier maintenant agt_7fRxP2kq8m@tenant_4hJnW:sk_live_•••••••••••••••••••••••• Ce secret n’est pas conservé et ne peut plus être récupéré. Faites-le tourner depuis la fiche de l’agent si nécessaire. La fenêtre affiche aussi deux extraits de configuration : un pour Claude Code et un pour `.mcp.json`. Copiez celui qui correspond à votre installation, il servira à l’étape 4. - 3Ajouter un rattachement Slack ## Ajouter un rattachement Slack à l’agent L’agent existe, mais il n’a encore accès à rien. Cliquez sur sa ligne pour ouvrir sa fiche, puis allez dans l’onglet **Rattachements**. Cliquez sur **Ajouter un rattachement**, sélectionnez **Slack** dans la liste des intégrations, choisissez une portée, et confirmez. Deux portées possibles : Slack lecture Lister les canaux, lire l’historique des messages. Aucune publication possible. Slack lecture + écriture L’accès en lecture, plus la possibilité de publier des messages. Pour un assistant Slack qui lit les canaux et publie des synthèses, choisissez **lecture + écriture**. Le score de risque de l’agent se met à jour automatiquement une fois le rattachement enregistré. Activez maintenant l’agent. De retour dans l’onglet **Vue d’ensemble**, cliquez sur **Activer**. L’état passe de `draft` à `active`. L’agent peut désormais appeler les outils Slack via Lutril. - 4Configurer Claude ## Configurer Claude pour qu’il utilise Lutril Le serveur MCP de Lutril expose toutes vos intégrations connectées sous forme d’outils. Vous y pointez Claude à l’aide du jeton MCP de l’étape 2. Pour **Claude Desktop**, ouvrez `~/Library/Application Support/Claude/claude_desktop_config.json` et ajoutez : ``` claude_desktop_config.jsonjson { "mcpServers": { "lutril": { "command": "npx", "args": ["-y", "@lutril/mcp-server@latest"], "env": { "LUTRIL_MCP_TOKEN": "agt_7fRxP2kq8m@tenant_4hJnW:sk_live_..." } } } } ``` Pour **Claude Code** ou une configuration au niveau du projet, utilisez `.mcp.json` à la racine du projet : ``` .mcp.jsonjson { "servers": { "lutril": { "type": "stdio", "command": "npx", "args": ["-y", "@lutril/mcp-server@latest"], "env": { "LUTRIL_MCP_TOKEN": "${LUTRIL_MCP_TOKEN}" } } } } ``` Gardez le jeton dans une variable d’environnement plutôt que de le committer en clair. Redémarrez Claude Desktop après avoir enregistré la configuration. - 5Tester et surveiller ## Tester et consulter le journal d’activité Demandez à Claude quelque chose qui nécessite un accès à Slack. Claude invoquera l’outil correspondant via Lutril, et vous verrez les appels apparaître en temps réel sous **Activité MCP**. - agt_7fRxP2 list_channels24 canaux renvoyés Slack Succès 41 ms - agt_7fRxP2 get_messages#general · 50 messages Slack Succès 178 ms - agt_7fRxP2 post_message#ai-updates · synthèse publiée Slack Succès 94 ms Chaque ligne se déplie. Cliquez dessus pour voir les paramètres d’entrée complets, la charge utile de la réponse, et l’acteur à l’origine de l’appel. Chaque entrée est inaltérable et exportable à des fins de conformité. Si l’agent tente d’utiliser une intégration pour laquelle il n’a pas de rattachement, l’appel est bloqué et une **demande d’accès** est créée automatiquement dans l’onglet correspondant. Un administrateur peut l’approuver ou la refuser depuis là, avec une date d’expiration facultative. ## Gérer le cycle de vie de l’agent Quelques points utiles pour la gestion au quotidien : - **Expiration.** Un agent doit avoir une date d’expiration (90 jours au maximum). À l’expiration, il cesse de fonctionner et doit être renouvelé explicitement. C’est volontaire : cela force une revue périodique de sa raison d’être. - **Suspension.** Un administrateur peut suspendre un agent immédiatement depuis le registre. Tout accès à Slack s’arrête. La réactivation se fait aussi en un clic. - **Rotation du jeton.** Si le jeton MCP est compromis, allez sur la fiche de l’agent et renouvelez l’identifiant. L’ancien jeton bénéficie d’une fenêtre de grâce de 24 heures, puis devient invalide. - **Départ du propriétaire.** Si le propriétaire de l’agent quitte l’entreprise, Lutril signale l’agent pour réattribution. L’accès ne se poursuit pas silencieusement sous un utilisateur déprovisionné. Identité de l’agent Chaque appel d’outil est attribué à `agt_7fRxP2` dans le journal d’activité, et non à un jeton Slack brut. Application de la portée L’agent ne peut appeler que les outils couverts par ses rattachements. Tout le reste est bloqué et journalisé comme demande d’accès. Piste d’audit Un journal inaltérable de chaque appel, avec tout son contexte. Exportable comme preuve SOC 2. Coupe-circuit Suspendez l’agent depuis le registre. L’accès à Slack s’arrête immédiatement, dans tous les environnements qui utilisent ce jeton. --- # Employee Offboarding Security: What Access Actually Gets Removed > 41% des collaborateurs conservent un accès aux systèmes de l’entreprise après leur départ. L’essentiel de ces accès vit dans des outils SaaS que votre IdP n’a jamais touchés. Voici ce qu’exige réellement une révocation complète. Source: https://www.lutril.com/fr/blog/employee-offboarding-security Published: 2026-06-03 Topic: Offboarding --- ## La faille des départs Quand une personne part, l’IT reçoit un ticket. Elle désactive le compte Okta, révoque peut-être un certificat VPN, et marque la tâche comme faite. Trente minutes un bon jour. Le problème, c’est que le compte Okta n’est qu’une couche d’accès parmi d’autres. Un profil de travailleur du savoir accumule des dizaines d’identifiants indépendants au fil de son passage dans l’entreprise : applications ouvertes avec Google, outils provisionnés directement par l’IT, clés d’API générées, intégrations configurées. Rien de tout cela ne disparaît quand Okta s’éteint. - **41%**: des partants conservent un accès - **3–5**: jours en moyenne pour un retrait complet - **30%**: des SaaS non gérés en SSO ## Ce qui survit à la désactivation du SSO Le SSO et SCIM résolvent le problème pour lequel ils ont été conçus : l’identité fédérée pour les applications qui la prennent en charge. Cela couvre bien votre socle. Cela ne couvre pas tout, et l’écart est plus large que ne le pensent la plupart des équipes IT. État des accès après déprovisionnement SSO Type d’accès Exemples État Applications fédérées en SSO Jira, Confluence, Salesforce (SSO) Révoqué Applications OAuth Google Notion, Loom, Figma (connexion Google) Toujours actif SaaS en connexion directe Outils historiques, portails fournisseurs Toujours actif Clés d’API qu’elle a générées Jetons HubSpot, Stripe, AWS Toujours actif Agents IA qu’elle a provisionnés Agents utilisant ses identifiants Toujours actif Identifiants partagés Comptes d’équipe, accès fournisseurs Inconnu Les applications OAuth sont le plus grand angle mort. Une personne qui s’est connectée à Notion avec son compte Google pendant qu’elle était en poste conservera indéfiniment l’accès à cet espace Notion après la désactivation de son compte Google, si ce compte a été désactivé sans que la session ou le jeton Notion n’aient été explicitement révoqués. Plus important encore : l’IT ignore souvent quelles applications relèvent de quelle catégorie. L’étape de découverte manque à la plupart des checklists de départ. ## La fenêtre d’exposition Même avec les bons processus, le calendrier compte. Il y a toujours un écart entre le dernier jour d’une personne et le moment où le retrait complet des accès est confirmé. En pratique, cet écart se mesure souvent en jours ou en semaines, pas en heures. Les risques qui vivent dans cette fenêtre ne sont pas théoriques. Une personne partie qui garde un accès résiduel au CRM, au code source ou aux systèmes financiers représente une exposition réelle. La plupart des incidents de sécurité attribués à d’anciens collaborateurs ne relèvent pas d’attaques sophistiquées. Ils relèvent de quelqu’un qui se sert d’identifiants jamais révoqués. Cette fenêtre a trois causes : - **Des chaînes de tickets manuelles.** Un départ déclenche une série de tâches réparties entre plusieurs équipes. Chaque passage de relais est une occasion de retard ou d’oubli. - **Un inventaire incomplet.** Vous ne pouvez révoquer l’accès qu’aux outils dont vous savez qu’ils étaient utilisés. Le shadow IT rend l’inventaire toujours incomplet. - **Aucune étape de vérification.** La plupart des processus de départ n’ont aucun mécanisme confirmant que tous les accès ont été retirés, seulement que le ticket a été clos. ## Ce que couvre un départ traité complètement Un départ traité complètement couvre plus de terrain que la plupart des checklists IT. Par ordre de priorité approximatif : - Déprovisionnement dans l’IdP. Désactivez le compte SSO et déclenchez le déprovisionnement SCIM pour toutes les applications fédérées. Cela devrait se faire automatiquement, idéalement à partir d’un événement du SIRH. - Révocation des jetons OAuth. Révoquez toutes les autorisations OAuth accordées par la personne, sur l’ensemble des applications connectées. Cela suppose une découverte préalable : il faut savoir quelles connexions OAuth existent avant de pouvoir les révoquer. - Rotation des clés d’API. Identifiez puis renouvelez ou révoquez toutes les clés d’API que la personne a générées dans les outils où elle avait un accès administrateur ou développeur. - Suppression des SaaS en connexion directe. Supprimez les comptes dans les outils qui ne sont pas gérés en SSO. Cela suppose de savoir à quels outils la personne avait accès indépendamment de l’IdP. - Déprovisionnement des agents IA. Suspendez ou réattribuez tous les agents IA que la personne a provisionnés, ou qui fonctionnaient avec ses identifiants. - Rotation des identifiants partagés. Tout mot de passe partagé ou compte de service auquel la personne avait accès doit être renouvelé. Cette étape saute souvent, faute d’un inventaire propre des identifiants partagés. - Audit de vérification. Un contrôle final confirmant que la personne n’apparaît plus comme utilisateur actif dans aucun système. C’est cette étape qui fait passer le départ du statut de processus à celui de contrôle. ## La complication des agents IA La plupart des checklists de départ ont été écrites avant que les agents IA ne deviennent une composante ordinaire du travail. Elles n’ont pas été mises à jour. Quand une personne met en place un agent IA, elle le provisionne en général avec ses propres identifiants : sa clé d’API, son jeton OAuth, son compte de service. L’agent agit en son nom. Quand elle part, l’agent ne s’arrête pas de lui-même. Tant que personne ne sait qu’il existe et ne le déprovisionne explicitement, il continue de tourner avec un accès censé avoir expiré. Ce n’est pas une hypothèse d’école. Les équipes commerciales font tourner des agents sur les données du CRM. Les ingénieurs en montent avec accès aux dépôts. Les équipes financières en branchent sur les systèmes de facturation. Chacun de ces agents est un chemin d’accès persistant que le ticket de départ standard ne rattrapera pas. Le correctif suppose de faire des agents des entités de plein droit dans votre modèle d’accès : des identités enregistrées, avec un propriétaire, plutôt que des clés d’API anonymes. Au départ du propriétaire, l’agent doit être suspendu automatiquement, ou réattribué avec une étape de revue explicite. ## Du manuel au systématique Si la sécurité des départs échoue, c’est parce qu’elle repose sur des humains qui doivent exécuter correctement une checklist, sous contrainte de temps, avec des informations incomplètes, à chaque départ. Ce modèle ne passe pas à l’échelle et ne produit pas de résultats constants. Un traitement systématique relie le retrait des accès directement à l’événement RH. Dès qu’un départ est enregistré dans le SIRH, le flux de retrait démarre automatiquement. Il n’attend pas de ticket. Il n’exige de personne qu’il se souvienne de la checklist. Il se déclenche à chaque départ, y compris ceux du vendredi à 17 heures. Le problème d’inventaire, cette étape de découverte que la plupart des checklists sautent, est la partie la plus difficile à automatiser. On ne retire pas l’accès à des outils dont on ignore l’existence. Cela demande une découverte SaaS continue, qui court en amont de l’événement de départ, et non un audit manuel déclenché par lui. --- # Shadow IT: Your IT Team Knows About 40 SaaS Apps. You Have 130. > Le shadow IT n’est pas un échec de politique interne. C’est le résultat naturel d’une adoption SaaS sans friction. Voici pourquoi il ne cesse de croître, quel risque de sécurité et de conformité il crée réellement, et quoi faire au-delà d’une charte que personne ne lit. Source: https://www.lutril.com/fr/blog/shadow-it-risks Published: 2026-06-03 Topic: Shadow IT --- ## Ce qu’est réellement le shadow IT aujourd’hui Le shadow IT, autrefois, c’était une équipe qui montait un serveur non autorisé, ou quelqu’un qui branchait une clé USB personnelle. Ce cadrage a vieilli. Aujourd’hui, le shadow IT est presque intégralement du SaaS : des outils que les collaborateurs adoptent de leur côté, sans passer par la validation de l’IT, les achats ou la revue de sécurité. Vu de l’intérieur, ça ne ressemble pas à une infraction. Ça ressemble à une personne du marketing qui ouvre un compte Notion gratuit pour organiser une campagne. À un développeur qui branche un dépôt GitHub sur un nouvel outil de CI pour livrer plus vite. À un dirigeant qui rédige des documents de conseil d’administration avec son abonnement ChatGPT personnel. Chaque décision prise isolément est raisonnable. Leur somme est une surface d’exposition vaste, non gérée et invisible. - **3x**: plus d’applications que ce que l’IT connaît - **2–3**: nouvelles applications par collaborateur / mois - **80%**: via une inscription Google ou par e-mail ## Comment il se répand La raison structurelle pour laquelle le shadow IT ne cesse de croître, c’est que s’inscrire à un nouvel outil SaaS est devenu trivial. Un bouton « Se connecter avec Google », une adresse professionnelle, et vous avez un compte actif en moins de 60 secondes. Aucun ticket, aucune validation, aucun cycle d’achat. Trois schémas expliquent l’essentiel : - **La connexion OAuth.** Les collaborateurs branchent de nouveaux outils avec leur identité Google ou Microsoft. Cela crée une session active dans un outil que votre IdP n’a jamais touché et dont il ignore peut-être l’existence. - **Les offres gratuites.** La plupart des produits SaaS ont un palier gratuit qui n’implique jamais l’entreprise. L’outil démarre comme une expérimentation personnelle et devient un flux de travail d’équipe avant que l’IT n’en entende parler. - **La diffusion en équipe.** Une personne adopte un outil, le trouve utile, et le partage avec son équipe. Quand l’IT le découvre, il y a 20 utilisateurs actifs et de vraies données métier à l’intérieur. Des politiques imposant une validation avant l’adoption d’un nouvel outil existent dans la plupart des entreprises. Elles ne ralentissent pas l’adoption du SaaS, parce que la friction du processus dépasse celle qui consiste à s’inscrire et à voir plus tard. ## Les vrais risques Le risque lié au shadow IT est présenté comme un problème de conformité, et il l’est. Mais ce cadrage minimise ce qui est réellement en jeu. **Des données dont vous ne pouvez pas rendre compte** Quand un collaborateur téléverse des données clients dans un outil d’écriture assistée par IA en offre gratuite, ces données quittent votre environnement et atterrissent dans un système tiers avec lequel vous n’avez ni contrat, ni accord de traitement, ni moyen d’audit. L’article 28 du RGPD impose un accord de traitement avec chaque sous-traitant qui manipule des données personnelles. Le shadow IT crée des sous-traitants dont vous ignorez l’existence. **Des accès que vous ne pouvez pas révoquer** Chaque outil de shadow IT est un compte que votre processus de départ manquera. Quand une personne quitte l’entreprise, son espace Notion, son compte Grammarly qui a accès à tout ce qu’elle a écrit et son abonnement ChatGPT personnel avec ses documents téléversés restent tous actifs. Ces comptes survivent au départ parce qu’ils n’ont jamais été dans le périmètre. **Des preuves d’audit que vous ne pouvez pas produire** SOC 2 et ISO 27001 vous demandent de démontrer que l’accès aux systèmes contenant des données sensibles est maîtrisé. Les outils de shadow IT sont des systèmes contenant des données sensibles, avec zéro contrôle d’accès. Un auditeur qui échantillonne les accès réels des collaborateurs trouvera des comptes dans des outils qui n’ont jamais figuré dans une revue d’accès. ## Ce que révèle vraiment une analyse de shadow IT La plupart des équipes IT sont surprises par les résultats de leur première analyse complète. Non pas parce que les outils sont exotiques, mais à cause du volume et de ce qu’ils contiennent. - ChatGPT (personnel) 38 Documents internes, données clients Élevé - Notion (comptes personnels) 21 Données de projet, notes clients Élevé - Grammarly 89 Tout le contenu rédigé Moyen - Loom (offre gratuite) 14 Enregistrements d’écran, démos Moyen - Zapier (personnel) 7 Données CRM et e-mail Élevé C’est le résultat Grammarly qui surprend le plus. 89 utilisateurs, cela signifie que la quasi-totalité de vos profils rédactionnels dispose d’une extension de navigateur ayant accès à tout ce qu’ils tapent, reliée à un service tiers via des comptes personnels. Ce n’est pas malveillant. C’est simplement invisible pour l’IT jusqu’à ce qu’une analyse le mette au jour. ## Encadrer plutôt que bloquer Le réflexe après une analyse de shadow IT est de bloquer. Révoquer les autorisations OAuth, durcir les politiques de navigateur, resserrer le processus de validation. Ce réflexe produit deux effets : les collaborateurs trouvent des contournements, et des outils de productivité légitimes tombent dans le filet. Une approche plus efficace distingue les outils selon leur niveau de risque et les traite en conséquence : | Catégorie | Approche | Pourquoi | | --- | --- | --- | | Risque élevé, aucun usage métier | Bloquer et expliquer pourquoi | Réduire la surface d’exposition là où aucun besoin légitime n’existe | | Risque élevé, usage métier avéré | Passer en mode géré, en priorité | Les équipes l’utiliseront de toute façon. Autant avoir un accord de traitement et du SSO | | Risque moyen, usage très répandu | Adopter et encadrer | Bloquer 89 utilisateurs de Grammarly crée plus de friction que de valeur | | Risque faible, usage limité | Surveiller et revoir chaque trimestre | Le coût du contrôle ne vaut pas un risque minime | L’objectif n’est pas le zéro shadow IT. C’est hors d’atteinte sans bloquer la productivité. L’objectif, c’est un shadow IT connu : une photo continue et à jour des outils qui existent, de qui les utilise et des données qu’ils touchent, pour arbitrer le risque au lieu de découvrir les problèmes pendant un audit. ## Le lien avec les départs Shadow IT et gestion des départs sont le même problème vu sous deux angles. Le shadow IT est le problème de découverte : vous ne savez pas quels outils une personne utilise. Le départ est le problème de remédiation : vous ne pouvez pas retirer un accès à des outils que vous ne connaissez pas. Chaque outil de shadow IT utilisé par un collaborateur est un compte qui survivra à son départ. L’espace Notion, l’abonnement ChatGPT personnel avec ses documents téléversés, le compte Zapier qui achemine des données CRM vers une adresse personnelle. Aucun n’apparaît sur le ticket de départ standard. Tous restent actifs quand le compte Okta s’éteint. Résoudre le shadow IT est donc un préalable à un départ traité de bout en bout. C’est la découverte continue, qui court en amont de chaque départ, qui rend la checklist de sortie exacte plutôt qu’approximative. --- # SOC 2 Wants Proof. Not a Spreadsheet. > La plupart des revues d’accès sont une formalité. Les managers approuvent sans contexte, le shadow IT n’est jamais revu, et les preuves sont minces. Voici ce qu’exigent réellement SOC 2 et ISO 27001, et à quoi ressemble le fait de combler l’écart. Source: https://www.lutril.com/fr/blog/access-reviews-soc2-iso27001 Published: 2026-06-03 Topic: Compliance --- ## Sur le papier, votre revue d’accès fonctionne Chaque trimestre, quelqu’un de l’équipe sécurité envoie un tableur à 40 managers. Les managers sont occupés, incertains de ce que leurs équipes utilisent vraiment, et flous sur ce que « revoir » veut dire. Ils cochent « approuvé » sur la plupart des lignes et renvoient le fichier. Quelqu’un collecte les réponses. Le dossier de preuves d’audit gagne une pièce jointe de plus. C’est ainsi que la plupart des entreprises mènent leurs revues d’accès aujourd’hui. Cela satisfait la lettre de l’exigence. Cela satisfait de moins en moins les auditeurs, et sûrement pas l’esprit de ce que demandent SOC 2 et ISO 27001. ## Ce que les référentiels exigent réellement SOC 2 et ISO 27001 se soucient de la même question de fond : **pouvez-vous prouver que les accès sont maîtrisés, appropriés, et retirés lorsqu’ils n’ont plus lieu d’être ?** - SOC 2CC6.2 L’accès logique aux composants du système est réservé aux utilisateurs autorisés. Les nouveaux comptes ne sont créés qu’avec l’autorisation appropriée. L’accès se limite au strict nécessaire pour le rôle de la personne. - SOC 2CC6.3 L’accès logique est retiré ou modifié dans un délai raisonnable dès qu’il n’est plus nécessaire : départs, changements de poste, évolution des besoins métier. - ISO 27001A.8.2 Les droits d’accès de tous les collaborateurs et prestataires sont revus à intervalles réguliers. Ils sont ajustés ou révoqués dès qu’ils ne sont plus appropriés, après un changement de poste ou un départ. - ISO 27001A.8.3 Tous les droits d’accès des collaborateurs et prestataires sont retirés à la fin ou à l’expiration du contrat de travail, de la prestation ou de l’accord. La distinction déterminante pour SOC 2 se joue entre le **Type I** et le **Type II**. Le Type I dit : « nous avons des contrôles conçus pour satisfaire ces critères ». Le Type II dit : « ces contrôles ont fonctionné efficacement sur toute la période auditée ». Pour les revues d’accès, le Type II impose de démontrer que les revues ont bien eu lieu, qu’elles étaient complètes, et qu’elles ont donné lieu à des retraits, de façon constante sur 6 à 12 mois. « Nous avons une politique » est une réponse de Type I à une question de Type II. ## Trois façons dont les revues d’accès échouent en pratique **Échec 1 : la faille de couverture** Votre IdP vous montre les applications qu’il gère. Mais dans la plupart des entreprises, l’adoption du SaaS a devancé le déploiement du SSO. Les collaborateurs s’inscrivent avec une connexion Google, utilisent des comptes personnels, ou sont provisionnés directement dans des outils non fédérés. Résultat : votre revue d’accès ne couvre qu’une fraction des accès réels. Pendant un audit SOC 2, un utilisateur échantillonné dans Salesforce, Notion ou HubSpot aura souvent des comptes hors périmètre. C’est un constat d’audit. **Échec 2 : la faille de contexte** L’e-mail de revue arrive chez un manager. Il voit : « Sarah Chen : Salesforce, HubSpot, Notion, Jira, Linear, Figma, Loom, GitHub ». Quarante lignes de ce type pour chaque personne de son équipe. Ce à quoi il doit répondre, c’est : Sarah a-t-elle encore besoin de tout cela ? La plupart des managers l’ignorent. Ils ne savent pas que Sarah ne s’est pas connectée à Figma depuis 3 mois, ni que ses droits d’administration Salesforce ont été élargis pour un projet terminé au premier trimestre. Alors ils approuvent tout. La revue devient une formalité. **Échec 3 : la faille de remédiation** Même quand un manager signale quelque chose à retirer, l’action ne suit pas toujours. Un commentaire dans le tableur dit « révoquer l’admin Salesforce de Tom ». Deux semaines plus tard, Tom est toujours administrateur Salesforce. Aucun lien n’existe entre la décision de revue et le système de provisionnement. Une preuve SOC 2 d’une revue qui a identifié des exceptions sans les corriger est pire qu’une absence de revue : elle montre que vous saviez et que vous n’avez rien fait. ## À quoi ressemble une bonne preuve Ce que les auditeurs veulent voir, c’est une boucle fermée : découverte → revue → décision → remédiation → preuve. Chaque étape traçable, horodatée, et attribuable à un relecteur nommé. Voici à quoi ressemble une campagne de revue structurée, quand les données sont réellement là pour la soutenir : - Utilisateur Accès Dernière activité Décision Relecteur - Sarah Chen GitHub · Notion · Jira · Linear il y a 2 jours Conserver M. Torres - Tom Okafor GitHub · Salesforce (admin) · AWS il y a 94 jours Révoquer l’admin M. Torres - Priya Nair Figma · Notion · Linear il y a 61 jours Révoquer Figma M. Torres - James Wu GitHub · Jira · Confluence · AWS hier Conserver M. Torres - Amara Diallo HubSpot · Notion · Slack il y a 4 jours En attente non attribué C’est la colonne « dernière activité » qui fait la différence entre une vraie revue et un tampon. Sans elle, un manager qui examine les accès de Tom n’a aucune base de décision. Avec elle, « il y a 94 jours » sur un compte administrateur Salesforce saute aux yeux. Pour l’audit, l’export de cette revue doit montrer : - Périmètre : quels utilisateurs et quels systèmes étaient couverts sur la période - Complétude : qui a revu quoi, avec horodatage et identité du relecteur - Exceptions : ce qui a été signalé pour retrait ou rétrogradation, et pourquoi - Remédiation : la preuve que les accès signalés ont bien été retirés, avec horodatage - Failles de couverture : les outils SaaS dont les accès n’ont pas été revus faute d’être dans le périmètre. Les auditeurs les cherchent. ## La question de la fréquence SOC 2 ne prescrit pas de cadence précise, mais la plupart des auditeurs attendent une revue trimestrielle pour les accès à privilèges et au moins annuelle pour les utilisateurs standard. ISO 27001 dit « à intervalles réguliers », ce qui s’interprète généralement comme trimestriel ou semestriel selon votre profil de risque. La question la plus utile est : **pourquoi la fréquence est-elle la contrainte ?** La cadence trimestrielle est un artefact du processus manuel. Collecter les données d’accès, construire des tableurs, relancer les managers, réconcilier les retraits. C’est assez long pour qu’une fréquence supérieure soit hors de portée. Mais le risque sous-jacent, lui, est continu. Quelqu’un change de poste un mardi de février. La revue suivante n’est qu’en avril. Pendant deux mois, il détient un accès qu’il ne devrait plus avoir. Quand les données d’accès sont vivantes et les campagnes automatisées, les revues peuvent se déclencher sur événement : un changement de poste, une fin de projet, 60 jours d’inactivité, plutôt que sur le seul calendrier. La revue trimestrielle devient alors un artefact de conformité qui confirme ce que la surveillance continue a déjà repéré, au lieu d’être la première ligne de découverte. C’est toute la différence entre la revue d’accès comme exercice de conformité et la revue d’accès comme véritable contrôle. --- # Aircall + Lutril: setup guide > Lutril se connecte à Aircall avec un API ID et un API Token (l’identifiant et le mot de passe de l’authentification Basic), ce qui lui permet de lire et de gérer vos utilisateurs Aircall. Source: https://www.lutril.com/fr/integrations/aircall Category: Communication Auth: api_key Last verified: 2026-06-17 --- ## Setup 1. Connectez-vous au tableau de bord Aircall avec des droits Admin ou Owner. 2. [object Object] 3. Aircall génère deux chaînes : l’API ID (identifiant) et l’API Token (mot de passe). Copiez les deux tout de suite, le token n’est affiché qu’une fois. 4. Dans Lutril, connectez Aircall, collez l’API ID et l’API Token, et définissez éventuellement l’URL de base. ## Access requested - Accès à l’API Aircall par authentification Basic (créez la clé en tant qu’Admin ou Owner) ## References - [Aircall documentation](https://developer.aircall.io/tutorials/basic-authentication/) - [Aircall console](https://dashboard.aircall.io) - [Références de l’API Aircall](undefined) --- # Allo + Lutril: setup guide > Lutril se connecte à Allo, l’espace de collaboration visuelle, avec une clé d’API. Vous pouvez éventuellement définir une URL de base d’API personnalisée. Source: https://www.lutril.com/fr/integrations/allo Category: Productivity Auth: api_key Last verified: 2026-06-17 --- ## Setup 1. Connectez-vous à Allo en tant qu’administrateur de l’espace de travail. 2. Ouvrez les paramètres de l’espace de travail ou du compte et cherchez la section API ou développeur pour générer une clé d’API. 3. Copiez la clé d’API et conservez-la en lieu sûr. 4. Dans Lutril, connectez Allo, collez la clé d’API, et définissez éventuellement une URL de base personnalisée. ## Access requested - Accès à l’API selon le compte et le rôle associés à la clé ## References - [Allo documentation](https://withallo.com/) - [Allo](undefined) --- # Ansys + Lutril: setup guide > Lutril a besoin d’un jeton d’accès personnel (PAT) du portail Ansys ID et de votre numéro de compte. Il liste les membres de votre compte Ansys avec leurs rôles, ajoute les nouveaux membres lorsqu’un accès est accordé, et les retire au départ des personnes. Source: https://www.lutril.com/fr/integrations/ansys Category: SaaS Auth: api_key Last verified: 2026-08-04 --- ## Setup 1. [object Object] 2. Cliquez sur votre icône de profil et sélectionnez Personal access token. 3. Cliquez sur Create Token, nommez-le (par exemple « Lutril »), définissez une date d’expiration et sélectionnez Full Access sous Scope. 4. Cliquez sur Create et copiez le jeton ; relevez votre numéro de compte dans le sélecteur de compte ou sur la page de détails du compte. 5. Dans Lutril, ouvrez Intégrations, choisissez Ansys, puis collez le PAT et saisissez le numéro de compte. ## Access requested - Portée du PAT : Full Access (nécessaire pour l’échange de jeton SSO) - Titulaire du PAT : membre du compte gouverné, avec un rôle Account Admin pour ajouter et retirer des utilisateurs ## References - [Ansys documentation](https://developer.ansys.com/docs/ansys-id-sso/pat-authentication-guide) - [Ansys console](https://id.ansys.com/) - [Gestion des utilisateurs du portail Ansys ID pour les administrateurs](undefined) - [Synchronisation des membres du portail Ansys ID (référence d’usage de l’API)](undefined) - [API Ansys ID (Swagger)](undefined) --- # Apollo + Lutril: setup guide > Lutril se connecte à Apollo avec une clé d’API maîtresse, ce qui lui permet de lire vos utilisateurs et de gérer les accès. Générez la clé depuis les paramètres d’API d’Apollo et collez-la dans Lutril. Source: https://www.lutril.com/fr/integrations/apollo Category: Sales & CRM Auth: api_key Last verified: 2026-06-17 --- ## Setup 1. Dans Apollo, ouvrez Settings → Integrations → API. 2. Cliquez sur Connect à côté d’Apollo API, puis ouvrez API Keys → Create new key. 3. Saisissez un nom et une description, puis activez « Set as master key » pour que la clé puisse lister les utilisateurs. 4. Cliquez sur Create API key et copiez la clé générée. 5. Dans Lutril, connectez Apollo et collez la clé dans le champ « Master API Key ». ## Access requested - Clé d’API maîtresse (accès à tous les endpoints, y compris Get a List of Users) ## References - [Apollo documentation](https://docs.apollo.io/docs/create-api-key) - [Apollo console](https://app.apollo.io/#/settings/integrations/api) --- # Appcues + Lutril: setup guide > Lutril se connecte à Appcues avec une clé d’API et un secret, ce qui lui permet de lire et de gérer votre compte. Vous fournissez également votre Account ID. Source: https://www.lutril.com/fr/integrations/appcues Category: Product Auth: api_key Last verified: 2026-06-17 --- ## Setup 1. [object Object] 2. Cliquez sur Create new key, donnez-lui un nom, choisissez le niveau d’accès, et copiez à la fois l’API Key et le Secret (le secret n’est affiché qu’une fois). 3. Retrouvez votre Account ID sur la page de compte de votre Studio. 4. Dans Lutril, connectez Appcues, collez le jeton ou la clé et son secret, et saisissez l’Account ID. Définissez éventuellement l’URL de base. ## Access requested - Accès à l’API publique au niveau que vous choisissez à la création de la clé ## References - [Appcues documentation](https://docs.appcues.com/dev-api-data/appcues-public-api) - [Appcues console](https://studio.appcues.com/settings/keys) - [Référence de l’API publique Appcues](undefined) --- # Asana + Lutril: setup guide > Lutril se connecte à Asana avec un jeton d’accès personnel créé dans la console développeur d’Asana. Vous fournissez également l’identifiant de l’espace de travail que Lutril doit gérer. Source: https://www.lutril.com/fr/integrations/asana Category: Project management Auth: api_key Last verified: 2026-06-17 --- ## Setup 1. Dans Asana, ouvrez votre photo de profil → Settings → Apps → View developer console. 2. Sous Personal access tokens, cliquez sur Create new token. 3. Nommez le jeton, acceptez les conditions de l’API Asana, et cliquez sur Create token. 4. Copiez le jeton immédiatement, il n’est affiché qu’une fois. 5. Dans Lutril, connectez Asana, collez le jeton et saisissez l’identifiant de votre espace de travail. ## Access requested - Accès complet de l’utilisateur qui autorise (les jetons d’accès personnels Asana ne sont pas limités par scope) ## References - [Asana documentation](https://developers.asana.com/docs/personal-access-token) - [Asana console](https://app.asana.com/0/my-apps) --- # Atlassian + Lutril: setup guide > Lutril se connecte à Atlassian (Jira et Confluence Cloud) avec un jeton d’API de compte. Vous fournissez votre domaine Atlassian, un e-mail d’administrateur et le jeton. Source: https://www.lutril.com/fr/integrations/atlassian Category: Developer tools Auth: api_key Last verified: 2026-06-17 --- ## Setup 1. Rendez-vous sur id.atlassian.com → Security → Create and manage API tokens. 2. Cliquez sur Create API token, donnez-lui un libellé, définissez une expiration, puis cliquez sur Create. 3. Copiez le jeton dans le presse-papiers, il est irrécupérable une fois la fenêtre fermée. 4. Dans Lutril, connectez Atlassian et saisissez votre domaine (par exemple mycompany), l’e-mail administrateur et le jeton d’API. ## Access requested - Agit avec les permissions du compte Atlassian qui autorise (utilisez un compte administrateur) ## References - [Atlassian documentation](https://support.atlassian.com/atlassian-account/docs/manage-api-tokens-for-your-atlassian-account/) - [Atlassian console](https://id.atlassian.com/manage-profile/security/api-tokens) --- # Avoma + Lutril: setup guide > Lutril se connecte à Avoma avec une clé d’API cadrée, ce qui lui permet de lire et de gérer vos réunions et les données de votre compte. Seuls les administrateurs d’organisation peuvent créer des clés. Source: https://www.lutril.com/fr/integrations/avoma Category: Sales & CRM Auth: api_key Last verified: 2026-06-17 --- ## Setup 1. Connectez-vous à Avoma en tant qu’administrateur d’organisation. 2. [object Object] 3. Cliquez sur Add API Key, saisissez un nom explicite et sélectionnez une portée. 4. Cliquez sur Create, puis copiez la chaîne complète (CLIENT_KEY:CLIENT_SECRET) et conservez-la en lieu sûr. 5. Dans Lutril, connectez Avoma et collez la clé d’API. ## Access requested - Clé d’API cadrée (CLIENT_KEY:CLIENT_SECRET), dont la portée choisie détermine l’accès de Lutril à vos données Avoma ## References - [Avoma documentation](https://help.avoma.com/api-integration-for-avoma) - [Documentation de l’API Avoma](undefined) - [Référence développeur Avoma](undefined) --- # AWS IAM Identity Center + Lutril: setup guide > Lutril lit et gère votre annuaire de collaborateurs via l’API AWS Identity Store. Vous fournissez une clé d’accès IAM (Access Key ID et Secret Access Key), l’Identity Store ID et la région où IAM Identity Center est activé. SCIM est pris en charge comme alternative. Source: https://www.lutril.com/fr/integrations/aws Category: Identity (IDP) Auth: service_account Last verified: 2026-06-17 --- ## Setup 1. [object Object] 2. Sur la page Settings d’IAM Identity Center, copiez l’Identity Store ID (il commence par d-) et relevez la région. Saisissez les deux dans Lutril. 3. Dans IAM, créez (ou réutilisez) un utilisateur IAM doté d’une politique autorisant les actions identitystore sur votre Identity Store. 4. [object Object] 5. Alternative (SCIM) : dans IAM Identity Center, activez le provisionnement automatique pour obtenir un endpoint SCIM et un jeton d’accès, puis saisissez l’URL de base SCIM et le jeton dans Lutril à la place. ## Access requested - Politique IAM autorisant les actions identitystore (par exemple identitystore:ListUsers, DescribeUser, CreateUser, UpdateUser, DeleteUser) sur l’Identity Store - Alternative : une URL de base d’endpoint SCIM et un jeton d’accès issus des paramètres de provisionnement d’Identity Center ## References - [AWS IAM Identity Center documentation](https://docs.aws.amazon.com/singlesignon/latest/IdentityStoreAPIReference/welcome.html) - [AWS IAM Identity Center console](https://console.aws.amazon.com/singlesignon) - [Référence de l’API Identity Store](undefined) - [Gérer les clés d’accès des utilisateurs IAM](undefined) - [Provisioning automatique (SCIM)](undefined) --- # Canny + Lutril: setup guide > Lutril se connecte à Canny avec la clé d’API secrète de votre entreprise, disponible dans les paramètres Canny. Source: https://www.lutril.com/fr/integrations/canny Category: Product Auth: api_key Last verified: 2026-06-17 --- ## Setup 1. Dans Canny, ouvrez Settings → API (paramètres de votre entreprise). 2. Copiez votre clé d’API secrète. 3. Dans Lutril, connectez Canny et collez la clé dans le champ API Key. 4. Ne conservez la clé que sur votre serveur : elle donne accès à vos données Canny. ## Access requested - Clé d’API secrète donnant accès aux données de votre entreprise dans Canny ## References - [Canny documentation](https://developers.canny.io/api-reference) - [Documentation développeur Canny](undefined) --- # Claude Console + Lutril: setup guide > Lutril se connecte à Claude (Anthropic) avec une clé d’API Admin d’organisation, ce qui lui permet de lire et de gérer les membres et les espaces de travail. Sa création requiert un administrateur d’organisation. Source: https://www.lutril.com/fr/integrations/claude Category: AI Auth: api_key Last verified: 2026-06-17 --- ## Setup 1. Connectez-vous à console.anthropic.com en tant qu’administrateur d’organisation. 2. Ouvrez votre nom d’utilisateur (en bas à gauche) → Organization settings → Admin keys (ou Admin Keys dans le menu de gauche). 3. Cliquez sur Create Admin Key et nommez-la. 4. Copiez la clé Admin et conservez-la en lieu sûr, elle n’est affichée qu’une fois. 5. Dans Lutril, connectez Claude et collez la clé dans le champ Admin API Key. ## Access requested - Clé d’API Admin d’organisation (gère les membres et les espaces de travail ; administrateur d’organisation uniquement) ## References - [Claude Console documentation](https://docs.anthropic.com/en/api/administration-api) - [Claude Console console](https://console.anthropic.com/settings/admin-keys) --- # Cloudflare + Lutril: setup guide > Lutril se connecte à Cloudflare avec un jeton d’API cadré, ce qui lui permet de lister, ajouter et retirer les membres du compte. Vous fournissez également votre Account ID. Source: https://www.lutril.com/fr/integrations/cloudflare Category: Infrastructure Auth: api_key Last verified: 2026-06-17 --- ## Setup 1. Dans Cloudflare, ouvrez My Profile → API Tokens → Create Token. 2. Choisissez Create Custom Token. 3. Ajoutez la permission Account → Memberships → Edit, ainsi que Account → Account Settings → Read. 4. Limitez la portée à votre compte, passez au récapitulatif, puis cliquez sur Create Token. 5. Copiez le jeton (affiché une seule fois). Dans Lutril, connectez Cloudflare, collez le jeton et saisissez votre Account ID. ## Access requested - Account → Memberships : Edit (lister, ajouter et retirer des membres) - Account → Account Settings : Read (résoudre les rôles) ## References - [Cloudflare documentation](https://developers.cloudflare.com/fundamentals/api/get-started/create-token/) - [Cloudflare console](https://dash.cloudflare.com/profile/api-tokens) - [Référence des permissions de jeton d’API](undefined) --- # Cursor + Lutril: setup guide > Lutril a besoin d’une clé d’API Team Admin Cursor pour lister les membres de votre équipe et leurs rôles. La clé se crée dans le tableau de bord Cursor, sous Settings. Source: https://www.lutril.com/fr/integrations/cursor Category: Developer tools Auth: api_key Last verified: 2026-07-17 --- ## Setup 1. [object Object] 2. Basculez le type de clé sur Team, cliquez sur New API Key, nommez-la et copiez-la immédiatement. Elle n’est affichée qu’une fois. 3. Dans Lutril, connectez Cursor et collez la clé dans le champ Admin API Key. 4. Laissez l’URL de base d’API vide pour utiliser https://api.cursor.com, ou renseignez-la uniquement si vous avez un endpoint personnalisé. ## Access requested - Clé d’API Team Admin (accès en lecture aux membres de l’équipe) ## References - [Cursor documentation](https://cursor.com/docs/account/teams/admin-api) - [Cursor console](https://cursor.com/dashboard) - [Référence de l’API Team Admin](undefined) --- # Datadog + Lutril: setup guide > Lutril a besoin à la fois d’une clé d’API et d’une clé d’application Datadog pour lire les utilisateurs et les rôles. Les deux se créent dans Organization Settings. Les comptes en région UE doivent aussi renseigner l’URL de base d’API européenne. Source: https://www.lutril.com/fr/integrations/datadog Category: Monitoring Auth: api_key Last verified: 2026-06-17 --- ## Setup 1. Dans Datadog, allez dans Organization Settings → API Keys et cliquez sur New Key. Nommez-la et copiez la clé d’API. 2. Allez dans Organization Settings → Application Keys et cliquez sur New Key. Nommez-la et copiez la clé d’application immédiatement, elle peut ne plus être récupérable ensuite. 3. Dans Lutril, connectez Datadog et collez la clé d’API et la clé d’application dans leurs champs respectifs. 4. Si votre compte est sur le site européen, renseignez l’URL de base d’API https://api.datadoghq.eu/api/v2 dans Lutril. ## Access requested - Clé d’API - Clé d’application (nécessite la permission user_app_keys ou org_app_keys_write) ## References - [Datadog documentation](https://docs.datadoghq.com/account_management/api-app-keys/) - [Datadog console](https://app.datadoghq.com/organization-settings/api-keys) - [Page des clés d’application](undefined) - [Site UE (clés d’API)](undefined) --- # DocuSign + Lutril: setup guide > Connectez DocuSign en OAuth pour que Lutril puisse lire votre compte et gérer les utilisateurs en votre nom. Lutril demande une autorisation par code et conserve le jeton de rafraîchissement obtenu ; aucune clé d’API n’est collée manuellement. Source: https://www.lutril.com/fr/integrations/docusign Category: Productivity Auth: oauth Last verified: 2026-06-17 --- ## Setup 1. Dans Lutril, ouvrez l’intégration DocuSign et cliquez sur Connecter DocuSign. Lutril vous redirige vers l’écran de connexion et de consentement DocuSign. 2. Connectez-vous avec un compte DocuSign disposant de droits d’administrateur sur le compte cible, afin que les scopes demandés puissent être accordés. 3. Vérifiez les accès demandés (signature, user_read, user_write) et approuvez. DocuSign vous redirige vers Lutril. 4. Lutril sélectionne votre compte DocuSign par défaut et conserve le jeton de rafraîchissement ; la connexion est active. 5. [object Object] ## Access requested - signature (envoyer et gérer des enveloppes via l’API REST eSignature) - user_read (lire les profils utilisateurs du compte) - user_write (créer et mettre à jour des utilisateurs dans le compte) ## References - [DocuSign documentation](https://developers.docusign.com/platform/auth/authcode/) - [DocuSign console](https://admindemo.docusign.com/apps-and-keys) - [Présentation de l’Authorization Code Grant](undefined) - [Référence des scopes d’authentification](undefined) --- # elba + Lutril: setup guide > Lutril se connecte à elba avec une clé d’API, ce qui lui permet de lire et de gérer les données de votre espace de travail. Générez la clé depuis vos paramètres elba. Source: https://www.lutril.com/fr/integrations/elba Category: Security Auth: api_key Last verified: 2026-06-17 --- ## Setup 1. Connectez-vous à elba en tant qu’administrateur. 2. [object Object] 3. Générez une nouvelle clé d’API et copiez-la (conservez-la en lieu sûr, elle peut n’être affichée qu’une fois). 4. Dans Lutril, connectez elba et collez la clé d’API. ## Access requested - Clé d’API donnant à Lutril accès aux données de votre espace de travail elba ## References - [elba documentation](https://docs.elba.security/) - [Documentation des paramètres elba](undefined) --- # Eurecia + Lutril: setup guide > Lutril se connecte à Eurecia avec un jeton d’API pour lire votre annuaire de collaborateurs : noms, e-mails, intitulés de poste, services, managers directs, dates d’entrée et de sortie. Lutril échange le jeton contre un jeton de session temporaire à chaque synchronisation ; il ne crée et ne modifie jamais rien dans Eurecia. Source: https://www.lutril.com/fr/integrations/eurecia Category: Identity (IDP) Auth: api_key Last verified: 2026-08-04 --- ## Setup 1. Dans Eurecia, vérifiez que la fonctionnalité API (services web) est activée. Si l’encart API n’apparaît pas dans votre espace d’administration, demandez son activation au support Eurecia. 2. Générez un jeton pour un utilisateur dédié : ouvrez la fiche de cette personne, allez dans l’onglet Admin, et créez un nouveau jeton d’API. Eurecia recommande un jeton par utilisateur ; le jeton hérite de la visibilité de cet utilisateur, choisissez donc un compte qui voit tous les collaborateurs. 3. Vous pouvez sinon générer un jeton de profil : dans la fiche de votre entreprise, ouvrez l’onglet Paramètres, trouvez l’encart API, et générez un jeton rattaché à un profil utilisateur. 4. Copiez le jeton et conservez-le en lieu sûr : c’est l’identifiant permanent qu’utilisera Lutril. 5. Dans Lutril, connectez Eurecia et collez le jeton d’API. Laissez l’URL de base vide, sauf si Eurecia vous a fourni un environnement non standard. ## Access requested - GET /v4/users (annuaire des collaborateurs, intitulés de poste, services, managers directs) - GET /v1/Auth (échange du jeton d’API contre un jeton temporaire) ## References - [Eurecia documentation](https://help.eurecia.com/hc/fr/articles/115000666829-Acc%C3%A9der-%C3%A0-l-API-Eur%C3%A9cia-Web-Services) - [Référence de l’API Eurecia (Swagger)](undefined) - [Centre d’aide interopérabilité Eurecia](undefined) --- # Figma + Lutril: setup guide > Lutril se connecte à Figma avec un jeton d’accès personnel. Générez-le depuis les paramètres de sécurité de votre compte Figma et accordez-lui les scopes en lecture dont Lutril a besoin pour lister les membres. Source: https://www.lutril.com/fr/integrations/figma Category: Design Auth: api_key Last verified: 2026-06-17 --- ## Setup 1. Dans Figma, ouvrez le menu du compte (en haut à gauche du navigateur de fichiers) → Settings. 2. Ouvrez l’onglet Security et trouvez la section « Personal access tokens ». 3. Cliquez sur Generate new token, définissez une expiration, et sélectionnez les scopes en lecture correspondant aux données auxquelles Lutril doit accéder. 4. Cliquez sur Generate token et copiez-le immédiatement, il n’est affiché qu’une fois. 5. Dans Lutril, connectez Figma et collez le jeton dans le champ « API Token » (ajoutez votre Org/Team ID si demandé). ## Access requested - current_user:read - org:read / lecture des membres d’équipe (pour lister les membres) ## References - [Figma documentation](https://developers.figma.com/docs/rest-api/personal-access-tokens/) - [Figma console](https://www.figma.com/settings) - [Référence des scopes de jeton](undefined) --- # GitHub + Lutril: setup guide > GitHub se connecte en OAuth. Vous saisissez l’organisation que Lutril doit gérer, puis vous autorisez l’application Lutril, qui demande un accès en lecture aux membres de l’organisation et aux e-mails pour pouvoir les synchroniser. Source: https://www.lutril.com/fr/integrations/github Category: Developer tools Auth: oauth Last verified: 2026-06-17 --- ## Setup 1. Dans Lutril, ouvrez Paramètres → Intégrations et sélectionnez GitHub. 2. Saisissez l’organisation GitHub que Lutril doit gérer, puis cliquez sur Connecter. 3. Vous êtes redirigé vers GitHub pour autoriser l’application Lutril sur cette organisation. 4. Vérifiez les scopes demandés et cliquez sur Authorize. Un propriétaire de l’organisation peut devoir approuver l’accès. 5. GitHub vous redirige vers Lutril et la connexion est établie. ## Access requested - read:org (lire les membres de l’organisation et des équipes) - admin:org (gérer les membres de l’organisation) - user:email (lire les adresses e-mail) ## References - [GitHub documentation](https://docs.github.com/en/apps/oauth-apps/building-oauth-apps/scopes-for-oauth-apps) - [GitHub console](https://github.com/settings/tokens) - [Autoriser les applications OAuth](undefined) --- # GitLab + Lutril: setup guide > GitLab se connecte en OAuth. Pour une instance auto-hébergée, vous renseignez d’abord l’URL de base, puis vous autorisez l’application Lutril, qui demande les accès api et read_user pour lire vos utilisateurs et vos projets. Source: https://www.lutril.com/fr/integrations/gitlab Category: Developer tools Auth: oauth Last verified: 2026-06-17 --- ## Setup 1. Dans Lutril, ouvrez Paramètres → Intégrations et sélectionnez GitLab. 2. Pour une instance auto-hébergée, saisissez l’URL de base de votre GitLab (à ignorer pour gitlab.com), puis cliquez sur Connecter. 3. Vous êtes redirigé vers GitLab pour autoriser l’application Lutril avec les scopes api et read_user. 4. Cliquez sur Authorize ; GitLab vous redirige vers Lutril et la connexion est établie. 5. Vous pouvez sinon coller un jeton d’accès personnel disposant des scopes api et read_user dans le champ manuel. ## Access requested - api (accès API en lecture et écriture) - read_user (lire le profil de l’utilisateur authentifié) ## References - [GitLab documentation](https://docs.gitlab.com/user/profile/personal_access_tokens/) - [GitLab console](https://gitlab.com/-/user_settings/personal_access_tokens) - [Référence des scopes de jeton d’accès](undefined) --- # Google Cloud + Lutril: setup guide > Lutril a besoin d’un compte de service portant un unique rôle personnalisé au niveau de l’organisation pour inventorier chaque compte de service et chaque clé Google Cloud, indiquer la date de dernière utilisation de chacun et vous permettre de désactiver les comptes dormants. Pas d’empilement de rôles prédéfinis : le rôle personnalisé ci-dessous est la liste complète des permissions, vérifiée en le créant. Lutril ne supprime jamais de compte de service, ne crée, ne renouvelle ni ne supprime jamais de clé, et ne modifie jamais les stratégies IAM. Source: https://www.lutril.com/fr/integrations/gcp Category: Infrastructure Auth: service_account Last verified: 2026-08-25 --- ## Setup 1. [object Object] 2. [object Object] 3. [object Object] 4. [object Object] 5. [object Object] 6. Dans Lutril, ouvrez Paramètres, puis Intégrations, puis Google Cloud. Collez le JSON du compte de service. Renseignez l’Organization ID pour une analyse de toute l’organisation (recommandé) ou un Project ID pour analyser un seul projet. Conservez le seuil de clé obsolète à 90 jours sauf si votre politique en dispose autrement. Activez la lentille d’impersonation pour lister qui peut usurper chaque compte de service ; elle coûte une lecture IAM supplémentaire par compte. 7. Ouvrez Identités non humaines et cliquez sur Actualiser. La synchronisation s’exécute en arrière-plan et prend quelques minutes sur les grandes organisations ; la page signale toute API ou permission manquante par un avertissement. Une dernière utilisation Inconnue partout signifie que Policy Analyzer n’est pas activé dans le projet Lutril ou que ses permissions manquent. Les projets marqués Non synchronisé n’ont pas les permissions resourcemanager. Une désactivation qui échoue avec une erreur de permission signifie que le rôle n’a pas iam.serviceAccounts.disable. Les limites de débit (429) sont réessayées automatiquement et les données déjà connues sont conservées. ## Access requested - Inventaire : iam.serviceAccounts.list, iam.serviceAccounts.get, iam.serviceAccounts.getIamPolicy, iam.serviceAccountKeys.list, resourcemanager.organizations.get, resourcemanager.folders.get, resourcemanager.folders.list, resourcemanager.projects.get, resourcemanager.projects.list, resourcemanager.projects.getIamPolicy - Recherche à l’échelle de l’organisation : cloudasset.assets.searchAllResources, cloudasset.assets.searchAllIamPolicies - Dormance (dernière authentification) : policyanalyzer.serviceAccountLastAuthenticationActivities.query, policyanalyzer.serviceAccountKeyLastAuthenticationActivities.query, serviceusage.services.use - Remédiation (facultatif) : iam.serviceAccounts.disable, iam.serviceAccounts.enable. Sans elles, l’inventaire fonctionne et le bouton Désactiver signale une erreur de permission. - Accès just-in-time (facultatif) : resourcemanager.projects.setIamPolicy. Sert uniquement à ajouter et retirer une autorisation IAM limitée dans le temps par demande d’accès approuvée. - Les valeurs Last used viennent de Policy Analyzer, qui agrège les authentifications par jour (heure du Pacifique). Google indique que les événements très récents peuvent manquer ; un décalage de plusieurs jours est courant. Google ne suit pas non plus les requêtes authentifiées par clé API liée, par clé HMAC Cloud Storage, ni les API Google hors Cloud (par exemple la délégation domain-wide vers Workspace, utilisée par GAM) : ces comptes peuvent apparaître jamais utilisés alors qu’ils sont actifs. C’est pourquoi Lutril traite l’absence d’authentification observée comme un signal d’alerte, jamais comme une preuve de non-usage. ## References - [Google Cloud documentation](https://docs.cloud.google.com/iam/docs/creating-custom-roles) - [Google Cloud console](https://console.cloud.google.com/iam-admin/serviceaccounts) - [Clés de compte de service](undefined) - [Policy Analyzer : activité d’authentification des comptes de service](undefined) - [Recherche Cloud Asset Inventory](undefined) --- # Google Workspace + Lutril: setup guide > Lutril s’authentifie comme compte de service Google Cloud avec délégation à l’échelle du domaine, ce qui lui permet de lire et de gérer votre annuaire Workspace pour le compte d’un administrateur Workspace. Vous fournissez la clé JSON du compte de service et l’e-mail de l’administrateur. Source: https://www.lutril.com/fr/integrations/google Category: Identity (IDP) Auth: service_account Last verified: 2026-06-17 --- ## Setup 1. [object Object] 2. Sélectionnez le nouveau compte de service, ouvrez Clés, cliquez sur Ajouter une clé, choisissez Créer une clé, et sélectionnez JSON. Collez l’intégralité du fichier JSON téléchargé dans Lutril. 3. Sur le compte de service, ouvrez les paramètres avancés et copiez son Client ID (un identifiant unique numérique utilisé pour la délégation). 4. [object Object] 5. Cliquez sur Ajouter, collez le Client ID, saisissez la liste des scopes OAuth ci-dessus séparés par des virgules, puis cliquez sur Autoriser. Si une entrée existe déjà pour ce Client ID, modifiez-la pour inclure tous les scopes ci-dessus et cliquez de nouveau sur Autoriser. Ajouter un scope à une entrée existante reste sans effet tant qu’elle n’est pas réautorisée, et c’est l’absence du scope admin.datatransfer qui bloque silencieusement le transfert de données au départ d’une personne. 6. Saisissez dans Lutril l’e-mail d’un administrateur Workspace (un super administrateur autorisé pour ces scopes) afin que les appels soient effectués en son nom. ## Access requested - https://www.googleapis.com/auth/admin.directory.user - https://www.googleapis.com/auth/admin.directory.user.alias - https://www.googleapis.com/auth/admin.directory.user.security - https://www.googleapis.com/auth/admin.directory.group.member - https://www.googleapis.com/auth/admin.directory.group.readonly - https://www.googleapis.com/auth/admin.reports.audit.readonly - https://www.googleapis.com/auth/admin.reports.usage.readonly - https://www.googleapis.com/auth/admin.datatransfer - https://www.googleapis.com/auth/gmail.send ## References - [Google Workspace documentation](https://developers.google.com/admin-sdk/directory/v1/guides/delegation) - [Google Workspace console](https://console.cloud.google.com/iam-admin/serviceaccounts) - [Guide de la délégation au niveau du domaine](undefined) - [Contrôler l’accès aux API par délégation de domaine](undefined) --- # Grafana + Lutril: setup guide > Lutril gouverne Grafana selon deux modes de provisionnement, que vous choisissez à la connexion. En mode JIT, votre SSO crée le compte à la première connexion et Lutril gère le rôle dans l’organisation, les appartenances aux équipes et l’état du compte. En mode SCIM, Lutril provisionne l’utilisateur via l’API SCIM de Grafana, ce qui nécessite Grafana Enterprise ou Grafana Cloud. Aucun mot de passe n’est jamais généré : un utilisateur SCIM est créé en fédéré, sans aucun mot de passe, et en mode JIT l’endpoint de création admin de Grafana en exige un, Lutril attend donc la première connexion SSO plutôt que de créer un compte. Dans les deux cas, une personne qui part est désactivée et non supprimée : tableaux de bord, permissions et propriété survivent, et le même compte peut être réactivé si elle revient. Source: https://www.lutril.com/fr/integrations/grafana Category: Monitoring Auth: service_account Last verified: 2026-08-10 --- ## Setup 1. Choisissez le mode de provisionnement. Prenez jit si vos utilisateurs accèdent à Grafana par SAML, OIDC ou OAuth et que Grafana crée leur compte à la première connexion. Prenez scim si vous exploitez Grafana Enterprise ou Grafana Cloud et souhaitez provisionner Grafana depuis votre fournisseur d’identité. Lutril ne bascule jamais de scim vers jit : si SCIM s’avère indisponible, la connexion est refusée, pour que rien ne change silencieusement de système propriétaire du cycle de vie. 2. Pour un jeton de compte de service, allez dans Administration, puis Users and access, puis Service accounts. Cliquez sur Add service account, donnez-lui un rôle couvrant les permissions listées ci-dessus, puis Add service account token et copiez le jeton immédiatement. 3. Pour une authentification Basic sur un Grafana auto-hébergé en mode jit, utilisez un utilisateur Grafana disposant du rôle d’administrateur de serveur. C’est normalement indispensable, car les endpoints de désactivation, de réactivation et de déconnexion relèvent de l’administration globale des utilisateurs. 4. Dans Lutril, connectez Grafana et collez l’URL de votre Grafana, par exemple https://grafana.example.com ou https://mystack.grafana.net. Elle doit être en https. 5. Réglez Provisioning Mode sur jit ou scim. En mode scim, renseignez aussi le SCIM Namespace : default pour un Grafana auto-hébergé, ou stacks-{stackId} pour Grafana Cloud. 6. Renseignez éventuellement l’Organization ID, par exemple 1. Avec lui, Lutril adresse explicitement cette organisation ; sans lui, Lutril agit sur l’organisation à laquelle l’identifiant est rattaché, ce qui devient ambigu si vous en exploitez plusieurs. 7. Si Grafana synchronise déjà les appartenances aux équipes depuis votre fournisseur d’identité, par Team Sync ou par synchronisation de groupes SCIM, réglez Team Membership Owner sur team_sync ou scim_groups. Lutril refuse alors d’écrire des appartenances que la prochaine connexion annulerait, plutôt que de signaler un changement qui n’a pas tenu. Grafana lui-même n’autorise pas la synchronisation de groupes SCIM et Team Sync en même temps. 8. Nommez vos niveaux d’accès comme les rôles d’organisation de Grafana, Viewer, Editor et Admin, et la correspondance ne demande aucune configuration supplémentaire. Une demande sans niveau n’envoie aucun rôle et Grafana applique son propre auto_assign_org_role, personne ne reçoit donc un rôle qu’il n’a pas demandé. À noter qu’en mode scim, le provisionnement d’utilisateurs SCIM de Grafana ne définit pas les rôles : ils viennent du Role Sync à la connexion, configurez-le si vous voulez que SCIM les pilote. 9. Enregistrez. Lutril lance une vérification de capacités qui détecte votre version de Grafana, valide l’identifiant, vérifie l’existence de l’organisation et teste si la désactivation douce est réellement disponible. Une connexion jit incapable de désactiver un compte est refusée, plutôt qu’acceptée avec une révocation qu’elle ne pourrait pas exécuter. ## Access requested - Mode JIT, auto-hébergé : authentification Basic en tant qu’administrateur du serveur Grafana. L’administration globale des utilisateurs (désactiver, réactiver, révoquer les sessions) n’est accessible qu’à un administrateur de serveur, et un compte de service limité à une organisation ne peut pas l’être. - Mode JIT, Grafana Cloud ou Enterprise avec RBAC : un jeton de compte de service dont le rôle accorde users:read, users:disable, users:enable, users:logout, org.users:write et teams.permissions:write. - Mode SCIM : un jeton de compte de service avec le rôle User administration, plus le rôle Teams si vous activez la synchronisation de groupes SCIM. - Jamais demandé ni utilisé par un flux de cycle de vie : users:delete. La suppression définitive est une opération distincte et volontaire, qu’aucune expiration ni aucun départ ne peut déclencher. ## References - [Grafana documentation](https://grafana.com/docs/grafana/latest/developers/http_api/admin/) - [Grafana console](https://grafana.com/docs/grafana/latest/administration/service-accounts/) - [Comptes de service et jetons](undefined) - [API HTTP Utilisateurs (recherche, équipes, organisations)](undefined) - [Provisionnement SCIM (Enterprise et Cloud)](undefined) - [Rôles et permissions d’organisation](undefined) --- # Gravitee AM + Lutril: setup guide > Lutril lit et gère les utilisateurs d’organisation de votre Gravitee AM (les opérateurs qui administrent AM) via son API REST de management. Il s’authentifie avec un jeton d’accès de compte créé pour un utilisateur d’organisation, envoyé en Bearer. Source: https://www.lutril.com/fr/integrations/graviteeam Category: Security Auth: service_account Last verified: 2026-07-15 --- ## Setup 1. Connectez-vous à votre console Gravitee AM en tant qu’administrateur. Pour l’automatisation, créez d’abord un compte de service dédié : dans le menu, cliquez sur Organization, puis sous User Management cliquez sur Users, et ajoutez un utilisateur qui servira d’identité d’intégration. Donnez-lui un rôle avec les permissions sur les utilisateurs d’organisation. 2. [object Object] 3. Copiez le jeton immédiatement : Gravitee AM ne l’affiche qu’une fois et il est ensuite irrécupérable. 4. Dans Lutril, connectez Gravitee AM. Réglez l’URL de l’API de management sur la base de votre AM jusqu’à (mais sans inclure) /management, chemin de contexte compris (par exemple https://am.example.com/am). Pour la trouver rapidement, ouvrez votre console AM sur /am/ui/constants.json et copiez la valeur baseURL en retirant le /management final. Collez le jeton dans Account Access Token, et renseignez l’Organization ID s’il n’est pas DEFAULT. ## Access requested - Utilisateur d’organisation autorisé à lire les utilisateurs d’organisation (pour les lister) - Ajoutez les permissions d’écriture et de suppression sur les utilisateurs d’organisation pour pouvoir les créer et les retirer depuis Lutril ## References - [Gravitee AM documentation](https://documentation.gravitee.io/am/guides/user-management/users) - [Référence de l’API AM](undefined) - [Configurer l’API AM](undefined) - [Correspondance utilisateurs, rôles et groupes](undefined) --- # Gravitee APIM + Lutril: setup guide > Lutril lit et gère les utilisateurs d’organisation de votre Gravitee APIM (les opérateurs qui administrent la plateforme) via son API REST de management. Il s’authentifie avec un jeton d’accès personnel créé pour un compte de service d’organisation, envoyé en Bearer. Source: https://www.lutril.com/fr/integrations/graviteeapim Category: Security Auth: service_account Last verified: 2026-07-15 --- ## Setup 1. Connectez-vous à la console Gravitee APIM en tant qu’administrateur. Ouvrez Organization settings, puis sous User Management cliquez sur Users, cliquez sur Add user, et choisissez le type Service Account. Donnez-lui un nom de service. 2. [object Object] 3. Sur la page du compte de service, descendez jusqu’à la section Tokens, cliquez sur Generate a personal token, nommez-le, et générez-le. Copiez le jeton immédiatement : il n’est affiché qu’une fois et ne peut pas être récupéré ensuite. 4. Dans Lutril, connectez Gravitee APIM. Réglez l’URL de l’API de management sur la base de votre APIM jusqu’à (mais sans inclure) /management (par exemple https://apim.example.com). Pour la trouver rapidement, ouvrez le constants.json de votre console APIM et copiez la valeur baseURL en retirant le /management final. Collez le jeton dans Personal Access Token, et renseignez l’Organization ID s’il n’est pas DEFAULT. ## Access requested - Compte de service d’organisation avec le rôle ORGANIZATION ADMIN (donne la lecture des utilisateurs d’organisation pour les lister) - Le rôle ADMIN couvre aussi la création et le retrait des utilisateurs d’organisation depuis Lutril ## References - [Gravitee APIM documentation](https://documentation.gravitee.io/apim/configure-and-manage-the-platform/manage-organizations-and-environments/user-management) - [Référence de l’API de management](undefined) - [Définir un compte de service APIM](undefined) --- # Harvest + Lutril: setup guide > Lutril se connecte à Harvest avec un jeton d’accès personnel. Au moment de le créer, Harvest affiche aussi votre Account ID, dont Lutril a besoin. Source: https://www.lutril.com/fr/integrations/harvest Category: Time tracking Auth: api_key Last verified: 2026-06-17 --- ## Setup 1. Rendez-vous sur id.getharvest.com/developers. 2. Cliquez sur Create new personal access token et nommez-le. 3. Cliquez sur Create personal access token ; copiez le jeton et relevez l’Account ID affiché. 4. Dans Lutril, connectez Harvest et saisissez l’Account ID et le jeton d’accès. ## Access requested - Agit avec les permissions de votre compte Harvest ## References - [Harvest documentation](https://help.getharvest.com/api-v2/authentication-api/authentication/authentication/) - [Harvest console](https://id.getharvest.com/developers) --- # HubSpot + Lutril: setup guide > HubSpot se connecte en OAuth. Vous autorisez l’application Lutril sur un compte HubSpot et accordez les scopes qui lui permettent de lire et de provisionner les utilisateurs et les équipes. L’octroi des scopes utilisateurs requiert un Super Admin. Source: https://www.lutril.com/fr/integrations/hubspot Category: Sales & CRM Auth: oauth Last verified: 2026-06-17 --- ## Setup 1. Dans Lutril, ouvrez Paramètres → Intégrations et cliquez sur Connecter pour HubSpot. 2. Vous êtes redirigé vers HubSpot pour choisir le compte à connecter. 3. Connectez-vous en Super Admin et vérifiez les scopes demandés (lecture et écriture sur les utilisateurs et les équipes). 4. Cliquez sur Connect app pour accorder l’accès ; HubSpot vous redirige vers Lutril. 5. Vous pouvez sinon coller dans le champ manuel un jeton d’application privée disposant des mêmes scopes. ## Access requested - crm.objects.users.read / write - settings.users.read / write - settings.users.teams.read - crm.objects.owners.read - account-info.security.read ## References - [HubSpot documentation](https://developers.hubspot.com/docs/guides/apps/authentication/scopes) - [Créer une application privée (solution de repli par jeton)](undefined) --- # Intercom + Lutril: setup guide > Intercom se connecte en OAuth. Vous autorisez l’application Lutril sur votre espace de travail ; l’accès suit les permissions configurées de l’application pour lire et gérer les coéquipiers. Un jeton d’accès est accepté en solution de repli manuelle. Source: https://www.lutril.com/fr/integrations/intercom Category: Support Auth: oauth Last verified: 2026-06-17 --- ## Setup 1. Dans Lutril, ouvrez Paramètres → Intégrations et cliquez sur Connecter pour Intercom. 2. Vous êtes redirigé vers Intercom pour autoriser l’application Lutril sur votre espace de travail. 3. Vérifiez les accès demandés et cliquez sur Authorize ; Intercom vous redirige vers Lutril. 4. Repli : dans le Developer Hub d’Intercom, ouvrez votre application → Configure → Authentication et copiez l’Access Token. 5. Collez le jeton dans le champ manuel de Lutril (ajoutez l’URL de base SCIM et le jeton si vous avez besoin de créer ou supprimer des coéquipiers). ## Access requested - Lecture et écriture sur les coéquipiers et administrateurs de l’espace de travail (selon les permissions configurées de l’application Lutril) ## References - [Intercom documentation](https://developers.intercom.com/docs/build-an-integration/learn-more/authentication) - [Créer un jeton d’accès](undefined) --- # Jenkins + Lutril: setup guide > Lutril se connecte à Jenkins avec un jeton d’API utilisateur. Vous fournissez l’URL de base de votre Jenkins, le nom d’utilisateur et le jeton. Source: https://www.lutril.com/fr/integrations/jenkins Category: Developer tools Auth: api_key Last verified: 2026-06-17 --- ## Setup 1. Connectez-vous à Jenkins avec l’utilisateur au nom duquel Lutril doit agir. 2. Cliquez sur votre nom (en haut à droite) → Configure (ou Security). 3. Sous API Token, cliquez sur Add new Token, nommez-le, et cliquez sur Generate. 4. Copiez le jeton immédiatement, Jenkins ne l’affiche qu’une fois. 5. Dans Lutril, connectez Jenkins et saisissez l’URL de base, le nom d’utilisateur et le jeton d’API. ## Access requested - Agit avec les permissions Jenkins du titulaire du jeton ## References - [Jenkins documentation](https://www.jenkins.io/doc/book/system-administration/authenticating-scripted-clients/) - [API d’accès distant](undefined) - [Système de jetons d’API](undefined) --- # lemlist + Lutril: setup guide > Lutril se connecte à lemlist avec une clé d’API générée dans les paramètres de votre équipe lemlist. Source: https://www.lutril.com/fr/integrations/lemlist Category: Sales & CRM Auth: api_key Last verified: 2026-06-17 --- ## Setup 1. Dans lemlist, ouvrez Settings → Integrations et descendez jusqu’à la section API. 2. Cliquez sur Generate pour créer une nouvelle clé d’API. 3. Copiez la clé immédiatement, elle n’est consultable qu’une fois. 4. Dans Lutril, connectez lemlist et collez la clé dans le champ API Key. ## Access requested - Accès complet aux données de votre équipe lemlist ## References - [lemlist documentation](https://help.lemlist.com/en/articles/4452694-find-and-use-the-lemlist-api) - [lemlist console](https://app.lemlist.com/settings/integrations) --- # Loom + Lutril: setup guide > Lutril provisionne et déprovisionne les membres Loom via SCIM (Directory Sync). Un administrateur de l’espace Loom récupère l’endpoint SCIM et le jeton Bearer depuis la configuration Directory Sync, puis colle les deux dans Lutril. Source: https://www.lutril.com/fr/integrations/loom Category: Communication Auth: api_key Last verified: 2026-06-17 --- ## Setup 1. Dans Loom, ouvrez Workspace settings depuis la navigation de gauche de la Library et sélectionnez l’onglet Security (nécessite le plan Enterprise et des droits d’administration). 2. Cliquez sur Configure Directory Sync pour lancer la console de configuration SCIM. 3. Copiez l’Endpoint (URL de base SCIM) et le Bearer Token affichés dans la console. 4. Dans Lutril, collez l’Endpoint comme SCIM Base URL et le Bearer Token comme API Token, puis enregistrez. ## Access requested - SCIM v2 : envoi des nouveaux utilisateurs, des mises à jour de profil et des groupes (identifiant unique réglé sur l’e-mail) ## References - [Loom documentation](https://support.atlassian.com/loom/docs/configure-sso-and-directory-sync-scim/) - [Configurer le SSO et Directory Sync (SCIM)](undefined) --- # Lucca + Lutril: setup guide > Lutril lit votre annuaire Lucca via le flux OAuth 2.0 client credentials. Vous créez une clé d’intégration dans Lucca pour obtenir un Client ID et un Client Secret, et vous renseignez votre hôte Lucca. Source: https://www.lutril.com/fr/integrations/lucca Category: Identity (IDP) Auth: api_key Last verified: 2026-06-17 --- ## Setup 1. Connectez-vous à votre compte Lucca avec un administrateur habilité à gérer les intégrations. 2. Ouvrez la page d’administration des clés d’intégration, au chemin /identity/admin/integration-keys sur votre hôte Lucca (par exemple https://votreentreprise.ilucca.net/identity/admin/integration-keys). 3. Créez une nouvelle application cliente : saisissez un e-mail de contact technique et un nom d’application. 4. Sélectionnez les scopes OAuth listés ci-dessus et les établissements auxquels l’application peut accéder, puis enregistrez. 5. Copiez le Client ID et le Client Secret générés (le secret n’est affiché qu’une fois) et saisissez-les dans Lutril. 6. Renseignez votre hôte Lucca dans Lutril (par exemple votreentreprise.ilucca.net). ## Access requested - employees.readonly - job-positions.readonly - departments.readonly - legal-entities.readonly ## References - [Lucca documentation](https://developers.luccasoftware.com/documentation/using-api/authentication) - [Guide d’authentification](undefined) - [Générer une clé d’API](undefined) --- # Microsoft Entra ID + Lutril: setup guide > Lutril se connecte à Microsoft Entra ID (Azure AD) comme application enregistrée, via le flux OAuth 2.0 client credentials. Vous fournissez le Tenant ID, le Client ID et un Client Secret, et vous accordez les permissions applicatives Microsoft Graph. Source: https://www.lutril.com/fr/integrations/azure Category: Identity (IDP) Auth: service_account Last verified: 2026-06-17 --- ## Setup 1. [object Object] 2. Sur la page Overview de l’application, copiez l’Application (client) ID et le Directory (tenant) ID dans Lutril. 3. Ouvrez Certificates and secrets, cliquez sur New client secret, définissez une expiration, puis copiez la valeur du secret (affichée une seule fois) dans Lutril. 4. Ouvrez API permissions, cliquez sur Add a permission, choisissez Microsoft Graph, puis Application permissions, et ajoutez les permissions listées ci-dessus. 5. Cliquez sur Grant admin consent pour votre tenant et vérifiez que chaque permission affiche Granted dans la colonne Status. ## Access requested - Microsoft Graph : User.Read.All (application) - Microsoft Graph : Directory.Read.All (application) - Microsoft Graph : AuditLog.Read.All (application) - Microsoft Graph : User.ReadWrite.All (application, nécessaire pour créer ou mettre à jour des utilisateurs) ## References - [Microsoft Entra ID documentation](https://learn.microsoft.com/en-us/entra/identity-platform/quickstart-register-app) - [Microsoft Entra ID console](https://entra.microsoft.com/#view/Microsoft_AAD_RegisteredApps/ApplicationsListBlade) - [Enregistrer une application](undefined) - [Obtenir un accès sans utilisateur (client credentials)](undefined) --- # Microsoft Teams + Lutril: setup guide > Connectez Microsoft Teams via le consentement administrateur Microsoft Entra, pour que Lutril puisse lire les utilisateurs de l’annuaire et envoyer des messages proactifs via Microsoft Graph. Aucun secret n’est collé manuellement : un administrateur Microsoft 365 accorde le consentement à l’échelle du tenant. Source: https://www.lutril.com/fr/integrations/teams Category: Communication Auth: oauth Last verified: 2026-06-17 --- ## Setup 1. Dans Lutril, ouvrez l’intégration Microsoft Teams et cliquez sur Connecter Microsoft Teams. 2. Lutril vous redirige vers l’écran de consentement administrateur Microsoft Entra, sur login.microsoftonline.com. 3. Connectez-vous avec un administrateur Microsoft 365 (Entra) habilité à accorder le consentement à l’échelle du tenant. 4. Vérifiez les permissions Microsoft Graph demandées (User.Read.All, TeamsAppInstallation.ReadWriteSelfForUser.All, offline_access) et acceptez. 5. Microsoft vous redirige vers Lutril et la connexion Teams devient active pour votre tenant. ## Access requested - https://graph.microsoft.com/User.Read.All (lire le profil complet de tous les utilisateurs de l’annuaire) - https://graph.microsoft.com/TeamsAppInstallation.ReadWriteSelfForUser.All (installer et gérer l’application Teams de Lutril pour les utilisateurs, afin de pouvoir leur écrire) - offline_access (obtenir un jeton de rafraîchissement pour maintenir la connexion active) ## References - [Microsoft Teams documentation](https://learn.microsoft.com/en-us/graph/permissions-reference) - [Référence des permissions Microsoft Graph](undefined) - [Présentation des permissions Microsoft Graph](undefined) --- # Mintlify + Lutril: setup guide > Lutril se connecte à Mintlify via son annuaire SCIM, adossé à Stytch. Il utilise l’URL de base de la connexion et le jeton Bearer pour lister, provisionner et déprovisionner les membres de votre organisation Mintlify. Source: https://www.lutril.com/fr/integrations/mintlify Category: Developer tools Auth: api_key Last verified: 2026-07-16 --- ## Setup 1. SCIM et SSO sont des fonctionnalités Enterprise : vérifiez d’abord que votre organisation Mintlify est sur un plan Enterprise. 2. [object Object] 3. Activez le provisionnement SCIM pour l’organisation. Mintlify crée une connexion SCIM via Stytch et affiche une URL de base de connecteur (de la forme https://api.stytch.com/v1/b2b/scim/) et un jeton Bearer. 4. Copiez l’URL de base SCIM et le jeton Bearer. Le jeton n’est affiché qu’une fois, conservez-le en lieu sûr. 5. Dans Lutril, connectez Mintlify et collez l’URL de base SCIM et le jeton Bearer dans leurs champs respectifs. ## Access requested - SCIM 2.0 /Users : lire, créer et désactiver les membres de l’organisation ## References - [Mintlify documentation](https://www.mintlify.com/docs/dashboard/sso) - [Mintlify console](https://app.mintlify.com/settings/organization/sso) - [Mintlify pour les entreprises](undefined) - [Guide de l’authentification unique (SSO)](undefined) --- # Mixpanel + Lutril: setup guide > Lutril provisionne et déprovisionne les utilisateurs Mixpanel via SCIM. Vous générez un jeton SCIM dans vos Organization Settings Mixpanel et le collez dans Lutril ; l’URL de base SCIM est facultative. Source: https://www.lutril.com/fr/integrations/mixpanel Category: Analytics Auth: api_key Last verified: 2026-06-17 --- ## Setup 1. [object Object] 2. Ouvrez l’onglet Access Security, puis le menu SCIM. Générer un jeton SCIM requiert le rôle Organization Owner ou Admin et un plan Enterprise. 3. Générez le jeton SCIM et copiez-le immédiatement (Mixpanel ne l’affiche qu’une fois). 4. Dans Lutril, collez le jeton dans SCIM Token. Renseignez éventuellement l’URL de base SCIM https://mixpanel.com/api/app/scim/v2, puis enregistrez. ## Access requested - SCIM v2 : créer, mettre à jour et désactiver les utilisateurs de l’organisation (uniquement sur les domaines d’e-mail vérifiés et revendiqués) ## References - [Mixpanel documentation](https://docs.mixpanel.com/docs/access-security/single-sign-on) - [Mixpanel console](https://mixpanel.com/settings/org) - [Authentification unique et SCIM](undefined) --- # Monday.com + Lutril: setup guide > Lutril se connecte à monday.com via l’API GraphQL (api.monday.com/v2) avec un jeton d’API personnel : il liste les membres, invités et lecteurs, invite les utilisateurs pour les demandes d’accès approuvées (monday.com envoie lui-même l’invitation par e-mail), et désactive les comptes au départ. Source: https://www.lutril.com/fr/integrations/monday Category: Project management Auth: api_key Last verified: 2026-08-04 --- ## Setup 1. Connectez-vous à monday.com en tant qu’administrateur du compte : inviter et désactiver des utilisateurs sont des opérations d’API réservées aux administrateurs, et un jeton personnel porte les permissions de son titulaire. 2. [object Object] 3. Copiez le jeton. Les administrateurs trouvent aussi un jeton au niveau du compte sous Administration, puis Connections, puis l’onglet API. 4. Dans Lutril, ouvrez l’intégration Monday.com et collez le jeton d’API. La version d’API vaut 2026-04 par défaut et l’endpoint https://api.monday.com/v2 ; les deux sont modifiables si nécessaire. ## Access requested - Requête users : lister les utilisateurs du compte, leur rôle, leur statut d’invité et leur dernière activité - Mutation invite_users : inviter des utilisateurs sur demande approuvée (administrateurs uniquement) - Mutation deactivate_users : désactiver des utilisateurs au départ (administrateurs uniquement) ## References - [Monday.com documentation](https://developer.monday.com/api-reference/reference/users) - [Référence de l’API Users (requêtes et mutations)](undefined) - [Authentification et jetons](undefined) --- # Netlify + Lutril: setup guide > Lutril se connecte à Netlify avec un jeton d’accès personnel. Vous fournissez également le slug du compte que Lutril doit gérer. Source: https://www.lutril.com/fr/integrations/netlify Category: Infrastructure Auth: api_key Last verified: 2026-06-17 --- ## Setup 1. Dans Netlify, allez dans User settings → Applications → Personal access tokens. 2. Cliquez sur New access token, saisissez un nom explicite, et définissez une expiration. 3. Cliquez sur Generate token et copiez-le : il n’est plus consultable une fois la page quittée. 4. Dans Lutril, connectez Netlify, collez le jeton, et saisissez le slug de votre compte. ## Access requested - Agit avec les permissions de votre compte Netlify (activez l’accès SAML de l’équipe si elle utilise le SSO) ## References - [Netlify documentation](https://docs.netlify.com/api-and-cli-guides/api-guides/get-started-with-api/) - [Netlify console](https://app.netlify.com/user/applications#personal-access-tokens) --- # New Relic + Lutril: setup guide > Lutril a besoin d’une clé d’API utilisateur New Relic pour lister les utilisateurs via NerdGraph, les comparer à votre annuaire et, éventuellement, en créer ou en retirer. Ce doit être une clé User, pas une clé de licence ni d’ingestion. Source: https://www.lutril.com/fr/integrations/newrelic Category: Monitoring Auth: api_key Last verified: 2026-07-10 --- ## Setup 1. [object Object] 2. Cliquez sur Create a key, choisissez le type User, donnez-lui un nom, et cliquez sur Save. 3. Copiez la clé complète immédiatement. Seuls les premiers caractères sont affichés ensuite. 4. Dans Lutril, connectez New Relic et collez la clé d’API utilisateur. 5. Réglez la région sur eu si votre compte New Relic est hébergé dans le centre de données européen, sinon laissez us. Une clé US ne fonctionne que sur l’endpoint US, et réciproquement. ## Access requested - Clé User (ni clé de licence, ni clé d’ingestion) - Pour créer, modifier ou retirer des utilisateurs, le titulaire de la clé doit avoir le rôle Authentication Domain Manager ## References - [New Relic documentation](https://docs.newrelic.com/docs/apis/intro-apis/new-relic-api-keys/) - [New Relic console](https://one.newrelic.com/api-keys) - [Gérer les utilisateurs avec NerdGraph](undefined) - [Centre de données UE ou US](undefined) --- # Notion + Lutril: setup guide > Notion se connecte en OAuth au niveau de l’espace de travail. Après avoir autorisé l’application Lutril, vous choisissez les pages et bases de données auxquelles elle peut accéder ; Notion n’accorde jamais un accès global. Source: https://www.lutril.com/fr/integrations/notion Category: Productivity Auth: oauth Last verified: 2026-06-17 --- ## Setup 1. Dans Lutril, ouvrez Paramètres → Intégrations et cliquez sur Connecter pour Notion. 2. Vous êtes redirigé vers Notion pour autoriser la connexion Lutril sur votre espace de travail. 3. Sélectionnez les pages et bases de données auxquelles la connexion doit accéder, puis cliquez sur Allow access. 4. Notion vous redirige vers Lutril et la connexion est établie. 5. Pour partager d’autres pages par la suite, ouvrez le menu ••• d’une page → Connections → ajoutez la connexion Lutril. ## Access requested - Accès au niveau de l’espace de travail, limité aux pages et bases de données que vous partagez explicitement avec la connexion ## References - [Notion documentation](https://www.notion.com/help/create-integrations-with-the-notion-api) - [Notion console](https://www.notion.so/my-integrations) - [Ajouter et gérer les connexions](undefined) --- # Odoo + Lutril: setup guide > Lutril se connecte à Odoo via l’API externe JSON-2 avec une clé d’API en Bearer : il liste les utilisateurs internes et portail, crée les comptes pour les demandes d’accès approuvées (Odoo envoie lui-même l’invitation par e-mail), et archive les comptes au départ. Source: https://www.lutril.com/fr/integrations/odoo Category: ERP Auth: api_key Last verified: 2026-08-04 --- ## Setup 1. Connectez-vous à Odoo avec un utilisateur ayant accès aux Paramètres (administration). Un compte de service dédié est recommandé, pour que la clé survive au départ d’un collaborateur. 2. Ouvrez le menu de votre avatar, puis Préférences, puis l’onglet Sécurité du compte, et cliquez sur Nouvelle clé d’API. 3. Saisissez une description (par exemple Lutril) et une durée, confirmez votre mot de passe, puis copiez la clé : Odoo ne l’affiche qu’une fois. 4. Dans Lutril, ouvrez l’intégration Odoo et collez votre URL de base (par exemple https://monentreprise.odoo.com), le nom de la base de données si votre serveur en héberge plusieurs, et la clé d’API. 5. À noter : l’API externe requiert un plan tarifaire Odoo Custom, et l’endpoint JSON-2 requiert Odoo 19 ou une version plus récente. ## Access requested - res.users : search_read (lister les utilisateurs et leur statut) - res.users : create (provisionner les utilisateurs sur demande approuvée) - res.users : write (archiver les utilisateurs au départ, jamais de suppression) ## References - [Odoo documentation](https://www.odoo.com/documentation/19.0/developer/reference/external_api.html) - [Référence de l’API externe JSON-2](undefined) - [Tarifs Odoo (l’API externe requiert le plan Custom)](undefined) --- # OpenAI + Lutril: setup guide > Lutril se connecte à OpenAI avec une clé d’API Admin d’organisation, ce qui lui permet de lire et de gérer les utilisateurs et les projets. Seul un Organization Owner peut en créer une. Source: https://www.lutril.com/fr/integrations/openai Category: AI Auth: api_key Last verified: 2026-06-17 --- ## Setup 1. En tant qu’Organization Owner, ouvrez platform.openai.com/settings/organization/admin-keys. 2. Cliquez sur Create new admin key et donnez-lui un nom. 3. Cliquez sur Create et copiez la clé, elle n’est affichée qu’une fois. 4. Dans Lutril, connectez OpenAI et collez la clé dans le champ Admin API Key. 5. Facultatif : ajoutez l’URL de base SCIM et le jeton SCIM si vous provisionnez les utilisateurs par SCIM. ## Access requested - Clé d’API Admin d’organisation (gère les utilisateurs, les invitations, les projets et les clés ; Org Owner uniquement) ## References - [OpenAI documentation](https://platform.openai.com/docs/api-reference/administration) - [OpenAI console](https://platform.openai.com/settings/organization/admin-keys) --- # PayFit + Lutril: setup guide > Lutril se connecte à PayFit avec une clé d’API Partner pour lire votre annuaire de collaborateurs (les personnes et leurs intitulés de poste). Vous générez la clé dans le hub d’intégrations PayFit ; Lutril identifie votre entreprise automatiquement. Source: https://www.lutril.com/fr/integrations/payfit Category: Identity (IDP) Auth: api_key Last verified: 2026-06-17 --- ## Setup 1. [object Object] 2. Cliquez sur Créer une clé, donnez-lui un libellé explicite, et accordez les scopes collaborators:read et collaborators:contracts:read (les deux sont nécessaires ; collaborators:contracts:read sert à lire les intitulés de poste). 3. Copiez la clé immédiatement, PayFit ne l’affiche qu’une fois. 4. Dans Lutril, connectez PayFit et collez la clé d’API. Votre entreprise est détectée automatiquement à partir de la clé. ## Access requested - collaborators:read (lire les informations générales des collaborateurs) - collaborators:contracts:read (lire les intitulés de poste) ## References - [PayFit documentation](https://developers.payfit.io/docs/authentication-via-api-key) - [PayFit console](https://app.payfit.com/integrations/hub/api) - [Scopes pour les partenaires](undefined) - [Démarrer avec l’API PayFit](undefined) --- # Probo + Lutril: setup guide > Lutril se connecte à Probo avec un jeton d’API en Bearer, votre identifiant d’organisation et l’URL de base de votre instance, ce qui lui permet de lire et de gérer les données de conformité. Source: https://www.lutril.com/fr/integrations/probo Category: Security Auth: api_key Last verified: 2026-06-17 --- ## Setup 1. Connectez-vous à votre instance Probo en tant qu’administrateur. 2. [object Object] 3. Générez un jeton d’API et copiez-le (conservez-le en lieu sûr, c’est un jeton Bearer). 4. Relevez l’URL de base de votre instance et votre identifiant d’organisation (l’identifiant org_). 5. Dans Lutril, connectez Probo, puis saisissez l’URL de base, l’identifiant d’organisation et le jeton d’API. ## Access requested - Jeton d’API en Bearer envoyé dans l’en-tête Authorization, avec l’identifiant d’organisation transmis à chaque requête ## References - [Probo documentation](https://www.probo.com/docs/api/mcp/overview) - [Documentation Probo](undefined) --- # Productboard + Lutril: setup guide > Lutril se connecte à Productboard avec un jeton d’accès à l’API publique, ce qui lui permet de lire et de gérer votre espace de travail. Source: https://www.lutril.com/fr/integrations/productboard Category: Product Auth: api_key Last verified: 2026-06-17 --- ## Setup 1. Connectez-vous à Productboard en tant que Maker avec un accès Admin. 2. Ouvrez Workspace Settings, Integrations, Public API, Access Token. 3. Cliquez sur le bouton plus pour générer un nouveau jeton d’accès et copiez-le. 4. Dans Lutril, connectez Productboard et collez la clé d’API. ## Access requested - Accès à l’API publique (la création du jeton requiert un Maker disposant d’un accès Admin) ## References - [Productboard documentation](https://developer.productboard.com/) - [Référence de l’API publique Productboard](undefined) --- # Redmine + Lutril: setup guide > Lutril se connecte à votre Redmine auto-hébergé en OAuth : vous saisissez l’URL de base de votre Redmine, puis vous autorisez Lutril depuis l’application. Une clé d’API REST personnelle est acceptée en solution de repli manuelle. Source: https://www.lutril.com/fr/integrations/redmine Category: Project management Auth: oauth Last verified: 2026-06-17 --- ## Setup 1. Saisissez l’URL de base de votre Redmine dans Lutril (par exemple https://redmine.votreentreprise.com). 2. Cliquez sur Connecter Redmine dans Lutril et validez l’écran d’autorisation OAuth sur votre instance Redmine. 3. Repli : un administrateur Redmine active l’API REST dans Administration, puis Configuration, puis l’onglet API, en cochant Activer l’API REST et en enregistrant. 4. Repli : chaque utilisateur ouvre Mon compte sur /my/account et copie la clé d’accès API dans le panneau de droite. 5. Repli : collez cette clé d’API dans Lutril au lieu de passer par OAuth. ## References - [Redmine documentation](https://www.redmine.org/projects/redmine/wiki/Rest_api) - [Référence de l’API REST Redmine](undefined) - [Ticket de suivi du fournisseur OAuth2](undefined) --- # Scaleway + Lutril: setup guide > Lutril se connecte à Scaleway avec une clé d’API IAM (clé secrète) rattachée à votre organisation, plus votre identifiant d’organisation, ce qui lui permet de lire et de gérer les membres IAM. Source: https://www.lutril.com/fr/integrations/scaleway Category: Infrastructure Auth: api_key Last verified: 2026-06-17 --- ## Setup 1. [object Object] 2. Cliquez sur + Générer une clé d’API et choisissez le porteur (vous-même ou une application IAM). 3. Renseignez éventuellement une description et une expiration, puis générez la clé. 4. Copiez la clé secrète (elle n’est affichée qu’une fois). Retrouvez votre identifiant d’organisation sur la page Paramètres de l’organisation. 5. Dans Lutril, connectez Scaleway, puis saisissez l’identifiant d’organisation et la clé secrète. ## Access requested - Clé d’API IAM (clé d’accès et clé secrète) rattachée à une seule organisation, portant les permissions de son utilisateur ou de son application IAM ## References - [Scaleway documentation](https://www.scaleway.com/en/docs/iam/how-to/create-api-keys/) - [Scaleway console](https://console.scaleway.com/iam/api-keys) - [Gérer les clés d’API](undefined) - [Référence de l’API IAM](undefined) --- # Slack + Lutril: setup guide > Slack se connecte en OAuth, il n’y a donc aucune clé d’API à coller. Quand vous cliquez sur Connecter, Slack vous demande d’approuver les scopes que Lutril réclame pour lire les membres et publier les notifications d’accès. Source: https://www.lutril.com/fr/integrations/slack Category: Communication Auth: oauth Last verified: 2026-06-17 --- ## Setup 1. Dans Lutril, ouvrez Paramètres → Intégrations et cliquez sur Connecter pour Slack. 2. Vous êtes redirigé vers Slack pour autoriser l’application Lutril sur votre espace de travail. 3. Vérifiez les scopes bot et utilisateur demandés, puis cliquez sur Allow. 4. Slack vous redirige vers Lutril et la connexion s’établit automatiquement. ## Access requested - Bot : users:read, users:read.email, team:read, app_mentions:read, channels:history, chat:write, im:history, im:write - Utilisateur : admin, channels:read, channels:history, chat:write, users:read, users:read.email ## References - [Slack documentation](https://docs.slack.dev/authentication/installing-with-oauth/) - [Référence des scopes OAuth](undefined) --- # Smallstep + Lutril: setup guide > Lutril se connecte à Smallstep avec un jeton d’API en Bearer, ce qui lui permet de lire et de gérer vos appareils et vos comptes. Vous pouvez éventuellement définir l’URL de base de l’API. Source: https://www.lutril.com/fr/integrations/smallstep Category: Infrastructure Auth: api_key Last verified: 2026-06-17 --- ## Setup 1. [object Object] 2. Ouvrez la section Settings dans le menu en bas à gauche. 3. Cliquez sur Add a Token, donnez-lui un titre explicite, et choisissez la durée de validité et les scopes. 4. Copiez le secret du jeton d’API (affiché une seule fois). Dans Lutril, connectez Smallstep, collez le jeton, et définissez éventuellement l’URL de base de l’API. ## Access requested - Jeton d’API en Bearer avec les scopes choisis à la création, permettant à Lutril de lire et de gérer les données du compte ## References - [Smallstep documentation](https://support.smallstep.com/getting-started-with-the-customer-api) - [Référence de l’API Platform](undefined) --- # Snowflake + Lutril: setup guide > Lutril a besoin de votre identifiant de compte et d’un jeton d’accès programmatique pour lister, créer, désactiver des utilisateurs Snowflake et leur attribuer des rôles via l’API REST. Chaque instruction ci-dessous s’exécute dans une feuille de calcul Snowsight, en cinq minutes environ de bout en bout. Snowflake cloisonne les rôles et les utilisateurs par compte : un jeton n’atteint jamais que le compte dans lequel il a été créé. Répétez donc l’opération pour chaque environnement à gouverner. Source: https://www.lutril.com/fr/integrations/snowflake Category: Infrastructure Auth: api_key Last verified: 2026-08-11 --- ## Setup 1. [object Object] 2. [object Object] 3. [object Object] 4. [object Object] 5. [object Object] 6. [object Object] 7. [object Object] 8. Dans Lutril, connectez Snowflake et collez l’identifiant de compte et le jeton. Programmez un rappel pour renouveler le jeton avant l’expiration choisie : quand un jeton expire, l’inventaire et le provisionnement s’arrêtent, et toute revue d’accès portant sur ce compte devient obsolète. ## Access requested - SECURITYADMIN, attribué à l’utilisateur de service et défini comme ROLE_RESTRICTION du jeton - Une politique réseau couvrant l’utilisateur de service (Snowflake en exige une pour qu’un jeton de service fonctionne) - API REST v2 : GET /users, GET /roles, POST /users, PUT /users/{name}, POST /users/{name}/grants ## References - [Snowflake documentation](https://docs.snowflake.com/en/user-guide/programmatic-access-tokens) - [Snowflake console](https://app.snowflake.com) - [Identifiants de compte](undefined) - [Référence CREATE USER](undefined) - [Politiques réseau](undefined) - [Référence utilisateurs de l’API REST](undefined) - [Authentification de l’API REST](undefined) --- # Sonatype Nexus Repository + Lutril: setup guide > Lutril se connecte à votre Nexus Repository auto-hébergé avec un jeton utilisateur employé en authentification Basic. Vous fournissez l’URL de base, le code du nom de jeton comme identifiant, et le code secret du jeton comme mot de passe. Source: https://www.lutril.com/fr/integrations/nexus Category: Developer tools Auth: api_key Last verified: 2026-06-17 --- ## Setup 1. Dans Nexus Repository, cliquez sur votre nom d’utilisateur en haut à droite de la barre d’outils pour gérer votre compte. 2. Ouvrez l’onglet User Token dans la navigation de gauche, puis cliquez sur Access User Token. 3. Saisissez à nouveau vos identifiants et authentifiez-vous ; copiez le code du nom de jeton (identifiant) et le code secret du jeton (mot de passe). 4. Dans Lutril, connectez Nexus, saisissez l’URL de base de votre Nexus, puis le code du nom de jeton comme identifiant et le code secret comme mot de passe. ## Access requested - Les permissions de l’utilisateur Nexus auquel appartient le jeton (un rôle administrateur est nécessaire pour gérer les utilisateurs) ## References - [Sonatype Nexus Repository documentation](https://help.sonatype.com/en/user-tokens.html) - [Référence de l’API des jetons utilisateur](undefined) --- # Sybill + Lutril: setup guide > Lutril se connecte à Sybill avec un jeton d’API et l’URL de base de l’API, ce qui lui permet de lire et de provisionner les personnes de votre espace de travail Sybill. Source: https://www.lutril.com/fr/integrations/sybill Category: Sales & CRM Auth: api_key Last verified: 2026-06-17 --- ## Setup 1. [object Object] 2. Générez un nouveau jeton d’API et copiez-le immédiatement, Sybill n’affiche la valeur qu’une fois. 3. Relevez l’URL de base de l’API (l’hôte REST de production est https://api.sybill.ai). 4. Dans Lutril, connectez Sybill, collez le jeton d’API, et saisissez l’URL de base. ## Access requested - Accès à l’espace de travail (lecture et gestion des membres) selon le rôle associé au jeton ## References - [Sybill documentation](https://api.sybill.ai/docs/introduction.html) - [Sybill console](https://app.sybill.ai) - [Centre d’aide Sybill](undefined) --- # Teamtailor + Lutril: setup guide > Lutril se connecte à Teamtailor avec une clé d’API, ce qui lui permet de lire et de gérer les utilisateurs et les données de recrutement. Vous pouvez éventuellement définir une URL de base adaptée à votre région. Source: https://www.lutril.com/fr/integrations/teamtailor Category: Recruiting Auth: api_key Last verified: 2026-06-17 --- ## Setup 1. Connectez-vous à Teamtailor avec un utilisateur disposant d’un accès Company Admin. 2. [object Object] 3. Cliquez sur + New API Key en haut à droite. 4. Choisissez le type de clé : prenez les permissions Admin en lecture et écriture pour une gestion complète. 5. Copiez la clé d’API (elle n’est pas modifiable ensuite, seulement supprimable). Dans Lutril, connectez Teamtailor, collez la clé, et définissez éventuellement l’URL de base. ## Access requested - Admin (accès complet au compte) en lecture et écriture, pour que Lutril puisse lister et gérer les utilisateurs et les données du compte ## References - [Teamtailor documentation](https://support.teamtailor.com/en/articles/5963369-use-our-teamtailor-api) - [Documentation de l’API Teamtailor](undefined) --- # TeamViewer + Lutril: setup guide > Lutril a besoin d’un jeton de script TeamViewer disposant des permissions de gestion des utilisateurs. Il liste les membres de votre entreprise avec leurs rôles, leur statut de authentification à deux facteurs et leur date de dernier accès, provisionne les nouveaux utilisateurs et désactive les comptes au départ des personnes. Source: https://www.lutril.com/fr/integrations/teamviewer Category: Security Auth: api_key Last verified: 2026-08-04 --- ## Setup 1. [object Object] 2. Cliquez sur votre nom d’utilisateur en haut à droite, puis sélectionnez Modifier le profil, puis Apps. 3. Cliquez sur Créer un jeton de script, nommez-le (par exemple « Lutril »), et sous Gestion des utilisateurs cochez consulter, créer et modifier des utilisateurs. Autorisez aussi la consultation des rôles si votre offre le permet. 4. Cliquez sur Créer et copiez le jeton ; TeamViewer ne l’affiche qu’une fois (un jeton n’est pas modifiable ensuite, il faut le supprimer et le recréer). 5. Dans Lutril, ouvrez Intégrations, choisissez TeamViewer, et collez le jeton dans le champ Script Token. ## Access requested - Gestion des utilisateurs : consulter, créer et modifier des utilisateurs (synchronisation d’annuaire, provisionnement à l’arrivée, désactivation au départ) - Gestion des rôles utilisateurs : consulter les rôles (alimente le sélecteur de rôle lors d’une attribution d’accès ; facultatif) ## References - [TeamViewer documentation](https://www.teamviewer.com/en/global/support/knowledge-base/teamviewer-remote/for-developers/use-the-teamviewer-api/) - [TeamViewer console](https://login.teamviewer.com/nav/api) - [Référence de l’API web TeamViewer (gestion des utilisateurs)](undefined) - [Créer une intégration TeamViewer](undefined) --- # TrackingTime + Lutril: setup guide > Lutril se connecte à TrackingTime avec un App Password utilisé comme jeton d’accès, plus un identifiant client qui désigne l’application. Avec ces deux éléments, Lutril peut lire et gérer les données de votre compte. Source: https://www.lutril.com/fr/integrations/trackingtime Category: Time tracking Auth: api_key Last verified: 2026-06-17 --- ## Setup 1. Connectez-vous à TrackingTime. 2. [object Object] 3. Créez un nouvel App Password et copiez la valeur générée (c’est votre jeton d’accès). 4. Dans Lutril, connectez TrackingTime, collez l’App Password comme jeton d’accès, et saisissez l’identifiant client qui nomme votre application. ## Access requested - App Password utilisé comme jeton d’accès en authentification Basic, donnant à Lutril accès aux données de votre compte TrackingTime ## References - [TrackingTime documentation](https://support.trackingtime.co/en/articles/6329119-apps-integrations) - [Documentation de l’API publique](undefined) - [Recommandations d’usage de l’API](undefined) --- # Userflow + Lutril: setup guide > Lutril se connecte à Userflow avec une clé d’API personnelle, ce qui lui permet de gérer les membres et les invitations de votre compte. Vous fournissez également votre Account ID. Source: https://www.lutril.com/fr/integrations/userflow Category: Product Auth: api_key Last verified: 2026-06-17 --- ## Setup 1. [object Object] 2. Créez une nouvelle clé d’API personnelle et copiez-la ; gardez-la secrète. 3. Retrouvez l’Account ID du compte que Lutril doit gérer (il apparaît dans les endpoints de compte de l’API, par exemple /accounts/{account_id}). 4. Dans Lutril, connectez Userflow, collez le jeton d’accès personnel, et saisissez l’Account ID. ## Access requested - Accès aux comptes auxquels vous appartenez, selon votre rôle Userflow (le rôle Owner est nécessaire pour ajouter des membres) ## References - [Userflow documentation](https://docs.userflow.com/docs/api) - [Userflow console](https://app.userflow.com) - [Référence de l’API Accounts de Userflow](undefined) - [Gérer les équipes dans Userflow](undefined) --- # Zapier + Lutril: setup guide > Lutril provisionne et déprovisionne les membres Zapier via SCIM. Vous activez le provisionnement d’utilisateurs dans Zapier, copiez le jeton Bearer généré, et le collez dans Lutril avec l’URL de base SCIM. Source: https://www.lutril.com/fr/integrations/zapier Category: Automation Auth: api_key Last verified: 2026-06-17 --- ## Setup 1. [object Object] 2. Cliquez sur Enable pour activer le provisionnement d’utilisateurs. Zapier génère un jeton d’authentification (le provisionnement d’utilisateurs requiert un plan Zapier Enterprise). 3. Copiez le jeton généré. Vous pouvez le régénérer depuis la même page s’il est perdu ou compromis. 4. Dans Lutril, collez https://zapier.com/scim/v3 comme SCIM Base URL et le jeton comme API Token, puis enregistrez. ## Access requested - SCIM v2 : envoi des nouveaux utilisateurs, des mises à jour de profil, désactivation et réactivation des utilisateurs ## References - [Zapier documentation](https://help.zapier.com/hc/en-us/articles/8496291497741-Provision-user-accounts-with-SCIM) - [Zapier console](https://zapier.com/app/settings/user-provisioning) - [Provisionner les comptes utilisateurs avec SCIM](undefined) --- # Zendesk + Lutril: setup guide > Zendesk se connecte en OAuth, avec des accès en lecture et en écriture. Vous saisissez votre sous-domaine Zendesk, puis vous autorisez l’application Lutril. Un jeton d’API est accepté en solution de repli manuelle. Source: https://www.lutril.com/fr/integrations/zendesk Category: Support Auth: oauth Last verified: 2026-06-17 --- ## Setup 1. Dans Lutril, ouvrez Paramètres → Intégrations, sélectionnez Zendesk, et saisissez votre sous-domaine (la partie avant .zendesk.com). 2. Cliquez sur Connecter ; vous êtes redirigé vers Zendesk pour autoriser l’application Lutril en lecture et écriture. 3. Cliquez sur Allow ; Zendesk vous redirige vers Lutril et la connexion est établie. 4. Repli : dans le centre d’administration Zendesk → Applications et intégrations → API → API Zendesk, activez l’accès par jeton et ajoutez un jeton d’API. 5. Collez ensuite votre e-mail d’administrateur et le jeton d’API dans les champs manuels de Lutril. ## Access requested - read (lire les utilisateurs et les organisations) - write (provisionner et mettre à jour les utilisateurs) ## References - [Zendesk documentation](https://support.zendesk.com/hc/en-us/articles/4408889192858-Managing-API-token-access-to-the-Zendesk-API) - [Gérer l’accès par jeton OAuth](undefined)