Identity Security in BFSI: Managing Human, Machine and AI-Agent Access
The traditional identity security question was relatively simple: Which employee should have access to which system? That question is no longer enough. A modern financial institution may have employees, contractors, partners, applications, APIs, cloud workloads, service accounts, automation tools and AI agents all requesting access to enterprise systems.
The identity estate is becoming larger precisely when the potential consequence of improper access is becoming greater. PwC reports that 76% of financial services organisations planned to increase cybersecurity budgets in 2026, with cloud related vulnerabilities among the threats firms felt least prepared to address. For BFSI, identity therefore needs to be treated as an architectural problem, not simply a login problem.
Human identities are only one part of the estate
Banks already understand employee access reasonably well. Employees generally have a known manager, job role, onboarding process, authentication and offboarding process. Machine identities can be much harder.
- A service account might be created for an integration and continue operating for years.
- An application may access multiple APIs.
- A workload may hold credentials to databases.
- An automated process may trigger transactions.
- And now AI agents may call tools and systems on behalf of people or other systems.
Each of these identities needs an answer to the same questions:
- Who owns it?
- What can it access?
- Why does it need that access?
- When should that access expire?
AI agents make identity more complicated
Traditional software generally executes predetermined logic. An AI agent can make more dynamic decisions. An agent may interpret a user request, retrieve information, select a tool, call an API, modify a system and trigger another workflow. The security problem therefore shifts. It is not only: Is the model secure? It is: What identity is the agent using, what systems can it access, and what actions is it authorised to perform?
The danger of inherited permissions
One tempting implementation model is to let an AI agent operate using the user's existing permissions. That can be convenient. It can also create problems. A human employee may technically have access to hundreds of records or functions but exercise judgment about when to use that access. An automated agent can operate much faster and at much greater scale.
Therefore, permission available to a user does not automatically equal permission appropriate for an autonomous agent. AI access may require narrower scopes.
Service accounts and machine identities matter too
AI agents are only the newest identity category. Many organisations already struggle with forgotten service accounts, static API keys, shared credentials, long-lived secrets and excessive permissions. Adding AI onto that environment increases the importance of cleaning up the foundation first. Otherwise, enterprises may create intelligent automation on top of weak identity architecture.
Zero Trust becomes more practical
Zero Trust is often reduced to: Never trust, always verify. The more useful enterprise interpretation is: Every access request should be explicitly authorised based on identity, context and required privilege. For BFSI, that can mean evaluating identity, authentication strength, device, workload, resource sensitivity, requested action, transaction risk and current context.
The objective is not constant friction. It is reducing implicit trust.
Least privilege needs to include AI
An AI agent handling customer-service questions should not automatically be able to change payment instructions, approve credit, modify compliance records or access unrelated customers. Even if the underlying user technically has broader access. The agent should receive the minimum authority needed for its workflow. That may involve scoped tokens, temporary credentials, action-level permissions, approval thresholds and separate identities for different agents.
Monitoring matters after authentication
Identity security does not end when access is granted. Organisations should also monitor unusual access patterns, unexpected volumes, sensitive-data retrieval, privilege changes, anomalous tool calls and repeated failed actions. This becomes especially important with autonomous systems. A legitimate identity can still behave incorrectly.
A practical identity checklist for BFSI
Before connecting automation or AI to enterprise systems, ask:
- Does every human and machine identity have a clear owner?
- Are service accounts still required?
- Are credentials short-lived where possible?
- Are permissions based on least privilege?
- Does an AI agent have its own defined identity?
- Can its permissions differ from those of the requesting employee?
- Are sensitive actions subject to stronger controls?
- Can every access and action be audited?
- Can credentials or permissions be revoked immediately?
- Are third-party identities governed to the same standard?
The takeaway
Identity is becoming one of the most important control layers in financial technology. The challenge is no longer just: Who logged in? It is increasingly: Which human, workload or AI system is asking to perform which action - and should it be allowed to do so? For BFSI organisations introducing more automation and AI, answering that question consistently may become as important as the intelligence of the AI itself.
FWC perspective: AI security starts with the systems around the model. Identity, permissions, integrations and monitoring determine what an AI system can ultimately do.
