Skip to content
redactsure
Book a demo

Explore.

Data Report · By Chris Sowa · Published
Last updated

How Can AI Agents Process Personally Identifiable Information in Financial Services?

They can, if the model never receives the nonpublic personal information: identifiers are substituted on the rendered screen before the model reads it, real values resolve only at approved destinations, and a named person approves each account change. Check whether a design keeps the model outside the NPI boundary, as tokenization keeps card data out of PCI scope.

Customer records pass through an abstract masking boundary and a circular processing node toward a financial institution.

They can, if the model never receives the nonpublic personal information: identifiers are substituted on the rendered screen before the model reads it, real values resolve only at approved destinations, and a named person approves each account change. Check whether a design keeps the model outside the NPI boundary, as tokenization keeps card data out of PCI scope. Financial institutions already know how to shrink a compliance boundary: the payments industry replaced card numbers with tokens so most systems never hold the real value. The same move is available for an agent that reads customer account screens, and it changes the regulatory question from "is the model safe enough to hold NPI" to "does the model hold NPI at all." This page sets out which rules apply when an agent touches customer information, where on an account servicing screen that information reaches a model, how tokenization at the screen keeps the model outside the boundary, which account actions need a named person, how a compliance officer should evidence the arrangement, and which vendor claims a buyer should decline. Regulators have said their existing rules apply to generative AI; the design task is to make an agent fit them.

Key findings

  • The FTC's Safeguards Rule, 16 CFR Part 314, sets the standards for safeguarding customer information, and an agent that reads or changes customer records operates inside the program the rule requires (FTC, 2024).
  • FINRA has told members that it "intends for its rules and guidance to be technologically neutral," so existing supervision, recordkeeping and customer information obligations apply to generative AI use without a separate rulebook (FINRA, 2024).
  • The Treasury Department's December 2024 report recommends that financial firms "prioritize their review of AI use cases for compliance with existing laws and regulations before deployment," placing the compliance analysis before the pilot (U.S. Department of the Treasury, 2024).
  • Tokenization's established role in payments is scope reduction: a system that holds only a token in place of a card number is outside the boundary that applies to the real value, and the same logic applies to a model that is shown ACCT_001 rather than an account number (PCI Security Standards Council, 2011).
  • Disclosure of sensitive data through model output is a recognized failure class, so keeping the real value out of the model's input is stronger than filtering output afterward (OWASP, 2025).
  • An agent that cannot see the real account number also cannot be tricked into sending it, the argument made in research on securing AI agents against financial fraud.

Which rules govern an agent that handles customer information at a financial institution?

Four bodies of guidance apply, and none was written for agents. The Safeguards Rule at 16 CFR Part 314 requires covered institutions to maintain a program for safeguarding customer information, with risk assessment, access controls and monitoring as its components (FTC, 2024). An agent that reads a customer account screen is an element of that program whether or not anyone has written it down.

The New York State Department of Financial Services addressed AI directly in its October 2024 industry letter on cybersecurity risks arising from artificial intelligence. Among its expectations is that covered entities "should consider using authentication factors that can withstand AI-manipulated deepfakes" (NYDFS, 2024). Its logic extends to an agent inside the institution: if the agent can be deceived, the controls around it must not depend on the agent's judgment alone.

FINRA's Regulatory Notice 24-09 reminded members that the rules are technologically neutral (FINRA, 2024), so supervision of communications, books and records requirements and the protection of customer information all reach an agent that drafts, files or updates on a member's behalf. The Treasury's December 2024 report adds the sequencing: review each AI use case against existing law before deployment (U.S. Department of the Treasury, 2024). Read together, the four sources say the question is not whether an agent is permitted, but whether the institution can show that its handling of customer information satisfies obligations it already carries.

Where on an account servicing screen does nonpublic personal information reach the model?

Take a customer account record as it appears to a servicing representative. The screen shows the customer's name, date of birth, Social Security number, residential address, phone number, the account number, the current balance, recent transactions and any notes from prior contacts. A representative updating a mailing address reads perhaps six of those fields and changes one. An agent doing the same task reads the whole screen, because the screen is what it receives.

That is the moment of exposure. Everything on the page becomes part of the context the model reasons over, remembers within the session, and may reproduce in its output. Neither the Social Security number, the balance nor the transaction history is needed to change an address, yet all of them enter the model, and once there they are subject to the disclosure risks OWASP catalogs under sensitive information disclosure, where the model's output can reveal data from its input in ways the operator did not intend (OWASP, 2025).

Legacy servicing applications sharpen the problem with dense screens that do not separate the fields a task needs from those it does not, a pattern examined in research on protecting sensitive information in legacy applications. The boundary question therefore has a precise location. It is the render of the account screen, in the instant between the application producing the page and the model reading it. A control placed anywhere else is acting after the NPI has been read.

How does tokenization move the model outside the NPI boundary?

The payments industry solved an analogous problem. The PCI Security Standards Council's tokenization guidelines describe replacing a primary account number with a surrogate value so that systems holding only the token are removed from the scope of the controls that apply to the real number (PCI Security Standards Council, 2011). Scope shrinks because fewer systems hold the thing the rules protect.

On the account servicing screen, before the model reads the page, the Social Security number becomes SSN_001, the account number becomes ACCT_001, the customer's name becomes CUSTOMER_001. The tokens are consistent for the run, so the agent still recognizes the same account across screens. The agent finds the address field, enters the new address, and submits. The real account number was never in the model's context. When the submission reaches the application, the token resolves to the real value at that destination, and only there.

The regulatory consequence follows the PCI pattern. A model that never receives NPI is not a system that stores, processes or transmits NPI; it is a system that processes tokens. The Safeguards Rule program still covers the environment that performs the substitution and holds the mapping; what changes is that the model, including any third-party model, sits outside the boundary. This is the approach to protecting sensitive information without locking down entire applications: the application is unchanged, the representative's own view is unchanged, and only what the model sees is altered.

Which actions on a customer account need a named person, and which can an agent complete with tokens?

Reading and acting are different risks. The FFIEC's 2011 supplement on authentication in an internet banking environment established the expectation of layered security proportionate to the risk of a transaction, with stronger controls on higher-risk activity (FFIEC, 2011). Updating a mailing address, drafting a response to an inquiry or summarizing a transaction history can be done with tokens and no real value exposed. Moving money, changing beneficiaries or altering credentials cannot be left to an agent's judgment, because the NYDFS point about deepfake-resistant authentication applies equally to an agent manipulated through its inputs (NYDFS, 2024).

Action on the customer account record What the agent handles What a named person does
Read the account to answer a servicing question Tokens in place of SSN, account number and name Nothing; the real values are never shown to the model
Update a mailing address or phone number Tokens; enters the new value in the destination field Confirms the tokenization policy for the screen before the run
Issue a refund or fee reversal Prepares the entry with tokens Approves the submission before it is sent
Add a payee or change a beneficiary Prepares the entry with tokens Approves the record change before it lands
Change authentication credentials or verification details Not delegated Performs the action directly

The table makes the design visible. The agent's reach is defined twice: by what it can see, which is tokens, and by what it can commit, which is nothing consequential without a person. The approval is the control the FFIEC guidance would expect on the transaction, performed by a person who can see the real values the agent cannot.

How should a compliance officer evidence an agent's handling of customer information?

The Safeguards Rule's program is written and examined, so three records do the work. The first is the tokenization policy for each screen the agent reads: which fields are substituted, who confirmed the policy and when. The second is a record of what the model received, as tokens, on each screen. The third is a record of every action and who approved it. Together they let an examiner reconstruct a run.

This evidentiary design is also what the Treasury's March 2024 report on AI-specific cybersecurity risks points toward. It noted that "smaller institutions generally lack sufficient internal data and expertise to build their own anti-fraud AI models" (U.S. Department of the Treasury, 2024), and the same gap applies to bespoke controls around third-party agents. Such an institution needs the environment it adopts to produce the records for it, in a form its SIEM already ingests.

The records also address a problem that long predates agents: the proliferation of data loss prevention rules written to catch sensitive values in transit. When the model receives tokens, there is no real value in the model's traffic for a DLP rule to catch, and the rule set that must be maintained shrinks accordingly, a point developed in research on reducing the number of DLP rules needed to protect sensitive information. FINRA's technologically neutral stance means its books and records expectations apply to these logs (FINRA, 2024). The test: pick one run, ask for the three records, and check whether the Social Security number appears in what the model was shown.

What does a governed environment change?

A governed environment keeps the model outside the nonpublic personal information boundary: the agent completes servicing tasks on tokens, and real identifiers exist only at the institution's own systems when a named person approves a change. The Safeguards Rule, 16 CFR Part 314, governs the institution's program for safeguarding customer information (FTC, 2024). The question for an agent inside it is whether customer information enters the model at all.

The mechanism acts on the rendered servicing screen. Account numbers, Social Security numbers, dates of birth and balances are replaced with consistent tokens before any model reads the page, so the task runs on tokens. Real values resolve only at an approved destination, such as the core system, at the moment of an approved action. A named person confirms what is tokenized and approves payments and account changes. Every screen as tokens, every action and every approval is recorded and exported to the institution's own logging, where a compliance officer can inspect it.

The precedent is already part of financial services practice. The PCI Security Standards Council describes tokenization as scope reduction: a system holding only a token in place of a card number sits outside the boundary that applies to the real value (PCI Security Standards Council, 2011). The same logic applies to a model shown ACCT_001 rather than an account number, and it is why input substitution is stronger than filtering output after the model has read the data.

The environment does not alter the servicing application, user entitlements or the model, and it does not make an institution compliant by itself; that remains a determination about the institution's own program.

Where does RedactSure sit?

The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company. The design answers the boundary question on this page by placing the model outside it. The agent works inside a governed environment in the customer's own cloud. On every rendered account screen, substitution happens at the render layer before any model reads the page, and the same customer maps to the same tokens, such as ACCT_001 or CUSTOMER_001, for the whole run. Real values resolve only at approved destinations at the moment of an approved action, so an address update lands in the servicing application as a real address while the model has only ever handled a token. A named person confirms the tokenization policy for each screen and approves every payment, submission and record change, the arrangement RedactSure calls Supervised Delegation. Every screen as tokens, every action and every approval lands in the AI Control Record and exports to the customer's SIEM. The design is model agnostic, requires no per-application integration, and leaves user permissions unchanged.

Deployments are in pilot. A pilot on an institution's own account servicing workflow would show, for one run, which fields the model received as tokens, which actions a named person approved, and whether a Social Security number appears anywhere in the model's input. Everyone else controls where data can go. RedactSure controls what the AI can see.

Methodology and limitations

This page rests on the text of the FTC Safeguards Rule at 16 CFR Part 314, the New York State Department of Financial Services industry letter of October 16, 2024 on cybersecurity risks arising from artificial intelligence, FINRA Regulatory Notice 24-09, the U.S. Treasury Department's reports of March and December 2024 on AI in financial services, the FFIEC's 2011 supplement on authentication in an internet banking environment, the PCI Security Standards Council's 2011 tokenization guidelines, the OWASP Top 10 for LLM Applications entry on sensitive information disclosure, and published RedactSure research pages on financial fraud, legacy applications and DLP rule reduction. All sources were read as of October 16, 2026.

No hands-on testing of any product was performed for this page. Where a feature or behavior is described as not covered, the statement refers to the pages reviewed and not to the product as a whole. Regulatory guidance and vendor features change, and the page carries its date. Statements about RedactSure describe its current design, with deployments in pilot. The customer account record and account servicing screen used as the worked example describe a record type, not any institution; no customer or prospect is described, and the field list is illustrative.

Whether a given agent deployment satisfies the Safeguards Rule, NYDFS Part 500, FINRA rules or any other obligation is a determination for the institution's counsel, its examiners and its own security and compliance officers. This page describes a design pattern and the questions a buyer should ask; it does not offer a legal conclusion about any deployment.

What the record shows

The regulators have already answered the threshold question: existing rules apply to agents, and the institution must show compliance before deployment, not after. What remains is design. An agent that reads a customer account screen receives every field on it unless something intervenes at the render, and the intervention that financial services already understands is tokenization, the payments industry's method for shrinking the boundary around protected values. A model shown ACCT_001 rather than an account number is outside the NPI boundary in the same way a merchant system holding a token is outside PCI scope, and the substituting environment is where the Safeguards Rule program concentrates its controls. RedactSure's design is one implementation of that pattern. The test is to name one agent and one servicing task and ask for the record of exactly which fields the model received, as tokens or as real values, on every screen in the run.

Frequently asked questions

Does GLBA prohibit AI agents from accessing customer information?

No. The Safeguards Rule at 16 CFR Part 314 does not name any technology; it requires covered financial institutions to maintain a program for safeguarding customer information with risk assessment, access controls and monitoring. An agent is a system within that program and must be governed accordingly. The practical question is whether the institution can show what the agent accessed, what it changed and who approved the change.

What counts as nonpublic personal information on an account screen?

Nonpublic personal information covers personally identifiable financial information a customer provides to obtain a product or service, or that the institution obtains in providing it: account numbers, balances, transaction histories, Social Security numbers and the fact that a person is a customer. On a servicing screen nearly every field qualifies, and a mailing address update needs almost none of them, yet the model receives all of them unless the screen is tokenized first.

Why is tokenization compared with PCI scope reduction?

Because the mechanism and the regulatory effect are the same. PCI tokenization replaces a card number with a surrogate so that systems holding only the surrogate fall outside the controls that apply to the real number. Replacing an account number with ACCT_001 before a model reads the screen produces the same result for the model: it processes tokens, not NPI. The real value and the mapping remain inside the institution's controlled environment.

Can an agent complete a funds transfer if the data is tokenized?

It can prepare one but should not commit one. Tokenization addresses what the model sees; it does not address whether the action is correct or authorized. The FFIEC's layered security expectation and the NYDFS letter's concern with AI-manipulated authentication both point to a named person approving consequential transactions. The agent fills the form with tokens, the person reviews it with real values visible to them, and the values resolve at the destination only when the approval is given.

What should an examiner be able to see for a single agent run?

Three records: the tokenization policy for each screen, naming who confirmed it; the screens as the model received them, with tokens in place of protected fields; and every action taken with the identity of the person who approved it. From those, the examiner can confirm that the model never received a Social Security number or account number and that no consequential change occurred without a named approver.

Does a model provider's no-training commitment protect customer information?

Only partly. A commitment not to train on customer data addresses one downstream use, but the exposure occurs when NPI enters the model's context at all. The data can be reproduced in output or extracted through prompt injection. A design in which the model never receives the real values does not depend on the provider's commitments, which is why substitution before the model reads the screen is the stronger position.

Book an AI Agent Security Review →

Bring your hardest questions.

Bring one sensitive workflow and the decisions your team needs to keep in its hands.

Book a demo

About the author

Christopher Sowa
Chris SowaCo-Founder, President and Chief Commercial Officer, RedactSure

Chris Sowa is a founder of RedactSure and a former CEO of an AI company; he started it years before ChatGPT existed. He previously led AI at Accenture, served as Global VP of Strategy & Innovation at Schneider Electric, was CCO of Sovos, and spent more than a decade at Oracle, with earlier roles at SAP and IBM.

Book a demo

Book a demo

Having trouble? Open the booking page or email us.