Bounded autonomy interview questions
6 questions with model answers
- junior 1
- mid 3
- senior 2
6 bounded autonomy questions asked in AI engineer, ML engineer and applied AI engineer interviews, each with a model answer you can say out loud in a minute or two: 1 junior, 3 mid-level and 2 senior. The lesson Bounded Autonomy: Limits, Permissions and Sandboxes teaches the ideas behind them.Updated
Model answer
An application that can take damaging actions when model output is unexpected, ambiguous or manipulated. OWASP names three causes: excessive functionality, permissions and autonomy.
Scroll sideways to see the whole diagram
OWASP's LLM06:2025, Excessive Agency, names three root causes. First: tools with more functionality than the application needs.
Text version
- OWASP's LLM06:2025, Excessive Agency, names three root causes. First: tools with more functionality than the application needs.
- Second: tools that reach downstream systems with more permissions than their task requires.
- Third: high-impact actions taken without independent verification or approval.
- OWASP's point: excessive agency enables damaging actions in response to unexpected, ambiguous or manipulated outputs, whatever caused them. Limit the agency, and every cause does less harm.
Model answer
Limits on steps, cost, wall-clock time, repeated identical calls and consecutive failures, all checked by the harness. Anthropic recommends stopping conditions such as a maximum number of iterations.
When one fires, checkpoint, report what was and wasn't done, and hand over.
Model answer
Only the tools it needs, each doing only what's needed; narrow tools over open-ended ones like a shell; read-only where possible; actions run as the user; authorisation enforced downstream on every request.
A tool that can't express a harmful action can't be talked into it.
Model answer
In the harness, in the refund tool's wrapper, checking the argument before the call runs. The prompt can describe the rule so the model explains the wait, but code decides what runs.
A policy uses facts the model doesn't control, like the customer's address from the ticket system.
Model answer
Treat every tool result as untrusted input. Detection is unreliable, so block outcomes: a recipient rule stops an injected email without anyone noticing the injection.
Scroll sideways to see the whole diagram
Anything a tool reads (a ticket, a web page, a document, an email) can contain text written by someone else, including instructions.
Text version
- Anything a tool reads (a ticket, a web page, a document, an email) can contain text written by someone else, including instructions.
- Once read, that text sits in the context alongside your instructions. This is the indirect prompt injection of Module 03.
- There's no reliable way to make the model ignore it, so assume it sometimes won't.
- The defence that holds is in the harness: limits on what any action can do, checked in code.
- The policy doesn't need to detect the attack. It only needs to forbid the outcome.
Don't let tool output widen permissions, and be wary of chains that give a stranger's text a route to write tools.
Model answer
Private data, untrusted content, and a way to communicate externally, in one agent. Then injected instructions can exfiltrate data.
Willison's advice: avoid the combination; a filter catching 95% of attacks is a failing grade against an adversary who retries. Remove a leg, fix the recipients, or split the work across agents.