Permission is capability
An agent can only cause the actions its credentials and tools allow. Reduce the blast radius before improving the prompt.
Builder pathLesson 05
Agent Safety: Permissions, Evidence, and Recovery
Design the permission boundaries, approval checkpoints, evidence trail, and recovery plan every useful agent workflow needs.
- Time
- 40 minutes
- Level
- Beginner to intermediate
- Reviewed
- August 1, 2026
Lesson outcome
You will create a safety checklist that separates read, draft, write, publish, spend, and delete permissions for one workflow.
Before you start
- A workflow or stack from lessons 02–04
- Access to the workflow's current permission settings
Mental model
Three ideas to keep
Evidence enables review
Source links, tool-call records, diffs, and test results let a human verify what changed and why.
Recovery is part of success
Backups, version history, spending limits, and kill switches define whether a mistake is a small interruption or a lasting incident.
Follow along
Complete the workflow
- 01
Inventory every action
List what the workflow can read, draft, write, publish, send, purchase, and delete. Include indirect actions through connected tools.
Expected result: There is a complete action list rather than a vague label such as full access. - 02
Assign the least privilege
Give each action one state: Always allowed, Ask first, or Blocked. Default external communication, spending, deletion, and permission changes to Ask first or Blocked.
Expected result: The workflow can complete its safe work without holding unnecessary authority. - 03
Define required evidence
For each important action, require an artifact such as a citation, diff, preview, transaction summary, or test result.
Expected result: A reviewer can inspect the proposed action before approving it. - 04
Create stop conditions
Stop on missing data, conflicting instructions, failed verification, cost limits, unusual volume, or any request outside scope.
Expected result: The agent knows when not to continue and what information to return. - 05
Rehearse recovery
Run a test where the workflow receives bad input or a tool fails. Confirm that you can stop the run, inspect the log, and restore the last known good state.
Expected result: Recovery steps work in practice and have a named owner.
Practice task
Build a permission matrix
Create a table of systems and actions for your workflow. Assign Allow, Ask, or Block, then attach an evidence requirement and recovery action to every high-impact row.
You are done when:
- No high-impact action is silently allowed by default.
- Important actions create an inspectable artifact.
- The workflow has a tested stop and recovery procedure.
Guardrails
Keep the exercise safe and reviewable
- Use separate credentials for development and production.
- Do not rely on a prompt as the only control for spending, deletion, or access changes.
- Review connected tools after team changes, role changes, and vendor updates.