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

*October 25, 2026 · 6 min read · Ramkumar Venkataraman*

> A technical walk through the consent layer of the Personal Agent Protocol draft 0.3 — delegated sign-in, scopes and scope hints, operations with terms and expiries, approval records and token lifetimes — and how a mortgage lender or a bank would map its own consequential actions onto it: credit pulls, rate locks, application submission, transfers, payment plans and disputes.

## 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](https://personalagentprotocol.org/docs/0.3/guides) 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](/blog/guides/personal-agent-readiness) 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](https://www.rfc-editor.org/rfc/rfc7636)), 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](https://www.rfc-editor.org/rfc/rfc8628). 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](/blog/personal-agents-mortgage-point-of-sale-application-trid-clock-consent)? 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](/blog/governing-personal-agent-traffic-mortgage-model-risk-fair-lending-audit-trail).

## 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](/blog/prompt-injection-defense-banking-ai-agents-red-team).

---

_Source: [https://www.seiright.com/blog/personal-agent-protocol-mortgage-scopes-approvals-oauth-consent-design](https://www.seiright.com/blog/personal-agent-protocol-mortgage-scopes-approvals-oauth-consent-design) · Sei AI_