[Security/UX] Add warning when users enter API keys on untrusted instances

[YizukiAme]

Problem

When users configure their AI provider API keys through the settings UI, there is no indication that the key will be transmitted to and processed by the server. This is the expected architecture — the server needs the key to call AI APIs on behalf of the user.

However, OpenMAIC instances can be deployed as public services by anyone. Users who discover these instances (e.g. via search engines) may not understand that entering their API key grants the instance operator full access to that key. This differs from platforms like ChatGPT where users authenticate against the official provider directly.

Proposal

Add a brief security notice near the API key input field in provider settings. Something like:

⚠️ Your API key will be sent to the server hosting this instance. Only enter your key if you trust the operator of this deployment.
This should be:

• Visible but not intrusive (e.g. a small info tooltip or muted text below the input)
• Localized (zh-CN / en at minimum)
• Shown for all provider types that accept user-supplied keys

Context

This is an inherent limitation of the proxy architecture, shared by all similar projects (ChatGPT-Next-Web, LobeChat, etc.). It cannot be "fixed" technically — but user awareness can be improved significantly with a simple UI change.

No API or behavior changes needed. This is purely a UX/security-awareness improvement.

That said, attackers can easily revert it

[KanameMadoka520]

也许可如此解决这个问题：
1，在 API Key 输入区增加明确的信任提示，也就是此issue所提出的。
当前用户输入的 key 会通过 OpenMAIC 自己的 /api/* 路由用于验证、聊天、内容生成等流程。
界面应明确提示：该 key 会经过当前实例的服务器，只有在信任该部署者时才应填写。

2，更明确地引导使用服务端配置
可以考虑支持一个部署者可配置的提示，比如 SECURITY_NOTICE：
如果部署者配置了，就显示自定义声明；如果没有配置，就显示默认安全提示。
同时，对于公开 / 共享部署，也建议更明确地引导部署者使用环境变量或 server-providers.yml 预先配置服务端 key，这样普通用户通常就不需要输入自己的个人 key。

3，更长期的方向：也许可采用客户端直连模式
从保护用户 key 的角度看，提供可选的 client-side direct mode，让浏览器直接调用上游 provider，而不是经过 OpenMAIC 后端，这样服务器就拿不到用户的 key。

然而3是比较大的架构改动，可作为后续单独的增强议题，取决于OPENMAIC是否希望实现这种实例会公开提供使用，支持陌生用户自带key使用的情景，还是保持在私人部署范围内。

关于“That said, attackers can easily revert it”
难以有完美的方案处理此问题，所以也许可以降低用户对第三方实例的依赖：
极简部署： 让私有部署变得极其简单，让用户没必要去用别人的公共实例。
教育用户： 在所有文档、视频、教程中强调：“不要在非自建实例输入 Key”。

[YizukiAme]

Thanks for the insightful breakdown~!!

Agree with the overall direction, a few thoughts:

The SECURITY_NOTICE env var idea is quite nice — it lets honest deployers declare themselves. Though in the threat model we're looking at (deliberately malicious operators mentioned in #442 ), it has the same limitation as most code-level mitigations: easy to revert or simply not set.

Looked into client-side direct mode a bit. Main blocker is that most AI provider APIs (OpenAI, Anthropic, etc.) don't serve CORS headers, so browser-side requests get blocked. This would need provider-side changes to work.

After digging deeper, I think the honest conclusion is: there's not much the codebase itself can do against a malicious fork. Any warning, modal, or confirmation we add can be removed in one commit by the operator. The measures that actually work are at a different level:

• AGPL enforcement against unauthorized commercial deployments
• User education — making it very clear in docs/README that keys should only be entered on trusted instances (though sadly, most users who end up on sketchy instances via Baidu are exactly the ones who lack this kind of awareness — and if they were already visiting our GitHub, they'd know the official site 😅)
• Lowering the barrier to self-host — so users have less reason to rely on third-party instances (ironically again, users capable of self-hosting are exactly the ones who don't need this protection in the first place...)
• Longer term, AI provider OAuth — so the key never touches the intermediary server at all (not holding my breath for this one before the 22nd century though 😂)
• SEO / search engine visibility — currently, searching "OpenMAIC" on major Chinese search engines surfaces unauthorized third-party instances before the official site. Improving the official site's search ranking would be one of the most practical ways to redirect uninformed users away from sketchy deployments

That said, a lightweight inline notice (your points 1 & 2) is still worth doing as a best-effort measure — it helps the "honest but unaware deployer" case and costs almost nothing to implement! Just we can't expect it to stop a determined bad actor 🙃