Agent authority and tool actions
An agent can turn a generated suggestion into an external action. Follow the complete path: instruction → model output → tool request → authorisation → execution → observed effect. Each arrow can introduce a different failure. STABLE
Three boundaries to keep separate
Section titled “Three boundaries to keep separate”| Boundary | Example control | Residual question |
|---|---|---|
| Access | Only approved records and tenants may be read | Is the retrieved content trustworthy and relevant? |
| Output and reliance | Recommendations require review before use | Can the reviewer detect an omission or fabricated claim? |
| Action | Payments require authorised identity, limits, and approval | Did the approved tool execute the intended transaction? |
Read-only access limits writes to the source system. A generated recommendation can still change a human decision. A user interface showing an approval button does not establish that approval is mandatory on every executable path. STABLE
OWASP’s agentic guidance extends attention to systems that plan and act across workflows. The curriculum uses that distinction to examine delegated authority, tool access, and multi-agent handoffs. GROUNDED · OWASP Source checked September 30, 2026.
Fictional case: the invoice agent
Section titled “Fictional case: the invoice agent”An agent reads an invoice containing instructions to replace the supplier’s bank account. Its service account can edit the supplier record and release a payment. A good answer identifies the untrusted instruction source, the excessive authority, the separate data-change and payment approvals, and the final bank-side effect. STABLE
Ask for concrete tests:
- Does content from a document acquire authority to change the task?
- Can the agent call the payment API directly, use another credential, or delegate to a peer?
- Is approval bound to the exact account, amount, recipient, and action being executed?
- Can a retry duplicate an already completed action?
- Does denial produce evidence, and does the downstream system confirm that no payment occurred?
These are test questions, not claims that a particular Glacis deployment supplies every control. STABLE
The effect matters
Section titled “The effect matters”“The policy engine returned deny” establishes a decision at that engine. “The payment did not occur” needs observation at the payment boundary. A signed allow record also does not establish successful execution, accurate output, or a harmless result. STABLE
Field drill
Section titled “Field drill”An agent’s model request passes through a governed proxy, but its database tool connects directly. State the evidence boundary in one sentence. A strong answer explicitly leaves database effects unverified.
→ Controls, evidence, and blind spots
Drill this page →21 bank questions stand behind what you just read. Check it while it’s warm.