我想从Cursor代理连接到Azure DevOps，以读取用户故事。在工作中我们被禁止使用MCP服务器，因此必须使用Azure CLI从 Azure DevOps获取用户故事。这需要使用 azure-devops Azure CLI扩展。

不信任AI代理，我想确保它通过Azure CLI执行的命令仅具有与Azure DevOps个人访问令牌（PAT）相关的有限权限。我不希望它使用与我的Azure账户相关的更广泛权限。

我该如何做到这一点？

我已经读到将PAT保存到环境变量 AZURE_DEVOPS_EXT_PAT 中，将确保 az devops 命令使用PAT进行身份验证，而不是使用已登录的Azure CLI账户。然而，事实似乎并非如此。根据我所见，似乎Azure CLI的登录会覆盖使用Azure DevOps PAT的身份验证。

我已将Azure DevOps PAT设置为仅具有“工作项 - 读取”权限。当我执行 az logout 以注销我的Azure CLI会话，然后运行 az boards work-item show --id 123456 时，它返回一个结果，大概是使用PAT进行身份验证。如果我随后执行一个它不应有权限执行的命令，例如 az boards work-item create --title 'My test item' --type Bug --organization https://myorg.visualstudio.com --project MyProject，它会因错误 The requested resource requires user authentication 而失败。正如预期。

现在如果我使用普通账户登录Azure CLI，然后重新运行 az boards work-item create --title 'My test item' --type Bug --organization https://myorg.visualstudio.com --project MyProject，这次命令成功。这不是我想要的，因为PAT没有对工作项进行更改的权限。

我已经尝试在执行任何 az boards 命令之前，显式登录到 az devops，并传入PAT。这给了我相同的结果——如果Azure CLI已经登出，az boards work-item create 会失败；如果Azure CLI已登录，则 az boards work-item create 会成功，而 az boards work-item show 无论我是否登录Azure CLI都能工作。

解决方案

AZ DevOps扩展始终偏好活动的 az login 会话而非 AZURE_DEVOPS_EXT_PAT，这是设计使然，无法被覆盖。

最干净的解决办法是完全绕过CLI，直接对REST API使用curl。PAT在每次调用中都是显式提供的，并且不会受到 az login 状态的影响。