A parks department limits an agentic offensive workflow so it may call only approved emulation APIs and forbids interactive shell on domain controllers. What safeguard is that?
Select an answer to reveal the explanation.
Short Explanation
Give the agent a short approved-API menu and keep domain-controller shells off the table—parks safety in one sentence. You might see human-gating, audit-logging, or isolating as useful, but they're not the approved-API menu and DC-shell block the stem describes. Scope the tools hard.
Full Explanation
Parks departments that limit agentic offensive workflows to approved emulation APIs and forbid interactive shell on domain controllers are applying tool-scoping safeguards. Allowlists define which capabilities the agent may invoke; explicit denials block high-risk actions that can destabilize identity systems. Interactive DC shell is a classic excessive capability for automation because small mistakes cascade into directory-wide outages.
The correct safeguard works by constraining the agent’s action space to purpose-built emulation interfaces that are logged, rate-limited, and designed for testing. API allowlists also make reviews tractable: auditors can enumerate permitted tools instead of guessing what a free-form shell might do.
Human-gating agentic offensive workflows to approved emulation APIs while forbidding shell on domain controllers fails because it adds an authorization gate rather than restricting the tool set itself; the scenario describes which APIs the agent may call and forbids DC shell outright, not who must sign off before it calls them.
Audit-logging agentic offensive workflows to approved emulation APIs while forbidding shell on domain controllers fails because it is a detective record of what happened, not the preventive allowlist that forbids DC shell in the first place.
Isolating agentic offensive workflows to approved emulation APIs while forbidding shell on domain controllers fails because it changes the testing environment instead of scoping the agent’s tools in the production-like context described.
Exam caveat: Tool-scoping = approved emulation APIs on, interactive DC shell off. Reject human-gating agentic offensive workflows, audit-logging agentic offensive workflows, and isolating agentic offensive workflows as the described safeguard.
Operational check: Enforce an API allowlist in the agent runtime, deny SSH/WinRM to DC groups for the automation identity, and penetration-test the agent’s tool layer to confirm it cannot escalate to forbidden shells.
Prefer to study offline? Printable PDF study book + test engine ($7.50, unofficial). These questions stay free here.