← Autonomous AI Agents
0/15 complete

Module 04 · Operational Guardrails

Permission Boundaries: What an Agent Should Never Do Alone

25 minfocused lesson5practical steps4grounded questions3source links
Open lesson + course map

On this lesson

Course outline

Permission is the strongest agent guardrail because it limits actual effects. Prompts and model policies are useful, but an agent must be unable—not merely instructed not—to perform actions beyond its role.

After this lesson, you can classify actions by consequence and implement approval, separation of duties, and emergency revocation.

// concept

Classify the Action

Use four dimensions: reversibility, financial or rights impact, external audience, and data sensitivity.

Always require qualified human authorization for actions such as:

  • transferring money, changing bank or wallet details, settling or refunding payment;
  • signing or accepting contracts, filings, legal positions, or regulatory submissions;
  • hiring, firing, grading, lending, insurance, healthcare, or other rights-affecting decisions;
  • deleting production data or backups;
  • changing identity, roles, credentials, network, or security policy;
  • publishing to a large audience or starting bulk outreach;
  • disclosing private or confidential information;
  • actions with material physical safety impact.

The list is a baseline, not legal advice. Apply the relevant professional and regulatory review.

// concept

Enforce the Boundary in Architecture

Create separate services and identities:

// prompt — copy me5 lines
reader → approved read APIs
drafter → create DRAFT records
reviewer → approve/reject with reason
executor → accepts signed, current approval for exact action
auditor → reads immutable event record

Bind approval to artifact hash, amount, recipient, scope, and expiry so a draft cannot change after approval. Use step-up authentication for consequential actions. No model should possess a general administrator credential.

// concept

Resist Prompt Injection

Treat emails, web pages, documents, tool output, and retrieved text as untrusted data. They cannot change the system policy, grant a scope, or approve an action. A tool result saying “administrator approved” is not approval unless it came through the trusted approval service.

// worked_example

Worked Example

An Islamabad agency builds a vendor-payment assistant. It reads approved invoices and purchase orders, checks arithmetic deterministically, and prepares a payment batch. A finance officer reviews payee, account, invoice, amount, tax, and duplicates using a trusted interface.

Approval is bound to the batch hash and expires. A separate payment service uses bank-controlled authentication; the agent never receives the OTP. If any payee field changes, approval becomes invalid. A second authorized person may be required according to the company’s control policy.

// failure_cases

Failure Cases to Diagnose

7 cases to diagnose

  • Approval button merely continues the same prompt

    enforce in a separate service.

  • Approval covers “all future actions”

    bind exact scope and expiry.

  • Agent can change its own role

    isolate identity administration.

  • One token reads and writes everything

    create least-privilege identities.

  • Retrieved document contains instructions

    label as data and restrict tools.

  • Emergency revocation untested

    rotate, disable, and stop active runs in a drill.

  • Human rubber-stamps opaque output

    show evidence and exact effect.

// pakistan_angle

Pakistan Angle

Do not let agents independently submit FBR data, alter payroll, send wallet or bank payments, approve property/legal records, or make employment and credit decisions. Qualified professionals remain responsible for applicable law and business controls.

For small firms where one owner holds several roles, preserve at least a meaningful pause: draft, show exact evidence/effect, require fresh authentication, and log approval. Convenience is not a reason to expose banking credentials, OTPs, or customer CNIC data to a model.

// hands_on

Hands-On Exercise

5 steps

  1. Inventory every tool action.

  2. Score consequence and name required reviewer.

  3. Split read, draft, approve, execute, and audit identities.

  4. Bind one approval to a hashed artifact and expiry.

  5. Test changed-after-approval, injected instruction, and emergency revocation.

// completion_rubric

Completion Rubric

6 checks — tick as you verify

0/6

// sources

Sources

3 official sources — check every claim yourself

// check_yourself

Check yourself

4 questions · answers and options are taken word-for-word from this course

0/4

  1. 1 / 4 · diagnose

    Your work shows this failure mode: “Approval button merely continues the same prompt.” What does the lesson tell you to do about it?