What the term actually covers
A quick disambiguation first: this article is about security in the protective sense. The phrase is occasionally read as "an AI security" meaning a tradable instrument in an AI company, which is a different subject entirely and not what a financial institution deploying AI is asking about.
AI security in financial services is the practice of protecting the systems, data and actions involved when an AI system operates inside a regulated institution. In practice that means four things at once: keeping the model and its inputs from being manipulated, keeping customer information from leaking through it, constraining what the system is permitted to do, and being able to prove afterwards what it did.
Three things make it different from ordinary application security rather than a subset of it.
The system takes actions. Conventional application security protects data at rest and in transit. An agent reads records, writes to systems and triggers downstream processes, so the question is not only what it can see but what it can do, and what happens if it does the wrong thing confidently.
The inputs are untrusted by default. A document processing agent reads borrower files that arrive from outside the institution. That is a category of input no traditional system treats as executable, and an AI system can be induced to treat it that way.
The output is a disclosure surface. A model can restate, in a summary, information the person reading it should not see. Access control that governs storage but not what the system surfaces is incomplete.
The broader digital banking view of this is in AI security solutions in digital banking. This article is the definitional companion to it, focused on what is being secured and what agents specifically add.
The five layers
| Layer | What is being protected | Characteristic failure |
|---|---|---|
| Model and inference | The model, the prompt and the context assembled around it | Output manipulated by crafted input, producing a confident wrong answer rather than an error |
| Data in transit and at rest | Customer documents, extracted values, and every copy of both | Exposure through a subprocessor, a retained copy, or a training set nobody asked about |
| Integration surface | The credentials and connections into core, origination, servicing and document systems | An over-permissioned service account that works fine and grants far more than the workflow needs |
| Action authority | What the agent may do, as distinct from what it may see | An agent writing where it should only read, or acting outside the workflow it was scoped to |
| Evidence trail | The record of what ran, on what, with what result, and who reviewed it | Inability to reconstruct a specific action months later, which is when it is always asked for |
Most security review concentrates on the second row because that is what questionnaires ask about. The third and fourth rows are where the real exposure usually sits, and they are the ones a SOC 2 report will not settle on its own. The gap between what that report covers and what you still need to ask is set out in SOC 2 Type II for commercial lending AI.
What agents add to the attack surface
Instructions hidden inside documents
An agent processing a borrower's file is reading text supplied by someone outside your institution, and that text can attempt to instruct the system rather than inform it. The durable control is architectural: content is treated as data, never as instruction, and permitted actions are scoped so a successful attempt still cannot do anything consequential.
Permissions broader than the workflow
The most common real exposure and the least discussed, because nothing visibly goes wrong. An agent scoped to read a document store and write one field does not need write access across the core. Scoping limits consequence instead of trying to predict every error.
Output as an exfiltration path
A generated summary can restate information the reader is not entitled to see, particularly where an agent has access across entities or relationships. Access control has to govern what the system surfaces, not only what it stores.
The model supply chain
Which model, hosted where, under whose terms, with which subprocessors, and whether your documents train anything. This is a contract question more than a technical one, and it is answered in writing or not at all.
Permission scope as an evaluable product feature, rather than a promise, is covered in the top features of AI agents in financial services.
Which frameworks actually govern this now
Two changes in the last year reshaped the answer, and together they produce a result that surprises people.
First, the baseline moved. The FFIEC retired its Cybersecurity Assessment Tool on August 31, 2025 and removed it from its website. The FFIEC pointed institutions toward established resources including NIST Cybersecurity Framework 2.0, CISA's Cybersecurity Performance Goals, the Cyber Risk Institute Profile and the CIS Controls, without endorsing any single one. NIST CSF 2.0 has become the most widely adopted replacement among financial institutions, with the CRI Profile, a financial-sector extension of the CSF, the other common choice. So the framework your AI security sits inside is now whichever one you selected to replace the CAT, which for many institutions is a decision made recently and not yet fully worked through.
Second, and more surprising: AI security is largely not a model risk question. The revised interagency model risk guidance issued in April 2026 as SR 26-2, with parallel OCC and FDIC issuances, explicitly places generative and agentic AI outside its scope as novel and rapidly evolving, directing institutions to govern those technologies under their existing risk management practices.
Read those together and the practical position is clear. There is no AI-specific supervisory framework. AI security lands in information security and third-party risk management rather than in model risk. The obligations that bind are the ones already there:
- Your chosen cybersecurity framework, post-CAT
- The GLBA Safeguards requirements applicable to your institution type
- Regulation S-P as amended, now in force for all covered entities, including service provider oversight and breach notification timing
- The 2023 interagency guidance on third-party relationships, across the full lifecycle from diligence to termination
What that adds up to is that an examiner is unlikely to ask whether you followed an AI security standard. They are likely to ask how this system fits the framework you already committed to. The Regulation S-P vendor obligations specifically are covered in intelligent document processing tools for finance in the USA.
What to ask, and what a good answer looks like
| Question | What you are testing |
|---|---|
| Where does inference run, and which subprocessors touch our data? | Whether you can answer a third-party risk question without going back to the vendor |
| Do our documents or extracted data train any model, by default or otherwise? | Whether it is in the contract. A verbal assurance is not an answer |
| What is your contractual breach notification window to us? | Compatibility with your own notification obligations and their clocks |
| Can we see and narrow exactly what the agent may read and write? | Whether scoping is a configurable control or a description |
| How is document content prevented from acting as an instruction? | Whether the answer is architectural or a filter that will be bypassed |
| Which model version processed this item, and is that retrievable later? | Reproducibility, which is what makes an incident investigable |
| How long are logs retained, and can we export them? | Whether the evidence outlives the vendor relationship |
| What happens to our data at termination? | The question most often left until it cannot be renegotiated |
Where Uptiq fits
Uptiq's agents are scoped to individual jobs rather than granted broad authority, so what each one may read and write is a configuration you can inspect and narrow rather than a property you have to trust. Data is encrypted in transit and at rest, and customer data does not train shared models. Every extracted value carries a citation to its source page, confidence thresholds route items into an exception queue instead of proceeding silently, and overrides are retained with prior value, new value, reason and user, which is what makes an action reconstructable long after it ran. The agents operate above existing core, origination, servicing and document systems through more than 100 native integrations rather than requiring data to be migrated somewhere new. Consequential actions require human approval. The governance framing sits in AI agents for financial services.
How to assess an AI deployment
Start from the framework you already chose
If you replaced the CAT with NIST CSF 2.0 or the CRI Profile, map the AI system against it rather than inventing a separate AI assessment. Examiners will ask about consistency with your own programme, not about a standard nobody has issued.
Inventory what it touches before what it does
Which systems, which data, read or write, and under what identity. This is a short document and it answers most of the questions that follow.
Narrow the permissions until something breaks
Then widen by one step. Scoping to the workflow is the highest-value control available and it costs nothing but attention.
Settle the contract questions early
Subprocessors, training use, breach notification window, retention and termination export. These take longer than the technical review and are more likely to stop a deal, so they belong at the start.
Test the evidence, not the promise
Pick a processed item and try to reconstruct it: inputs, model version, output, who reviewed it, what changed. If that takes a support ticket, it will not be available during an incident.
Frequently asked questions
What is AI security in financial services?
It is the practice of protecting the systems, data and actions involved when an AI system operates inside a regulated institution: preventing the model and its inputs from being manipulated, keeping customer information from leaking through it, constraining what the system is permitted to do rather than only what it can see, and retaining evidence sufficient to reconstruct what happened. It spans the model, the data, the integration surface, the agent's action authority and the audit trail.
How is it different from regular cybersecurity?
Three differences. The system takes actions rather than only storing and returning data, so authority matters as much as access. Its inputs are untrusted documents from outside the institution, which no conventional system treats as potentially instructive. And its output is itself a disclosure surface, because a generated summary can restate information the reader should not see. Everything else in your security programme still applies.
Which framework applies now that the FFIEC CAT has been retired?
The FFIEC retired the Cybersecurity Assessment Tool on August 31, 2025 and pointed institutions to established resources including NIST Cybersecurity Framework 2.0, CISA's Cybersecurity Performance Goals, the Cyber Risk Institute Profile and the CIS Controls, without endorsing one. NIST CSF 2.0 has become the most widely adopted replacement, with the CRI Profile a common financial-sector choice. AI systems should be assessed within whichever framework your institution adopted rather than under a separate AI standard, since no AI-specific supervisory framework exists.
Is AI security part of model risk management?
Largely not, and this changed in 2026. The revised interagency model risk guidance issued in April 2026 as SR 26-2, with parallel OCC and FDIC issuances, places generative and agentic AI outside its scope, directing institutions to govern those technologies under existing risk management practices. In practice AI security sits with information security and third-party risk management. A traditional statistical model used in underwriting is a different matter and remains within model risk scope.
What is prompt injection, and does it matter for document processing?
It is the general problem of untrusted input being treated as instruction rather than as content. It matters directly in document processing, because the documents an agent reads come from outside your institution and can contain text aimed at the system rather than the reader. The reliable control is architectural: content is handled as data, and the agent's permitted actions are scoped narrowly enough that a successful attempt still cannot do anything consequential. Filters alone are not a sufficient answer.
What should we ask an AI vendor about security?
Where inference runs and which subprocessors touch your data; whether your data trains any model, in the contract rather than in conversation; the contractual breach notification window and whether it fits your own obligations; whether you can inspect and narrow what the agent reads and writes; how document content is prevented from acting as an instruction; whether the model version behind a given output is retrievable later; and what you receive at termination.
Regulatory and framework descriptions reflect publicly available sources as of September 2026, including the FFIEC's Cybersecurity Assessment Tool sunset statement, SR 26-2 and the parallel OCC and FDIC issuances of April 2026, the 2023 interagency guidance on third-party relationships, and the amended Regulation S-P. Frameworks, guidance and supervisory expectations change, and application depends on your charter, size and activities. Nothing here is legal, compliance, regulatory or security advice; confirm with your own legal, compliance and information security functions. Performance figures are Uptiq platform benchmarks across production deployments and are not a guarantee of results at any individual institution.
Ask us the hard security questions
Bring your third-party risk questionnaire and your framework of choice, and we will answer against them rather than around them.
