Scopes, Approvals and Records: Designing Consent for Personal Agents in Mortgage and Banking

The Problem the Consent Layer Solves

When a borrower's agent talks to a lender, three different questions need answers, and most confusion comes from treating them as one. Which agent is this? Which customer sent it, and what did they allow? Did the customer approve this particular action? The first is identity, the second is delegation, the third is authorization of a specific act.

This post is about the second and third — the consent layer — as the Personal Agent Protocol draft 0.3 describes it, and how a mortgage lender or a bank would map its own business onto it. We quote field names from the draft where they help, with the caveat that a draft can change; the design ideas are the durable part. The personal agent readiness guide covers the rest of the stack at a higher level.

Delegation: The Customer Signs In at the Business

The protocol builds on OAuth. The business runs the authorization server; the agent is a client identified by its client_id, which is a URL where the agent's metadata and keys live. The customer grants access at the business, not to the agent.

The draft ranks three ways of doing that:

1. Direct sign-in. The agent opens the business's authorization URL in the customer's browser. The customer signs in at the business's own site and approves. The agent uses state and PKCE with the S256 method (RFC 7636), and checks that the iss returned matches the issuer it expected.
2. Device sign-in. The customer approves on a second device using a code, the flow standardized in RFC 8628. The draft asks businesses to confirm the code with the customer rather than auto-approving on a scanned link, to throttle polling with slow_down, and to keep codes short-lived.
3. Mediated sign-in. The agent collects the credentials itself. The draft treats this as transitional — something a business should plan to remove — and asks for rate limits and identical errors for an unknown account and a wrong password.

For a lender or a bank the choice is not close. Direct sign-in keeps the customer's credentials, multi-factor authentication and fraud controls exactly where they already are. It also produces the cleanest record: the customer authenticated at the institution and approved this agent.

The consent page carries much of the weight. The draft asks that it show the agent's name and the domain of its client_id, the account being connected, and the scopes in plain language, with consequential and personal-data scopes called out. The domain matters more than the name, because, as the draft puts it elsewhere, "the personal agent chooses its own name, so the domain is what the user can trust."

Scopes: Cutting the Business at Its Joints

A scope is a permission the customer can grant or withhold. The draft asks businesses to describe scopes in plain language, specifically enough for a model to match them to a task, to say when a scope is read-only, and to split scopes where that gives the customer a better choice. It also defines hints, under auth.scope_hints, for scopes whose actions are irreversible or touch personal data, so an agent can warn the customer before asking for them.

The draft does not name scopes for any industry. Here is one way to cut a mortgage loan and a bank account, illustrative rather than standard:

Mortgage	Banking	Grant
Read rates, products, eligibility	Read products and rates	At sign-in
Read loan status, milestones, conditions	Read balances and transactions	At sign-in
Upload documents against a named condition	Upload documents for a request	At sign-in, logged
Book time with a loan officer	Book an appointment	At sign-in
Authorize a credit pull	Move money between own accounts	Per action, approved
Submit an application	Pay a third party	Per action, approved
Lock or extend a rate	Set up a payment plan	Per action, approved
Request a changed circumstance	File a dispute	Per action, approved

The split is about consequence, not sensitivity alone. Reading a balance is sensitive; it is also reversible in the sense that matters. Locking a rate or sending money is not, and those belong in the bottom half.

Operations: Approval as a Data Structure

Scopes say what an agent may ask for. Operations are how the business asks the customer to approve one specific consequential act. The draft's guidance for businesses that offer operations is detailed, and it reads like a checklist for anyone who has had to defend a disputed transaction:

• A summary that stands alone. No links, no references to earlier messages. The customer should understand what they are approving from the summary as written, and the agent is told to show it as written.
• terms named after the request's own fields. If the API takes lock_period_days and rate, the terms say lock_period_days and rate, so an agent can compare what it is being asked to approve with what it asked for.
• An expires_at. At least 15 minutes, longer when the terms are stable. A rate lock offered this morning should not be acceptable tonight at this morning's price.
• Tamper evidence. The draft describes signing operation revisions so a changed operation is detectable.
• An approval record. Operation identifier, revision, client_id, account and time.

The agent side is constrained too: it should not pre-approve on the customer's behalf, should not ask for re-approval until the outcome of the first attempt is known, and should retry a failed request with the same approval rather than asking again.

Mapped onto mortgage, this answers questions lenders already struggle to answer on ordinary files. Who authorized the credit pull, and when? What did the borrower see when they locked? Did the borrower — not a loan officer, not a portal default — submit the application that started the TRID clock? Mapped onto banking, it gives a transfer or a payment plan an approval that sits on the institution's side, which is the kind of evidence that matters when a customer later says they did not authorize something.

Lifetimes and Revocation

Delegation that cannot be taken back is not consent. The draft's guidance on token lifetimes is short and opinionated:

• Access tokens last hours, not days. Long enough for a task, short enough that a leaked token is a contained problem.
• Revocation is immediate. When a customer disconnects an agent, its access tokens stop working, or the business checks authorization on every request.
• Refresh tokens are tied to the client_id. The draft suggests long refresh lifetimes, so a customer does not re-consent every week, and ties consequential work to the refresh token so that disconnecting stops it.
• The customer can see and disconnect every agent. An account settings page lists connected agents with their name, domain, scopes and last use.

That last item is the one we would build first. A borrower or account holder who can see what is connected, and turn it off, is the strongest consumer protection in the stack, and it costs very little.

Sessions, and Why They Matter to Audit

Every request in the protocol carries a session token naming the agent and a session identifier, sid. The draft says a session "is named by the client_id and sid of its Session JWTs", asks businesses to record the user and agent at a session's start and to reject a different one later in the same session, and to keep conversation records for at least 30 days.

For a regulated institution, that is the spine of an audit trail. A session record that joins the agent, the customer, the scopes granted and used, the operations proposed and approved, and the outcome can be attached to the loan file or the account, where compliance, QC and examiners will look for it. The alternative — reconstructing what an agent did from a vendor's chat transcript — is what every institution should be designing away from now. We go into the governance side of that record in governing personal-agent traffic.

Three Mistakes to Avoid

Treating the agent's word as the customer's approval. "The borrower told me to lock" is a claim. An operation the borrower approved on your side is evidence.

One scope for everything. A single account scope forces the customer to choose between letting the agent do nothing and letting it do anything. Most will choose nothing, and the ones who choose anything will be the ones you hear from later.

Letting secrets into the conversation. The draft is emphatic that tokens, private keys and authorization codes stay out of logs, telemetry, error reports, URLs, conversation messages and model context, and that sign-in during a conversation happens through an authorization event rather than a code typed into chat. Anything a model reads can end up somewhere you did not intend, a point we made at length in prompt injection defense.