How should financial institutions govern AI use without weakening identity and data protection controls?

Why This Matters for Security Teams

For financial institutions, AI risk is not limited to model accuracy or user experience. The real exposure comes when copilots, chat tools, or internal agents touch customer data, payment data, credentials, or regulated records without the same identity and data controls applied to core banking systems. Governance has to cover access, retention, logging, human approval, and the possibility that a model may reproduce sensitive information. Current guidance from NIST Cybersecurity Framework 2.0 and NHIMG’s Ultimate Guide to NHIs both point to the same operational reality: AI should be governed as an identity-rich workload, not as a standalone innovation layer.

That matters because AI tools often inherit broad access through service accounts, shared API keys, or vendor integrations, then make it hard to prove who accessed what, when, and for which purpose. NHIMG research shows that 97% of NHIs carry excessive privileges, while 79% of organisations have experienced secrets leaks, which is exactly the kind of control failure that becomes more dangerous when AI can act at machine speed. In practice, many security teams encounter AI-related identity abuse only after data has already been queried, copied, or exposed, rather than through intentional design.

How It Works in Practice

The safest pattern is to govern AI use through the same control stack used for high-risk non-human identities: distinct workload identity, least privilege, short-lived credentials, and policy checks at request time. For institutions that are experimenting with agentic workflows, static role-based access is usually too blunt. An AI agent may need to retrieve a record, summarize it, create a case, and call a downstream tool, all in one session. Each step should be authorised separately rather than assumed because the agent has an approved role.

That is why a context-aware model is emerging. The decision should consider the requesting workload, the task, the data class, the business justification, and the destination system. Where possible, issue ephemeral credentials per task, and revoke them immediately after completion. Use workload identity, not shared secrets, so that the system proves what the AI service is, not just what token it happens to hold. This aligns with approaches such as NIST SP 800-63 Digital Identity Guidelines for assurance and with NHIMG lifecycle guidance for managing NHIs.

• Separate training, inference, and administration environments.
• Restrict prompts and retrieval layers to approved data classes.
• Log every model access to sensitive data with identity, purpose, and timestamp.
• Block AI tools from exporting secrets, tokens, or regulated data outside approved boundaries.
• Review third-party integrations as if they were privileged service accounts.

For financial firms, this also means testing whether the AI layer can be abused through prompt injection, data exfiltration, or over-broad connectors. The control objective is not to prevent all AI use, but to make every access decision explicit, attributable, and revocable. These controls tend to break down when legacy banking platforms expose broad shared service accounts because the AI workload can inherit access that no human reviewer can easily trace.

Common Variations and Edge Cases

Tighter AI governance often increases delivery friction, so institutions have to balance speed against evidentiary control and privacy obligations. That tradeoff is real, especially when business teams want rapid deployment of chatbots, document assistants, or analyst copilots. Best practice is evolving, but there is no universal standard for this yet: some firms begin with data-loss prevention and allowlists, while others require full policy-as-code enforcement before any production access.

Edge cases usually appear where AI touches regulated or high-sensitivity workflows. Customer service copilots may need redaction before retrieval. Fraud teams may need access to telemetry but not raw secrets. Developer assistants should be blocked from production credentials entirely. When the AI is embedded in a vendor platform, the institution still needs to verify identity boundaries, session scope, retention settings, and auditability. NHIMG’s State of Secrets in AppSec is a useful reminder that fragmented secrets management and delayed remediation create avoidable exposure, especially when AI workflows are added on top.

The practical rule is simple: if a human could not justify direct access to the data, an AI should not inherit it by default. Where that rule is ignored, financial institutions usually discover the control gap through an incident review, not through a planned governance test.

Related resources from NHI Mgmt Group

• How should financial institutions use trusted third-party TIN data without weakening CIP controls?
• How should security teams use AI in identity governance without weakening controls?
• How should security teams use AI for adversarial data loss prevention without weakening governance controls?
• What breaks when identity verification data is reused without strong consent and governance controls?