Turn a Bank Policy PDF Into a 'Bring Your Own Agent' Readiness Brief

The task

You work in finance or treasury at a bank, fintech, or a corporate that holds large deposits. Your institution has an existing customer data-sharing or third-party authentication policy, and leadership wants to know whether that policy is already compatible with the Personal Agent Protocol — a collaborative effort to standardize agent-business interactions, with 42 design partners including Bank of America, Wells Fargo, Visa, and Mastercard. This workflow turns a dense policy document into a structured readiness brief you can hand to legal, product, or your CFO.

Before AI

Normally you'd read the policy end-to-end, cross-reference it against the Poppy spec, build a comparison grid in a doc, and write up findings. For a 20-30 page policy, that's a half-day of careful reading plus another couple of hours drafting. Most of the time is spent re-reading the same sections to make sure you didn't miss a scope definition or revocation clause.

The workflow

The idea: paste your institution's policy text in, then run three prompts in order. Each one builds on the previous output.

Step 1 — Extract the authentication and data-sharing posture

Paste the full policy text (or the relevant sections) in with this prompt. The model pulls out only the clauses that matter for an agent-authorization review.

You are a finance operations analyst preparing a readiness brief for the Personal Agent Protocol (PAP, "Poppy") — the framework from Sierra and Meta that lets a customer's personal AI agent sign in to a company on the customer's behalf, with scoped permissions the company defines (e.g., poppy:read, poppy:write) and user-controlled revocation.

Below is the full text of an internal bank or fintech policy document covering customer authentication, third-party access, and data sharing.

Your task: extract ONLY the clauses relevant to a bring-your-own-agent review. Produce a structured list with these fields for each extracted clause:

- Clause ID or section reference (use the heading or paragraph number if present)
- Verbatim quote (max 2 sentences)
- Topic tag — one of: {authentication, scope/permission, consent, revocation, logging/audit, liability, third-party API, data minimization, other}
- Plain-English restatement (one line)

Skip anything about branch operations, marketing, or physical security. If a topic is not addressed anywhere in the policy, note it at the end under "Gaps — not addressed."

Policy text follows below the line.
---

MERIDIAN TRUST BANK — Customer Digital Access & Third-Party Authentication Policy
Document ID: MTB-POL-2024-07 | Effective: March 1, 2024 | Owner: Chief Information Security Office

Section 3.1 — Customer Authentication
All customer-facing digital channels require multi-factor authentication (MFA) using a password plus one of: SMS one-time code, authenticator app TOTP, or FIDO2 passkey. Session tokens expire after 15 minutes of inactivity and a maximum lifetime of 8 hours.

Section 3.2 — Third-Party Application Access
Third parties may access customer account data only through the Bank's published Open Banking API, governed by OAuth 2.0 with PKCE. Available scopes are: accounts.read, transactions.read, balances.read, and payments.initiate. Write scopes require customer re-authentication at the time of each payment initiation.

Section 3.3 — Credential Sharing
Customers are prohibited from sharing login credentials with any third party, including aggregators, financial advisors, or automated software. Violations may result in account suspension per Section 7.

Section 4 — Consent and Disclosure
Before granting a third party access, the customer must view a consent screen listing (a) the requesting party's legal name, (b) the specific data scopes requested, (c) the duration of access (max 180 days), and (d) a link to revoke access. Consent is logged with timestamp, IP, and device fingerprint.

Section 5 — Revocation
Customers may revoke third-party access at any time via the Security Center in online banking or mobile app. Revocation takes effect within 60 seconds across all channels. The Bank may unilaterally revoke access upon detection of anomalous activity.

Section 6 — Audit and Logging
All third-party API calls are logged with: caller client_id, scope, endpoint, response code, and latency. Logs are retained for 7 years. Quarterly reviews are conducted by the Internal Audit team.

Section 7 — Liability
The Bank is not liable for losses resulting from customer-authorized third-party access, except where the Bank failed to honor a valid revocation. Fraud claims under Reg E remain governed by Section 9.

Section 8 — Automated Agents and Scripts
Access via headless browsers, screen-scraping bots, or automated scripts that impersonate a human user is prohibited and will be blocked by the Bank's bot-mitigation systems. Legitimate automated access must use the Open Banking API under Section 3.2.

Step 2 — Map each clause to the Poppy spec

Now compare what you extracted against the actual PAP requirements. The model produces a readiness grid.

Using the extracted clauses from the previous step, build a readiness grid that maps each PAP capability to the policy's current posture.

Use these PAP capability rows (based on the Poppy draft spec at personalagentprotocol.org/docs/spec):

1. Agent discovery via /.well-known/poppy.json
2. Sign-in flow on the Company's own page (not credential sharing to the agent)
3. Scope definition — standard scopes (poppy:read, poppy:write) and any custom scopes
4. Durable sign-in with user- and company-side revocation
5. Audit logging that distinguishes agent-initiated calls from human-initiated calls
6. Liability allocation when an agent acts on the user's behalf
7. Data minimization — returning only data within the granted scope

For each row produce:
- Status: READY / PARTIAL / GAP / CONFLICT
- Supporting clause(s) from Step 1 (by section reference)
- One-sentence rationale
- If PARTIAL or GAP: the smallest policy change that would move it to READY
- If CONFLICT: the specific clause language that would need to be amended or carved out

Output as a markdown table followed by a short "Conflicts to escalate" list.

Step 3 — Draft the executive brief

Turn the grid into something a CFO, General Counsel, or Head of Digital will actually read.

Draft a one-page readiness brief for the executive sponsor based on the grid from Step 2. Structure:

**Headline (1 sentence)** — overall readiness: Ready / Mostly ready, pending X / Material gaps / Not ready.

**What PAP is (3 sentences max)** — written for a reader who has heard the phrase "bring your own AI agent" but hasn't read the spec. Mention that participating institutions include Bank of America, BBVA, Synchrony, and Wells Fargo.

**Where we stand** — 3-5 bullets summarizing READY and PARTIAL rows.

**Gaps and conflicts** — numbered list of the GAP/CONFLICT rows, each with the recommended policy edit and an owner suggestion (CISO, Legal, Product, Audit).

**Decisions requested** — 2-3 crisp questions for the sponsor (e.g., "Do we want to offer poppy:write at launch or read-only?").

**Rough effort estimate** — small/medium/large for policy amendment, and separately for engineering (publish poppy.json, add scope mapping, extend audit log fields).

Keep it under 450 words. No hedging language ("it may be possible to consider"). Write like you've already done the analysis — because you have.

Gotchas

• The spec is a moving target. Poppy is draft 0.2 as of this writing — companies MAY define their own scopes, such as addresses, and describe each one in auth.custom_scopes, and both scope names and discovery format may shift. Re-run Step 2 against the current spec before publishing the brief externally.
• Policy ≠ implementation. A policy that permits scoped OAuth access doesn't mean your bot-mitigation layer won't block a legitimate agent. Flag this to engineering separately — the brief should note it as an open item, not pretend it's solved.
• "Prohibits automated scripts" clauses are the usual conflict. Many policies (like Section 8 in the sample) ban scripted access wholesale. PAP needs a carve-out for agents authenticated through the sanctioned flow — don't let the model paper this over.
• Model will hallucinate section numbers if you give it a messy paste. If your source is a scanned PDF, OCR it cleanly first and keep heading numbers intact, or Step 1's clause references will be wrong.
• Don't paste a real policy into a consumer chat tool. Use your enterprise instance with retention disabled, or redact institution names first.

Time saved

A manual read-and-grid of a 20-page policy against a draft protocol spec runs 4-6 hours for someone familiar with both documents, longer if they're not. This workflow compresses the reading and mapping into ~15 minutes of model time plus 30-45 minutes of human review and editing. The savings come from the model doing the clause extraction and the capability-by-capability comparison in one pass — the parts that are mechanical but unforgiving. The judgment calls (what counts as a CONFLICT vs. a PARTIAL, how to word the executive asks) still belong to you.

What we got when we ran it

We executed every prompt above, in order, against the sample input (model: claude-sonnet-4-6). Outputs below are real and unedited apart from length truncation.

Step 1 output

# Meridian Trust Bank — PAP Readiness Clause Extraction Policy Reference: MTB-POL-2024-07 | Effective March 1, 2024 Prepared for: Personal Agent Protocol (PAP / "Poppy") Bring-Your-Own-Agent Review --- ## Extracted Clauses --- ### Clause 1 | Field | Content | |---|---| | Clause ID | Section 3.1 — Customer Authentication | | Verbatim Quote | "All customer-facing digital channels require multi-factor authentication (MFA) using a password plus one of: SMS one-time code, authenticator app TOTP, or FIDO2 passkey. Session tokens expire after 15 minutes of inactivity and a maximum lifetime of 8 hours." | | Topic Tag | authentication | | Plain-English Restatement | Any agent acting on a customer's behalf must still clear MFA at sign-in, and the resulting session will time out after 15 minutes idle or 8 hours absolute — Poppy's session management must accommodate both limits. | --- ### Clause 2 | Field | Content | |---|---| | Clause ID | Section 3.2 — Third-Party Application Access | | Verbatim Quote | "Third parties may access customer account data only through the Bank's published Open Banking API, governed by OAuth 2.0 with PKCE. Available scopes are: accounts.read, transactions.read, balances.read, and payments.initiate." | | Topic Tag | third-party API | | Plain-English Restatement | Poppy must integrate via the bank's OAuth 2.0 + PKCE Open Banking API; no other channel (screen-scraping, headless browser, etc.) is permitted, and only the four listed scopes are available. | --- ### Clause 3 | Field | Content | |---|---| | **Clause

…output truncated at 250 words.

Step 2 output

# Meridian Trust Bank — PAP Capability Readiness Grid Policy Reference: MTB-POL-2024-07 | Based on Step 1 Extraction Prepared for: Personal Agent Protocol (PAP / "Poppy") Integration Review --- ## Readiness Grid | # | PAP Capability | Status | Supporting Clause(s) | Rationale | Remediation (if applicable) | |---|---|---|---|---|---| | 1 | Agent discovery via `/.well-known/poppy.json` | GAP | (none — gap identified in Step 1) | The policy has no provision for publishing or consuming a PAP discovery document; the bank's integration surface is defined solely by its OAuth 2.0 Open Banking API with no mechanism to advertise agent-specific metadata, supported scopes, or endpoint capability to an incoming Poppy client. | Add a subsection to §3.2 (or a new §3.5) requiring the bank to publish and maintain a /.well-known/poppy.json discovery document listing supported PAP scopes, auth endpoints, revocation URL, and agent registration requirements. | | 2 | Sign-in flow on the Company's own page (not credential sharing to the agent) | READY | §3.1, §3.2, §3.3, §8 | The policy mandates OAuth 2.0 + PKCE through the bank's own API (§3.2), explicitly prohibits credential sharing with any automated software (§3.3), and blocks any headless or scraping alternative (§8) — this architecture cleanly matches PAP's requirement that the sign-in page is rendered and controlled by the company, never by the agent. | (no change needed) | | 3 | Scope definition — standard scopes (`poppy:read`, `poppy:write`) and any custom scopes | PARTIAL | §3.2, §4; *scope/permission gap from Step

…output truncated at 250 words.

Step 3 output

# PAP ("Poppy") Integration — Executive Readiness Brief Meridian Trust Bank | MTB-POL-2024-07 | Prepared: June 2025 --- HEADLINE Mostly ready, pending three policy amendments and one legal resolution on agent liability before any pilot launch. --- WHAT PAP IS The Personal Agent Protocol lets a customer's personal AI agent — running on their phone, laptop, or a cloud service — sign in to a bank on their behalf using scoped, revocable permissions the bank controls. The customer authorizes exactly what the agent can see and do; they can cut off access instantly. Bank of America, BBVA, Synchrony, and Wells Fargo are among the institutions already participating. --- WHERE WE STAND - Sign-in architecture is clean. Our OAuth 2.0 + PKCE flow, MFA requirement, and credential-sharing prohibition already match PAP's model exactly — no engineering change needed here. - Consent and revocation are largely in place. The 180-day grant window, our Security Center revocation (effective in 60 seconds), and bank-initiated revocation all satisfy PAP's durable sign-in requirement. - Audit logging has the right bones. We log every API call with client_id, scope, and endpoint today; a single schema field addition closes the gap. - Scope structure is reusable. Our four existing OAuth scopes map cleanly to PAP's poppy:read / poppy:write vocabulary with a translation addendum — no new infrastructure required. --- GAPS AND CONFLICTS — ACTION REQUIRED 1. GAP — Agent discovery (`/.well-known/poppy.json`). Add a new §3.5 requiring the bank to publish and maintain the PAP discovery document. **Owner: Product

…output truncated at 250 words.

---

This content is for informational purposes only and is not financial, investment, or accounting advice. Verify outputs against authoritative sources before use.