Device aware MCP access controls for Codex Enterprise to prevent agents from picking up privileged human Azure credentials.

Codex Feature Requests
1

ChatGPT Enterprise/Codex needs device-aware MCP policy, not just user/group policy.

The risk is simple: engineers often have highly privileged Azure ADM accounts already authenticated on their workstations. If Codex or ChatGPT runs a local Azure MCP there, the agent can end up using the human’s privileged Azure credential. That destroys segregation between human administration and agentic execution.

We need to support this pattern:

  • Work laptop: ChatGPT/Codex allowed, Azure MCP blocked.

  • Approved bastion/sandbox: Azure MCP allowed, using only a dedicated least-privileged bot or managed identity.

  • Same human user on both devices.

Today, if MCP access is controlled only by user/group, enterprises are forced to either block Azure MCP for that engineer everywhere, or allow it on machines where privileged ADM credentials exist.

The ask: allow MCP servers and MCP actions to be whitelisted/blacklisted based on managed device or device posture, ideally with the ability to require a specific execution identity and prevent inheritance of local human Azure CLI credentials.

2

For your no-inheritance requirement, should fail-closed behavior be an explicit acceptance criterion? On an approved bastion, making the dedicated agent identity unavailable must cause the action to fail, even with a privileged human Azure CLI session present.

3

No, on the bastion machine, the cli accounts and mcp connection can be logged with a least privileged account.

Read only access with JIT/PIM access to production via rbacs.

Auth needs to happen harder than in the harness, hence the bastion.

Harness can do that it wants, it can’t break the permissions easily, if the CLI is not logged in with a account that is over privileged.