AI Security in Regulated Industries: A Pre-Deployment Checklist

Federal banking regulators just published revised model risk management guidance and explicitly left generative AI and agentic AI out of scope, promising to address them later. Banks, health systems, and defense contractors are not waiting. If your organization is one of them, the security controls that matter are not the ones in the vendor's pitch deck.

On April 17, 2026, the Office of the Comptroller of the Currency, the Federal Reserve Board, and the FDIC jointly issued OCC Bulletin 2026-13, “Model Risk Management: Revised Guidance”, replacing the 2011 supervisory guidance that has governed bank model risk for fifteen years. The revised guidance is notable for what it excludes: generative AI and agentic AI models are explicitly outside its scope, described as “novel and rapidly evolving.” The agencies say a separate request for information on banks' use of AI, including generative and agentic AI, is coming “in the near future.”

That is a candid admission from three of the most conservative regulators in financial services: the rulebook has not caught up to the deployment. It has not caught up in healthcare or the defense industrial base either. Meanwhile, copilots, coding assistants, and customer-facing chat agents are already running in production at banks, hospital systems, and CMMC-scoped contractors. The gap between what is deployed and what is governed is where the real exposure sits, and it is the gap every regulated buyer should be closing this quarter regardless of what an examiner asks for today.

The compliance gap regulators just made official

OCC Bulletin 2026-13 rescinds the 2011 interagency guidance, the 2021 BSA/AML model risk statement, and the 1997 credit scoring examination guidance, consolidating model risk expectations around governance, development, validation, monitoring, and vendor oversight. It is expected to be most relevant to institutions with more than $30 billion in total assets, though smaller institutions with concentrated model exposure are also in scope. None of it currently reaches the generative or agentic AI systems those same institutions are rolling out.

This is not a reason to wait. It is a reason to build your own governance now, using the frameworks regulators are already pointing toward. The most substantive of those is the National Institute of Standards and Technology's AI Risk Management Framework: Generative Artificial Intelligence Profile (NIST AI 600-1), published in July 2024 as a companion to the cross-sectoral AI RMF 1.0. It is voluntary, but it is the closest thing to an agreed reference point across sectors, and it organizes generative AI risk management around four functions — govern, map, measure, manage — with particular emphasis on governance structure, content provenance, pre-deployment testing, and incident disclosure. An examiner or auditor who asks how you manage AI risk today has a reasonable expectation that you can point to something resembling this structure, even without a binding rule requiring it.

The threat model vendors don't put in the pitch deck

Vendor security reviews for AI tools tend to focus on the same SOC 2 report and encryption-at-rest checklist used for any SaaS product. That misses the risks specific to how large language models actually fail. The OWASP Top 10 for LLM Applications (2025) catalogs the ones that matter most in production: prompt injection, sensitive information disclosure, LLM supply chain vulnerabilities, data and model poisoning, improper output handling, excessive agency, system prompt leakage, vector and embedding vulnerabilities, misinformation, and unbounded consumption. Prompt injection remains the top-ranked risk, and for good reason — it is the one attackers are actively operationalizing.

Joint guidance from CISA, the NSA, and the FBI on securing the data used to train and operate AI systems makes a related point: the accuracy, integrity, and trustworthiness of an AI system's output depends on the security of the data behind it across the full lifecycle — development, testing, deployment, and operation. A model is only as trustworthy as the data pipeline feeding it, and that pipeline is now part of your attack surface.

Indirect prompt injection stopped being theoretical in 2026

The clearest evidence that this threat model is not academic comes from the Cloud Security Alliance's April 2026 research note, “Indirect Prompt Injection Goes Operational.” Citing Google's own telemetry, the note reports a 32% relative increase in malicious indirect prompt injection content between November 2025 and February 2026, sampled across roughly 2–3 billion crawled pages per month. Palo Alto Networks Unit 42 separately documented 12 cases of indirect prompt injection against AI agents, cataloging 22 distinct payload-delivery techniques, with 85.2% of cases using a social-engineering frame such as a fake “security update” notice to convince the agent the instruction was legitimate.

The documented outcomes are concrete, not hypothetical: forced $5,000 PayPal.me transfers, Stripe-based subscription fraud, recursive file deletion via hidden shell commands, and API key exfiltration triggered by hidden instructions embedded in web pages, calendar invitations, log entries, and support tickets — content an AI agent is expected to read and act on as part of its normal job. The common thread is an agent that treats untrusted third-party content as an instruction because nothing in its architecture distinguishes data from commands. Swap the target from a personal PayPal account to a wire authorization queue, an EHR order set, or a CUI-scoped document repository, and the regulatory consequences change from awkward to reportable.

What actually matters for CMMC, HIPAA, and financial-services buyers

Strip away the vendor marketing and the actual due-diligence questions are consistent across verticals:

• Data flow and training use. Does the vendor train on your prompts and outputs by default, and can that be contractually disabled? For any tool touching protected health information, a business associate agreement covering the AI vendor is not optional under the HIPAA Security Rule's existing framework for safeguarding electronic PHI — a generative interface does not change that requirement.
• Data residency and CUI boundaries. For defense contractors, controlled unclassified information cannot be pasted into a public consumer LLM. It stays inside an authorized enclave — GCC High, an approved DoD Impact Level boundary, or a FedRAMP-authorized environment scoped for CUI — the same boundary discipline covered in our FedRAMP 2026 rules preview.
• Least privilege for agentic tool use. If an AI agent can send email, execute code, query a database, or move funds, it needs the same scoped, auditable service-account model you would require of a human contractor with the same access — not a standing credential with broad reach.
• Logging that a SOC can actually use. Full prompt and response logging, retained according to the applicable regulatory retention schedule (financial records, PHI, CUI), and fed into the same monitoring pipeline as every other identity and application — not a vendor-side log you can request only after an incident.
• Output treated as untrusted. Model output that triggers an action — a code commit, a database write, a customer-facing response — should pass through the same validation and approval gates you would apply to output from an unvetted script, because architecturally that is what it is.
• A human checkpoint on consequential actions. No agent should have unilateral authority to approve a wire transfer, alter a care plan, or make a CUI release decision. That checkpoint is the cheapest control on this list and the one most often skipped for the sake of a smoother demo.

What to do this quarter

None of this requires waiting for a binding rule. It requires treating AI governance as an extension of security programs regulated organizations already run:

1. Inventory shadow AI first. Most organizations discover the AI tools employees are already using — personal ChatGPT accounts, unsanctioned browser extensions, embedded copilots in productivity suites — before they discover the ones IT approved. You cannot govern what you have not found.
2. Stand up a lightweight governance structure against NIST AI 600-1. You do not need a full AI ethics board to assign an owner, define what “acceptable use” means for regulated data, and require pre-deployment testing before a new AI feature touches production data.
3. Extend existing monitoring to cover AI agent activity. If your SOC already ingests identity, endpoint, and application logs, add AI agent prompts, tool calls, and outputs to that same pipeline rather than standing up a separate, disconnected review process.
4. Apply zero trust principles to agent identities. Every agent that can take an action is an identity that needs scoped permissions, continuous verification, and the ability to be revoked instantly — the same model our zero trust engagements already apply to human and service accounts.
5. Run a tabletop for a prompt-injection or agentic-AI incident. Most incident response plans were written before agentic AI existed. Walk through what happens when an agent is manipulated into an unauthorized action, and confirm who has the authority to pull its access in minutes, not days.

The organizations that get burned by generative AI in a regulated environment will not be the ones that moved too slowly. They will be the ones that deployed capability without deploying the controls to match it, and then discovered the gap during an incident instead of during a design review. If you want a second opinion on where your AI deployments stand against these controls, our team can walk through it — reach out to start that conversation, or see how our MDR, MSSP, and SIEM buyer's guide frames the monitoring decisions AI agents now factor into.

Frequently asked questions about AI security in regulated industries

Are generative AI and agentic AI models covered by the April 2026 federal bank model risk management guidance?

No. OCC Bulletin 2026-13, issued jointly with the Federal Reserve Board and FDIC on April 17, 2026, explicitly excludes generative AI and agentic AI models from its scope, describing them as novel and rapidly evolving. The agencies have said a separate request for information addressing banks' use of AI is planned for the near future.

Does HIPAA require specific safeguards for AI tools that process protected health information?

HIPAA does not have an AI-specific rule, but the existing HIPAA Security Rule's requirements for safeguarding electronic PHI apply regardless of whether the tool involved is a generative AI system. Any AI vendor that creates, receives, maintains, or transmits PHI on a covered entity's behalf needs a business associate agreement, and the covered entity remains responsible for verifying the vendor's technical, administrative, and physical safeguards.

What is indirect prompt injection?

Indirect prompt injection is an attack where malicious instructions are hidden inside content an AI agent is expected to read as data — a web page, email, calendar invitation, log entry, or support ticket — rather than delivered directly by the user. Because many agents do not distinguish untrusted data from legitimate instructions, the hidden content can cause the agent to take unauthorized actions.

Can defense contractors put controlled unclassified information into an LLM?

Only inside an authorized boundary scoped for CUI, such as GCC High, an approved DoD Impact Level environment, or a FedRAMP-authorized environment with CUI in scope. Pasting CUI into a public consumer LLM tool is a DFARS 252.204-7012 and CMMC compliance issue, not just a general security best practice.

What does the NIST Generative AI Profile (NIST AI 600-1) actually require organizations to do?

NIST AI 600-1 is a voluntary companion to the AI Risk Management Framework, published in July 2024. It organizes generative AI risk management around four functions — govern, map, measure, and manage — with particular emphasis on governance structure, content provenance, pre-deployment testing, and incident disclosure. It does not carry the force of regulation, but it is the reference point examiners and auditors increasingly expect organizations to be working toward.

Is a SOC 2 report from an AI vendor sufficient security assurance?

No. A SOC 2 report addresses the vendor's general control environment, not model-specific risks such as prompt injection, training-data use of your inputs, or excessive agency in agentic features. Regulated buyers need a separate AI-specific risk assessment layered on top of standard third-party due diligence.

What is the single biggest AI security mistake regulated organizations make?

Granting an AI agent standing, broad-scope access to systems or data without the logging, least-privilege controls, and human checkpoint that would be required of a human employee or contractor with the same access. Excessive agency, ranked among the top risks in the OWASP Top 10 for LLM Applications, is consistently the gap attackers exploit.

Should we disable agentic AI features while our governance program matures?

For high-risk agentic features — ones that can execute code, move funds, or write to production systems — restricting or disabling autonomous action until logging, scoped permissions, and a human checkpoint are in place is a reasonable interim compensating control, not an overreaction.