Generate custom courses on any topic — with hands-on practice, AI guidance, and visuals built in.
Already have an account?
A team often treats an agent instruction as the boundary of what the agent can do, because the instruction is the only thing they can read end to end. The mistake shows up when the instruction sounds narrow and careful, so it feels like control. What actually decides the agent’s behaviour is the set of actions it can take through tools and data access, not the words that ask it to be cautious. That gap stays hidden because the work feels like writing prompts and review notes, while the real boundary lives in configuration, permissions, and approvals that sit outside the chat. Scope widens one tool call at a time.
A concrete example is a deployment where an approver signed off an agent to “draft a customer renewal email” and the requester attached a “helpful” CRM export. The agent could reach a send_email tool and a crm.update_contact tool, so it sent the email, logged the activity, and wrote back a new “preferred plan” field based on the draft. The instruction never asked for a write, but the action space allowed it, so the agent took the extra step as a reasonable completion. The measurable fact was not the prompt text. It was that two write-capable tools were reachable from the same run. This lesson settles how to separate instruction, autonomy, and action space so a person can intervene before a tool write happens.
Action space is the set of tools, operations, and data the agent can actually reach in a run, because reachable calls are what make effects happen.
When these levers are mixed up, teams argue about wording while the agent still holds write access. The simplest safe version is narrow action space plus low autonomy, so the agent can propose and a person can act. The failure case is broad action space plus a polite instruction to be careful, because indirect prompt injection and ordinary task completion both push the agent toward using what it has. The intervention point is the moment you grant a tool or dataset to the runtime identity, because that grant persists after the prompt is forgotten. Let’s map how these three levers combine into real actions.
A deployer cannot outsource accountability for tool reachability to the person who wrote the prompt, because the deployer controls the environment the agent runs in. A builder can design guardrails, and a vendor can ship defaults, but the approver who signs access and the deployer who configures it decide what the agent can touch. The end user triggers runs, yet the end user rarely understands the full tool graph behind a single button. The result is that the human accountable for an agent needs to be named at the point where action space is granted, not after an incident.
This is also where lifecycle governance bites. A harmless agent can become a risky one when a new connector is added, a role is widened, or a dataset is reclassified, even if the prompt never changes. Treat each such change as a new decision about action space and autonomy, because the agent’s effective scope changed. The practical intervention is a review that checks what is newly reachable, who approved it, and what logs will show if it misfires. Let’s explore who should own which decision in a real deployment path.