A new self-hosted option means the legal-AI chat can run on infrastructure you control instead of a third-party cloud.
nforum/mike
Active fork adding OpenAI/vLLM providers, user-controlled MCP connectors, and LLM-layer security guardrails
nforum/mike is running several concurrent feature tracks. The most substantial work adds user-configurable MCP server connectors with OAuth 2.1 - end users can register Streamable-HTTP MCP servers from the account settings, and those tools surface to the chat agent under a mcp__<slug>__<tool> namespace. It's the most security-aware MCP implementation in this cohort of forks: RLS-gated storage, HMAC-signed state tokens for the OAuth popup, and PKCE. Credential encryption is called out as deferred.
On the model side, the fork adds OpenAI (GPT-5.5 / GPT-5.4 Nano) as a third provider, then unifies it with a vLLM/LocalLLM provider in a shared openai.ts factory that dispatches on model id prefix. The architecture is reasonable for multi-provider or on-prem scenarios, but the reconciling merge bakes in default-model preferences that favor vLLM when the env var is set - something to override before deploying.
A security PR appends intent-based refusal instructions to the system prompt: system prompt confidentiality, a PII enumeration list, and tool-use boundaries. Prompt-only guardrails, so they're best-effort, but the PII list and intent-framing are well thought out for a legal product.
There's also a docs-only workflow pack format proposal - YAML files with a JSON Schema that map to existing workflow DB columns. No importer yet, just a schema and examples.
What's in it
- OpenAI provider support Adds GPT-5.5 and GPT-5.4 Nano as first-class model choices alongside Claude and Gemini.
- Self-hosted LocalLLM backend Point Mike at a vLLM endpoint to run inference on your own infrastructure instead of a hosted API.
- User-configurable MCP connectors End users can register their own MCP servers from account settings, with OAuth 2.1, and expose those tools to the chat agent.
- Safety and confidentiality guardrails Intent-based refusals covering system-prompt confidentiality, PII handling, and tool-use boundaries.
- Tighter project boundary checks Hardens authorization around project-folder operations to prevent cross-project access.
- Declarative workflow packs (proposal) A documented YAML format for checking shareable workflow packs into a repo and importing them into Mike.
Direction
integrationsecurityworkflow
Activity
OpenAI now sits alongside Claude and Gemini as a pickable model provider in nforum's fork.
A new set of refusal rules tells the assistant to clam up on personal data, resist prompt-leak tricks, and stay inside its lane on tool use.
📝 nforum wants Mike's workflows to travel between deployments 3 commits 2mo ago workflowknowledge-management draft
A proposal to turn legal workflows into portable, version-controlled files instead of settings locked inside one installation.
📝 nforum quietly stops logging every AI exchange to disk 2 commits 2mo ago securityinfrastructure draft
A fork that was writing the raw output of every AI response to a file on the server - in production - now keeps that turned off by default.
📝 nforum closes a cross-project back door in folder handling 2 commits 2mo ago securityknowledge-management draft
Three document-organization endpoints were trusting folder IDs without checking which project they belonged to - nforum tightened all three.
End users can now connect Mike to outside services themselves - no engineer required - and sign in to them securely.
Threads of work (detailed view)
nforum lets Mike run on your own hardware
A new self-hosted option means the legal-AI chat can run on infrastructure you control instead of a third-party cloud.
vLLM/LocalLLM provider via OpenAI-compatible client
nforum adds support for self-hosted vLLM endpoints alongside cloud providers. The conflict-resolving merge that united this with the OpenAI PR is the most consequential piece - it rewires defaults in a way that deserves a second look before import.
nforum hands Mike a third AI engine: OpenAI
OpenAI now sits alongside Claude and Gemini as a pickable model provider in nforum's fork.
OpenAI added as third LLM provider (GPT-5.5, GPT-5.4 Nano)
nforum adds OpenAI support alongside Claude and Gemini, following the same BYOK pattern already established for the other two providers.
nforum teaches Mike when to say no
A new set of refusal rules tells the assistant to clam up on personal data, resist prompt-leak tricks, and stay inside its lane on tool use.
System prompt gains confidentiality, PII, and tool-use guardrails
nforum adds 35 lines to the system prompt covering three refusal categories: system prompt leakage, PII extraction, and tool-use boundaries. All three use intent-based refusal - the model is told to decline based on what is being asked, not whether the relevant data is currently available.
nforum wants Mike's workflows to travel between deployments
A proposal to turn legal workflows into portable, version-controlled files instead of settings locked inside one installation.
Declarative workflow pack format proposed (docs and schema only)
nforum's amiel-35 proposes a YAML-based workflow pack format checked into the repo, with a JSON Schema and two example files. No importer exists yet - this is a design artifact for a future build.
nforum quietly stops logging every AI exchange to disk
A fork that was writing the raw output of every AI response to a file on the server - in production - now keeps that turned off by default.
nforum closes a cross-project back door in folder handling
Three document-organization endpoints were trusting folder IDs without checking which project they belonged to - nforum tightened all three.
nforum lets users plug their own tools into Mike
End users can now connect Mike to outside services themselves - no engineer required - and sign in to them securely.
User-configured MCP Connectors with OAuth 2.1
nforum lets end users register Streamable-HTTP MCP servers from the account settings page and expose those tools to the chat agent. The three-commit feature covers the data model, a polished UI, and a full OAuth 2.1 flow with PKCE and dynamic client registration.