立即删除泄露密钥并创建新密钥，检查调用日志识别异常行为，改用环境变量加载密钥，切换至最小权限子账号，部署请求签名验证机制。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
如果您发现 MiniMax API Key 已被泄露，攻击者可能已获得调用 MiniMax 开放平台接口的权限，进而访问模型服务、窃取提示词内容或触发异常高并发请求导致账单激增。以下是立即执行的处置与加固步骤：
一、立即禁用并重置密钥
首要动作是切断泄露密钥的全部访问能力，防止持续滥用。MiniMax 平台不支持“临时停用”，必须通过主动删除实现即时阻断。
1、登录 https://www.minimax.com/console，使用原注册账号进入控制台。
2、点击左侧导航栏【API 密钥管理】，定位到已泄露的密钥条目。
3、点击该密钥右侧的【删除】按钮，确认执行删除操作。
4、在相同页面点击【创建新密钥】，生成一组全新 Secret Key，并立即复制保存至安全位置。
5、将新密钥仅用于当前受信环境，严禁再次明文写入代码或配置文件。
二、检查调用日志与异常行为
密钥删除后需回溯其历史使用痕迹，确认是否已有未授权调用发生，尤其关注高频、跨地域、非工作时段的请求模式。
1、在【API 密钥管理】页面，点击原泄露密钥条目旁的【查看调用日志】（若仍可访问）。
2、筛选时间范围为密钥创建至删除前，导出 CSV 日志文件。
3、检查字段 client_ip 与 endpoint，识别非常规 IP 地址或高频调用 /chat/completion 等高成本接口的行为。
4、若发现可疑调用，记录对应时间戳与 IP，提交至 MiniMax 官方支持邮箱 support@minimax.com 并附日志摘要。
三、迁移至环境变量加载方式
避免密钥再次硬编码导致二次泄露，必须将新密钥从源码中剥离，改由运行时环境注入，确保其不进入 Git 历史与构建产物。
1、在部署服务器上，以运行应用的用户身份执行：
Linux/macOS：echo 'export MINIMAX_API_KEY=your_new_secret_key' >> ~/.bashrc && source ~/.bashrc
为 OpenClaw 配置 MiniMax 作为模型源。MiniMax 提供两种接入方式：API Key 直连（openai-completions 协议）和 OAuth 门户（anthropic-messages 协议）。包含 provider 注册、模型定义、别名配置、fallback 链接入和验证的完整流程。当管理员说想"加 MiniMax"、"配 minimax"、"接入 MiniMax 模型"、"加海螺模型"、&qu
2、验证注入生效：printenv MINIMAX_API_KEY 应输出密钥值，且无换行或空格。
3、修改应用初始化逻辑，将原 api_key="xxx" 替换为 os.getenv("MINIMAX_API_KEY")（Python）或等效环境读取方式。
4、检查项目根目录及所有子目录中是否存在 .env、config.json、settings.py 等含密钥字样的文件，全部删除并执行 git rm --cached 防止误提交。
四、启用最小权限子账号隔离
若当前使用主账号 API Key，应立即切换至权限受限的子账号凭证，将模型调用范围收敛至必要模型与功能，降低单点泄露影响面。
1、进入 MiniMax 控制台【团队与成员】→【子账号管理】，点击【新建子账号】。
2、填写子账号名称（如 prod-chatbot-service），勾选【仅允许 API 调用】，不授予控制台访问权限。
3、在【权限策略】中，选择或自定义策略，仅允许 POST /v1/chat/completions 及所需模型 ID（如 abab6.5s-chat），禁止 /v1/files、/v1/fine_tuning 等高危接口。
4、为该子账号生成专属 API Key，并在应用中替换原密钥。
五、部署客户端请求签名验证
在网关层对所有发往 MiniMax 的请求添加签名机制，使泄露的密钥无法脱离可信客户端独立使用，大幅提升攻击门槛。
1、在反向代理（如 Nginx）或 API 网关中，为每个请求头注入 X-Minimax-Signature 字段。
2、签名算法采用 HMAC-SHA256，密钥为独立于 MiniMax Key 的服务端密钥，原文为 method + path + timestamp + nonce。
3、MiniMax 后端服务（或前置中间件）校验该签名有效性，拒绝无签名或签名失效的请求。
4、确保 timestamp 有效期不超过 300 秒，并在服务端比对系统时间偏差。
