An HCP Terraform agent pool runs inside a restricted network segment that can reach payment systems. Any workspace in the organization can currently select the pool in its settings. How should access be limited?
Select an answer to reveal the explanation.
Short Explanation
An agent sitting next to the payment systems is a door into that network, so you decide exactly who gets to use it. Scope the pool to the workspaces or projects that need it, then go check who's already plugged in. Here's the trap: scoping doesn't kick out workspaces that are already using the pool.
Full Explanation
Workspaces assigned to an agent pool run their plans and applies on agents in that pool, which means their code executes with the network reach of the agents. Scoping an agent pool restricts which workspaces, projects or Stacks may select it, and the pool then no longer appears in other workspaces' lists. HashiCorp notes that scoping does not remove the pool from workspaces that are actively using it; those must be switched to another execution mode or pool in their own settings. The complete fix is therefore to scope the pool and then audit and reassign any out-of-scope workspaces. Revoking an agent token disconnects the agents using it; it does not control which workspaces can choose the pool, and the next registered agent would serve everyone again. There is no sensitive marking for workspaces; sensitivity applies to variables and only hides values. Relying on scoping alone misses the documented gap for existing assignments. Exam caveat: combine scoping with team permissions, because anyone who can edit an in-scope workspace's configuration can still run code on the agents. Operational check: list workspaces using the pool, confirm only payment workspaces remain, and verify the pool is absent from another workspace's execution settings.