navicat cloud 不支持临时访问凭证，仅同步连接配置、查询等元数据，不托管数据库连接或管理凭据生命周期；临时权限必须由数据库服务端控制，如设置短期密码、ip白名单或sts令牌。
Navicat Cloud 不支持为外包团队设置临时访问凭证。
它只同步连接配置（如主机、端口、数据库名）、查询、代码段等元数据，不托管、不代理、不转发数据库连接，更不提供凭据生命周期管理能力。所谓“临时访问”，实际要解决的是：外包人员在有限时间内安全使用数据库，且事后可快速回收权限——这必须由数据库服务端控制，而非 Navicat 客户端层。
Navicat Cloud 里根本不存在“临时凭证”这个功能
-
Navicat Cloud的账户体系是静态的：一个邮箱注册一个账号，登录即获得完整同步权限； - 它不提供角色分级、会话时效、IP 白名单、MFA 强制、或按项目/时间粒度授权的能力；
- 即使你把外包人员拉进共享项目，他们只要登录自己的
Navicat Cloud账号，就能永久看到所有已同步的连接和查询——除非你手动移除其协作权限，或删除整个项目。
真正该控制临时访问的地方是数据库服务端
外包人员最终连的是 MySQL / PostgreSQL / Redis，不是 Navicat Cloud。所以临时性必须落在：
- 创建专用数据库用户，并设短期密码（例如 7 天有效期）；
- 使用数据库原生的过期机制（如 MySQL 8.0+ 的
password_expired、PostgreSQL 的VALID UNTIL）； - 配合网络层限制：只允许其 IP 段访问，或强制走公司堡垒机；
- 若用云数据库（如 AWS RDS、阿里云 PolarDB），启用 IAM 角色 + 临时安全令牌（
STS），让外包方通过短期AccessKeyId/SecretAccessKey连接。
Navicat Cloud 在这里唯一能做的，是同步那个「已配好 host/port/username 的连接」，但密码字段不会明文存——它依赖本地客户端解密后填充，且一旦外包人员拿到该连接，只要密码没改，就能一直连。
如果非要用 Navicat 协作，必须配合外部流程管控
- 不在
Navicat Cloud中保存密码：创建连接时不勾选 Save password，这样同步过去后，外包人员双击连接仍需手动输密码——你只需定期重置该数据库用户的密码； - 所有连接统一用域名（如
db-staging.company.internal），而非localhost或硬编码 IP，避免外包本地环境误连； - 同步前检查连接是否启用了 SSL：若数据库要求
require_secure_transport，而 Navicat 连接未勾选 SSL 选项，外包人员会直接报错Connection refused或SSL connection error，这不是凭证问题，而是配置缺失。
外包人员退出后，最常被忽略的一点是：他们本地 Navicat 客户端里可能还缓存着旧连接、历史查询、甚至导出过的表结构 SQL。这些不会因你从 Navicat Cloud 移除其协作权限而自动清除——得靠终端管理策略或人工确认卸载。
