> For the complete documentation index, see [llms.txt](https://docs.durohub.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.durohub.com/ai-integration/security.md). # What the AI Can See Connecting an AI assistant to your PLM is a reasonable thing to be careful about. This page is the honest answer to "what happens if someone does that?" — written to be forwarded to whoever needs to approve it. ## The short version * It sees **one library** — the one you picked when you signed in. Not your other ones. * It acts as **you**, with your permissions. It cannot do anything you couldn't do yourself. * Everything it changes is **attributed to you** in the change history. * The credential **expires after 90 days** and you can revoke it in Duro at any time. * Your **AI client never sees your password**. You sign in on Duro's own page, as always. ## How the connection is authorized When you add the MCP server, no credential exists yet. The first time your assistant tries to use it, this happens: 1. The server refuses the request and tells the client where to authenticate. 2. Your browser opens **Duro's own sign-in page**. You sign in exactly as you normally do — including SSO, if your organization uses it. 3. Duro shows you a consent screen naming the application that asked, and asks which organization and library to connect. 4. Your choice is exchanged for an API key scoped to that one library, and handed to your client. The credential your assistant holds is an ordinary Duro API key — the same kind you can create by hand under **Library Settings → API Keys**. There is no separate identity, no shadow account, and no new permission system to reason about. If you already understand Duro API keys, you already understand this. The flow is OAuth 2.1 with PKCE. Your password is never sent to the MCP server or to your AI client. ## Library scoping This is the part worth understanding properly, because it's stronger than it sounds. The key is bound to a single library at the moment it's created. Duro enforces that binding on **every request**, server-side. It is not a filter the assistant applies, and not something a cleverly-worded prompt can talk its way around. The practical consequence: if you belong to three libraries and connect to one of them, a part in either of the other two is **not found** as far as this connection is concerned. Not "access denied" — genuinely invisible, the same as a CPN that doesn't exist. To work in a different library, remove the connection and add it again, choosing that library. Or keep two connections, named for the libraries they point at. ## Permissions The key carries your identity, so your role applies unchanged. A viewer's assistant can read and cannot write. If your role can't submit change orders, neither can your assistant. Roles are described in [Role-Based Access Control](/advanced-topics/rbac.md). Two things follow from this that are easy to miss: **Your assistant can write.** Creating components, editing them, opening and submitting change orders — these are all available if your role allows them. Most MCP clients ask you to approve a tool call the first time. Read what you're approving, particularly for `duro_change_order_submit`, which starts a real review that real people get notified about. **Everything is attributed to you.** Change history, `createdBy`, `updatedBy`, and change order authorship all record you, not "an AI". That's deliberate — it keeps the audit trail honest — but it does mean you own what it does. ## The credential's life | | | | -------------- | ----------------------------------- | | **Type** | Library-scoped Duro API key | | **Lifetime** | 90 days from issue | | **Stored** | By your MCP client, on your machine | | **Visible in** | Library Settings → API Keys | | **Revoke** | Same page, any time | Revoking takes effect immediately. Your assistant's next call fails and it will offer to re-authenticate. Because the key is a normal API key, it shows up in the same list as the ones you created yourself, and can be audited the same way. ## What it can do Within the one library you chose, and only as far as your own role reaches: * Search and read components, assemblies, and BOMs * Create and update components * Upload files and attach documents * Open, add items to, and submit change orders * Run Duro's own validation rules without saving anything Every one of these is something you can already do yourself in the web app or with an API key you made by hand. Nothing here is new capability — it is the same capability through a different door. ## What it cannot do * Reach a library you didn't select, or one you're not a member of * Exceed your role's permissions * See your password, or authenticate as anyone else * Change library configuration — categories, statuses, CPN schemes, workflows, RBAC * Manage API keys, webhooks, or users * Act while you're offline. It runs only when you ask it something ## For administrators **What connecting looks like from your side.** Each connection appears as an API key in that library's settings, attributed to the member who created it. You can see who has connected, and revoke any of them. **It grants nothing new.** The MCP server is a front end to the same GraphQL API, with the same authorization. A member cannot reach data through it that they couldn't reach with an API key they made themselves, or by clicking through the web app. **If you restrict API key creation**, that restriction applies here too — the consent screen only offers libraries the member can actually open. **Data leaving your tenant.** Your assistant reads Duro data into its own context to answer you, which means that data reaches your AI provider the same way anything else you paste into an assistant does. That's a question about your AI vendor's terms, not about Duro, but it's the right question to ask and it belongs in the same review. ## Reporting a problem Found something that looks wrong? Email ****. For anything you believe is a security issue, say so in the subject line and we'll route it accordingly. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.durohub.com/ai-integration/security.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.