Phase 7: AI Agents & Tool-Using Systems · 95 min · LangGraph interrupts · OpenAI Agents SDK guardrails · OWASP LLM Top 10
The Problem
An AI job application agent drafts outreach emails. Then a student asks it to “apply to all good matches.” The agent uses a browser tool, edits a cover letter, uploads a resume, and submits an application with a hallucinated salary requirement.
The bug is not only the hallucination. The real bug is that the product allowed an irreversible external action without approval.
Agents become risky when they can:
- Send messages.
- Spend money.
- Modify databases.
- Delete files.
- Submit forms.
- Execute code.
- Access private documents.
- Call internal APIs.
The more real the tool, the more real the permission model must be.
The Concept
Autonomy Is a Spectrum, Not a Switch
The biggest mistake in agent design is treating autonomy as binary — either the agent can do something or it can't. In reality, autonomy is a spectrum with five levels, and the right level depends on the irreversibility of the action:
Read-only actions (search docs, fetch data, list files) are safe to allow automatically. They don't change anything, so even if the model makes a bad decision, there's no harm. Log them for auditability but don't block them.
Draft actions (write an email, compose a response, generate code) produce content that a human will review before it's used. The action itself is safe — the output is a draft, not a final action. Allow automatically but make clear the output is not yet "live."
Reversible writes (save a note, update a draft, edit a temporary file) change state but can be undone. These are generally safe to allow with logging, as long as the undo path is clear and the user knows what changed.
Irreversible external actions (send an email, submit a form, make a payment, post publicly) cannot be undone. Once the email is sent, it's sent. These must require explicit human approval before execution. The approval gate should show the user exactly what will happen, what data will be sent, and allow them to approve, reject, or edit.
Dangerous execution (run shell commands, execute generated code, modify production databases) can cause harm beyond the immediate action — data loss, security breaches, infrastructure damage. These require sandboxing (restrict what the action can access) in addition to approval.
A tool permission system answers four questions:
- Who is requesting the action?
- What tool is being called?
- What data will the tool access or modify?
- Does this action require approval, sandboxing, or denial?
Use capability levels:
| Level | Action type | Example | Default policy |
|---|
| Read-only | Fetch or inspect information | Search course docs | Allow with logging |
| Draft | Produce proposed output | Draft email | Allow, but do not send |
| Reversible write | Update a draft or internal note | Save application note | Allow with audit trail |
| Irreversible external action | Submit form, send email, pay invoice | Apply to job | Require approval |
| Dangerous execution | Run shell, browser automation, database mutation | Execute generated code | Sandbox and restrict |
Human-in-the-loop is not a decorative approve button. It is a workflow checkpoint with state, diff, reason, policy, and audit log.
Unlock the full lesson
You've read the first 2 sections. The rest of this lesson covers Build It, Use It, Sandboxing, Ship It, Evaluation, Common Mistakes, Common Pitfalls, Exercises, Key Terms, Interview Framing — plus a hands-on lab, quiz, and project artifact.
Create a free account to unlock Phase 0 and Phase 1 of every course — no credit card.