Credentials, payments and human approval gates

Video lecture

Credentials, payments and human approval gates

15 chapters · about 8 min · full transcript

Coming soon

Chapter 1 of 15

Credentials, payments and approvals

The golden rule
Safe login patterns
Agents and money
Approval gates that work

The narrated lecture is in production

Every chapter is scripted and ready. Browse the chapters and read the full transcript now — the video will appear here when it’s published.

Chapters

Transcript of the narration, chapter by chapter.

0:00 Credentials, payments and approvals

Two things attackers want from your agent: your secrets, and your money. Passwords, one-time codes and card numbers on one side. Payments, messages and deletions on the other. In this lesson you will learn the golden rule for both, how to handle logins without the model ever seeing a password, and how to design approval gates people actually read.

0:26 The golden rule

Here's the golden rule. The model should never see a secret it doesn't need, and it should never be the final authority on an irreversible action. Everything in this lesson follows from those two sentences. Keep them in mind as you watch the rest of this lesson, because every pattern we cover, from logins to payments to approvals, is simply a practical way of applying them.

0:55 Why it matters

Why does this matter? Because the two things attackers and mistakes are most likely to cost you are secrets and money. A leaked password can open every system behind it. An unapproved payment or message can be irreversible, and embarrassing. Getting these patterns right early means you can give agents more useful work, confidently, because the worst outcomes are designed out rather than hoped away.

1:23 The hotel concierge

Here's an analogy. A good hotel concierge can book your restaurant, arrange your taxi and hold your luggage. But they don't know your bank PIN, and they don't sign your mortgage. When something needs your money or your signature, they bring it to you and wait. That's exactly the relationship you want with an agent: capable preparation, and a clear handover for anything involving secrets, money or irreversible commitments.

1:53 Simple example: office supplies

A simple example of tiers in action. Your agent is reordering office supplies. Browsing supplier sites and comparing prices: tier zero, no approval, just logging. Adding items to a cart: tier one, reversible, so a daily batch review is enough. Submitting the order: tier three, because it spends money. The agent stops, posts the cart total, the supplier domain and a screenshot to your team chat, and waits. Someone with authority taps approve, and a human places the order.

2:27 Safe login patterns

Now logins, best option first. Use an API or delegated, scoped access instead of a login wherever possible; tokens can be revoked and audited. Next best, human in the loop: the harness pauses at the login screen, a person signs in, including MFA, through a remote view, and the agent carries on. If automation truly must log in, the harness fills the fields from a secrets manager with ordinary code, after checking the domain matches exactly. The model never sees the password, and screenshots of that step are skipped or redacted.

3:07 Credential hygiene

Why the exact domain check? Because a lookalike login page is the oldest trick for harvesting credentials, and careless automation will happily type a password into it. Also, never put passwords in prompts, task descriptions, spreadsheets the agent reads, or logs. And never let the model type a password it found on a page or in a document.

3:32 Agents and money

Money next. The safe default is simple: agents prepare, humans pay. The agent researches, compares, fills the cart or drafts the purchase order, then stops at a gate showing exactly what will happen. If you do let agents pay, use virtual or single-use cards with limits and instant freeze, amount thresholds that need a human above a small figure, payment protocols built for agents that carry verifiable user authorization, and reconcile every transaction against what was approved.

4:05 Approval gates

Now approval gates. A good gate is specific: submit these six values to this exact domain, not continue question mark. It's evidence-backed, with the screenshot, the domain, the data and the agent's reasoning. It's enforced in code, so the harness physically can't proceed without an approval record. And it's risk-tiered. Reading needs no gate. Reversible writes can be batch-reviewed. External effects need per-action approval. Money and irreversible actions need an authorized person plus limits.

4:37 Worked example: procurement

Here's a Dubai example. A facilities company lets an agent compare prices on three supplier portals and fill carts for routine consumables. It logs in through harness-injected service accounts, one per portal. At checkout it stops and posts an approval request to the procurement chat with screenshots and totals. Small orders on a capped virtual card can be approved by anyone on the team, larger ones need the manager, and a human clicks place order in the remote view. The agent never sees a card number.

5:14 Designing for attention

Approval fatigue is real, so design for attention. If people get fifty approval requests a day for trivial things, they stop reading and click approve on everything, including the one that mattered. Keep gates for tier two and three actions. Batch tier one reviews into a daily summary. Make each request readable in ten seconds: what, where, which data, and why. And periodically include a deliberately wrong request in testing to see whether reviewers catch it.

5:47 Where approvals live

Where should approvals happen? Wherever your team already works. Many teams post approval cards into their chat tool, with the screenshot, the key details and approve or reject buttons that call back into the harness. Others use a small review page. Either way, record who approved, when, and exactly what they saw. That record protects the reviewer as much as the business, because it shows the decision was made on real evidence.

6:18 Three mistakes

Three common mistakes. First, approval prompts that just say continue, with no details, which trains people to click yes without thinking. Second, gating every trivial step, so reviewers drown and start rubber-stamping. Third, storing session cookies unencrypted, or sharing them across clients, which turns a convenience into a skeleton key. Fix those three, and your approvals become real decisions rather than rituals.

6:45 Try this now

Try this now. List every action in one of your agent workflows, from opening a page to submitting a form. Assign each a tier: zero for reading, one for reversible writes, two for external effects, three for money or irreversible actions. For every tier two and three action, write the exact approval message a reviewer would see: what, where, which data, why, with a screenshot. If you can't write a clear message, the action isn't ready to automate.

7:19 Recap

Recap. Keep secrets away from the model, and keep final authority with humans for anything irreversible. Prefer delegated tokens or human login, and check domains exactly. Agents prepare, humans pay. Build gates that are specific, evidence-backed, enforced in code and tiered by risk, and watch the rejection rate for signs of rubber-stamping. Your next step: sort every action in one workflow into tiers zero to three. Next module: agent-to-agent protocols and agentic commerce.

The golden rule

The model should never see a secret it does not need, and should never be the final authority on an irreversible action. Credentials, one-time codes, card numbers and bank details are exactly what injection attacks try to steal. Payments, sends and deletions are exactly what they try to trigger.

Handling credentials safely

Options, from best to acceptable:

Use an API or delegated access instead of a login. OAuth-style delegated, scoped tokens are revocable and auditable; a password in an agent's context is neither.
Human-in-the-loop login. The harness pauses at the login screen, a human authenticates (including MFA) via a remote view of the sandbox, and the agent continues in the authenticated session. The model never sees the password.
Harness-injected credentials. If automation must log in, the harness (not the model) fills the login fields from a secrets manager using deterministic code, after verifying the domain matches exactly. Screenshots taken during this step are redacted or skipped.
Session reuse with care. Pre-authenticated storage state (cookies) for a dedicated low-privilege account, scoped to one domain, rotated frequently, stored encrypted.

Never put passwords in prompts, task descriptions, spreadsheets the agent reads, or logs. Never let the model type a password it read from a page or document.

# harness_login.py: the model never sees the secret
import os
from urllib.parse import urlparse

def harness_login(page, expected_host: str):
    host = urlparse(page.url).hostname
    if host != expected_host:
        raise PermissionError(f"Refusing to enter credentials on {host}")
    page.get_by_label("Email").fill(os.environ["PORTAL_USER"])
    page.get_by_label("Password").fill(os.environ["PORTAL_PASSWORD"])
    page.get_by_role("button", name="Sign in").click()
    # MFA: pause for a human rather than automating the second factor
    page.wait_for_url(f"https://{expected_host}/dashboard*", timeout=180000)

Note the exact-host check: phishing pages that look like the real login are a classic way to harvest credentials from careless automation.

Payments and money movement

Agentic commerce is arriving (next module), but for your own agents the safe default is: agents prepare, humans pay. The agent can research options, fill a cart, draft a purchase order or pre-fill a transfer, then stop at an approval gate showing exactly what will happen. If you do allow agent payments:

Use virtual or single-use cards with per-transaction and monthly limits, restricted merchants and instant freeze.
Keep amount thresholds: below a small limit, auto-approve with logging; above it, require a human.
Use payment protocols designed for agents where available, which carry verifiable user authorization (mandates) rather than raw card numbers.
Reconcile every agent transaction against the approved request.

Designing approval gates

An approval gate is a harness state where execution pauses and a human decides. Good gates are:

Specific: "Submit this form to supplier-portal.example.ae with these 6 field values" rather than "Continue?"
Evidence-backed: show the screenshot, the target domain, the data to be sent, and the agent's reasoning.
Enforced in code: the harness cannot proceed without a signed-off approval record.
Risk-tiered: not every click needs approval, or people stop reading (approval fatigue).

Tier	Examples	Gate
0: Read	Navigate allowlisted pages, read, screenshot	None; log only
1: Reversible write	Save a draft, add to cart, fill a form without submitting	Batch review or sampling
2: External effect	Submit a form, send a message, publish, change a setting	Per-action approval
3: Money or irreversible	Pay, delete, transfer, accept legal terms	Per-action approval by an authorized person, plus limits

Hands-on: an approval gate

# approval.py
import json, time, uuid

def request_approval(store, *, action, target_domain, data_preview, screenshot_path, reason):
    req = {"id": str(uuid.uuid4()), "ts": time.time(), "action": action,
           "domain": target_domain, "data": data_preview,
           "screenshot": screenshot_path, "reason": reason, "status": "pending"}
    store.save(req)          # e.g. a DB row that a review UI or chat bot shows to the approver
    return req["id"]

def wait_for_decision(store, req_id, timeout_s=3600, poll_s=5):
    deadline = time.time() + timeout_s
    while time.time() < deadline:
        req = store.load(req_id)
        if req["status"] in ("approved", "rejected"):
            return req["status"] == "approved", req.get("approver")
        time.sleep(poll_s)
    return False, None       # timeout = rejection

Record who approved, when, and what they saw. That record is your audit trail.

Worked example: a Dubai procurement assistant

A facilities company in Dubai lets an agent compare prices across three supplier portals and fill carts for routine consumables. The agent logs in through harness-injected, per-portal service accounts. It stops at checkout and posts an approval request to the procurement team's chat channel with screenshots and totals. Orders under a small threshold on a virtual card with a monthly cap are approved by any team member; larger ones need the manager. The agent never sees card numbers because the portal stores the company card and the human clicks "Place order" in the remote view.

Pitfalls

Approval prompts that say "Continue?" with no detail.
Approvals required for every trivial step, leading to rubber-stamping.
Storing session cookies unencrypted or sharing them across clients.

How to measure success

Track approvals requested, approval time, rejection rate (a healthy non-zero rate shows people are actually reviewing), secrets exposure incidents (target zero) and spend reconciled versus approved.

Models should never see unneeded secrets or be the final authority on irreversible actions.
Prefer delegated tokens or human-in-the-loop login; if automation must log in, the harness fills credentials after an exact-domain check.
Default to 'agents prepare, humans pay'; if agents pay, use virtual cards, limits and agent payment protocols.
Approval gates must be specific, evidence-backed, code-enforced and risk-tiered to avoid approval fatigue.

Classify every action in one of your agent workflows into tiers 0 to 3 and design the approval message for each tier-2 and tier-3 action.

Enrol for free to save your progress

Reading is always free. Enrol to keep your place, take the final assessment and earn a verifiable certificate.

Credentials, payments and human approval gates