Monday, January 5, 2026

[389-users] Re: [ANN] LDAP Assistant MCP v0.2.0 - AI-Powered 389 DS Diagnostics

Hey William,

On Mon, Jan 5, 2026 at 5:23 PM William Brown via 389-users <389-users@lists.fedoraproject.org> 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'.
 

- 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.


- 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.

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.

Sincerely,
Simon
 
 

-- 
Sincerely,

William Brown

Senior Software Engineer,
Identity and Access Management
SUSE Labs, Australia

--
_______________________________________________
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org
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/389-users@lists.fedoraproject.org
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)