> On 6 Jan 2026, at 12:19, Simon Pichugin <[email protected]> wrote: > > Hey William, > > On Mon, Jan 5, 2026 at 5:23 PM William Brown via 389-users > <[email protected] > <mailto:[email protected]>> wrote: >> >> Hey there, >>> Important Notes >>> >>> - Experimental - Early-stage project, APIs may change >>> - Read-only - No write operations yet >> >> I think we should never allow write operations. LLM's are statistically >> plausible sentence generators, not intelligent beings with context and >> understanding. >> >> There are already far too many cases where "LLM Agents" have destroyed >> peoples data and systems when given write access. >> >> Given the critical nature of LDAP in many environments, I would be extremely >> against any kind of write functionality in this given the high risks >> associated. >> >> If write access is to be developed, it should be feature gated behind a >> safety switch, and default to "false" (aka read-only by default). > > That's the intention. And generally, I don't plan it any time soon as it's > the least desired feature. Reindex and fixup tasks? That might be sooner, but > still it'll be guarded with the switch with the default to 'false'.
Even then, LLM's have been shown to bypass and avoid developer implemented limits. I'd be very hesitant about this. For example, a reindex task takes your instance temporarily offline. What if the LLM decides a reindex is needed before you gave it consent? What if it reindexs all your systems in parallel rather than one at a time? Even this is potentially an outage in the making. > >> >>> - Privacy mode - Set LDAP_MCP_EXPOSE_SENSITIVE_DATA=false to anonymize >>> output >> >> Privacy should be the default IMO, especially given how LLMs may harvest >> data. > > It is default to not provide any sensitive data to LLM. It can be turned off > for cases (ideally) when the model is local, for example. Okay, it wasn't clear in how you wrote it. > >> >>> - Plain text passwords - Use restrictive file permissions on config files >>> >>> Feedback >>> >>> I'd love to hear your thoughts: >>> - What diagnostics would be most useful? >>> - What operations would you want AI assistance with? >> >> Honestly? I don't think we should have MCP anywhere near 389-ds. I know that >> you will have worked a lot on this, and I'm sure there was a "business >> reason" your employer probably wanted you to implement this for. >> >> But as I have said - LDAP is a high value, important, and critical piece of >> infrastructure in many environments. If LDAP stops - the business stops. >> >> To have an MCP/LLM trying to "summarise and advise" about how one of the >> most critical pieces of software in an environment works seems like a recipe >> for disaster. >> >> As a former sysadmin, I would not want MCP anywhere near systems. Systems >> require insight, understanding, and thought to manage. Systems do not need >> "statistically plausible sentence generators". >> >> There are many ways we can make LDAP and 389-ds easier and more accessible >> to administrators, to assist them with understanding the state of their >> systems. But MCP/LLMs are not it. > > I appreciate the thoughtful feedback, and I think you raise valid concerns > about AI and critical infrastructure. But I'd push back a bit on the framing > here. > > This isn't about having an LLM "advise" on how to run your directory service, > or make autonomous decisions about your topology. It's a read-only diagnostic > wrapper around lib389. > > Think about what the tool actually does - it calls healthcheck, parses > replication status, looks for unindexed searches in logs (not LLM parses, > lib389 parses, - LLM gets only the 'yes or no' answer - and more if sensitive > is off), gives monitor output. These are things you'd do yourself with dsconf > or by reading documentation. The MCP layer just lets you ask "are there any > unindexed searches?" instead of remembering the exact incantation to grep the > logs or which dsconf subcommand to use. lib389 does the job and we are making > sure it's correctly implemented. The human still sees the output (and MCP > logs for the exact lib389 output). The human still decides what to do. The > human still runs dsconf or edits dse.ldif themselves. Nothing writes to the > directory. > > You're right that LDAP is critical infrastructure. You're right that LLMs > make mistakes. But there's a difference between "AI agent manages your LDAP > topology" and "natural language interface to lib389 that returns diagnostic > information." This is the latter. The concern is that the diagnostic information may be *altered* or *misrepresented*. This isn't just "calling healthcheck" - it's calling healthcheck with a transformation layer in between that *can* and *will* alter that output. And that transformation layer is a "statistically plausible sentence generator" so your framing of how you make a request can cause that data to be altered. And that's the problem - if the LLM tells you what you want to hear, or alters the data, it may mask a critical or important detail in it's output. This prevents the human from being able to intervene, investigate, and understand the situation. > > If your concern is that sysadmins will blindly trust LLM output without > verification - that's a valid concern, but it's also true of any > documentation, any Stack Overflow answer, any vendor support response. The > tool surfaces information; it doesn't replace the judgment needed to act on > it. That judgment was always required - with or without MCP. For experienced > admins who understand what they're looking at, I think it can be a useful > convenience. As an experienced admin, this would be a hinderance - not a convenience. I would forever be doubting if the surfaced information is truthful or not. There are better ways we can surface information about 389-ds to promote transparency and understanding for our admins and users. Again, in my view, this is not it. -- Sincerely, William Brown Senior Software Engineer, Identity and Access Management SUSE Labs, Australia
-- _______________________________________________ 389-users mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/[email protected] Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
