As software begins to act, transact and make decisions on behalf of institutions, the question of “who are you?” is no longer limited to people.
Financial institutions have spent decades building identity systems around people: customers authenticate into digital banking, employees receive role-based access, administrators use privileged accounts and regulated processes establish who is allowed to approve a payment, view a record or change a model. That architecture is now being stretched by a new class of participant — software that can act with increasing autonomy.
APIs already communicate with one another at machine speed. Cloud workloads create and retire service identities continuously. Robotic-process automation executes routine tasks without direct human intervention. The next step is more consequential: AI agents that can gather information, call tools, initiate workflows and potentially instruct other systems. Once machines can act rather than merely calculate, identity becomes a control problem.
This is why the emerging contest over machine identity matters. NIST’s Zero Trust Architecture frames security around protecting resources, services and workflows rather than trusting network location. That principle becomes more important as financial institutions move from a relatively stable population of human accounts to a rapidly changing population of non-human actors.
Machine identity is becoming a financial control
A machine identity is the digital identity assigned to a non-human actor: an application, workload, API client, container, service account, bot, cryptographic process or AI agent. The identity allows systems to answer basic questions that sound simple but become difficult at scale: what is this entity, who owns it, what is it authorised to do, what credentials does it use, where is it running and when should its access expire?
In traditional enterprise security, machine identities often lived in the background. Service accounts were created to keep applications running; API keys were embedded in integrations; certificates authenticated servers; secrets were stored in configuration files. The operational objective was continuity. The strategic objective was rarely to treat every machine actor as a governed economic participant.
Financial services changes that calculation because access frequently maps to money, regulated data or irreversible actions. A non-human identity that can read a customer record is already sensitive. One that can alter payment instructions, initiate a reconciliation, change a trading parameter, open an incident ticket or instruct another agent is more than a technical credential. It is a delegated authority.
AI agents turn authentication into delegated authority
The arrival of agentic AI sharpens the issue because the software may decide which tool to call next. A conventional application follows a predefined path. An AI agent can be given a goal, interpret context and select actions dynamically. That does not mean agents are fully autonomous or inherently unsafe, but it means identity systems must account for behaviour that is less deterministic than a standard script.
The Bank for International Settlements has already tested AI agents for cash management in payment systems, examining how generative-AI agents can assist with liquidity decisions in real-time gross settlement systems. The research is experimental rather than an endorsement of autonomous deployment, but it illustrates the direction of travel: agents may eventually operate close to high-value financial infrastructure.
This creates a hierarchy problem. An institution may know the employee who launched an agent, but that is not enough. It may also need to know which agent instance acted, which model was used, which data sources were accessed, which tools were available, which approval policy applied and which downstream machine identities were invoked. A single human instruction could trigger a chain of machine-to-machine actions. Governance must therefore preserve accountability across the whole chain.
Why passwords and API keys are no longer enough
Static credentials are poorly suited to this environment. Long-lived API keys and shared service accounts are convenient because they reduce operational friction, but they also make attribution difficult and increase the damage that can follow from credential theft. The more autonomous a process becomes, the more dangerous it is to rely on credentials that are persistent, broadly permissioned or difficult to rotate.
The emerging alternative is identity that is short-lived, cryptographically verifiable, workload-specific and tied to policy. Instead of asking whether a secret matches, the system can ask whether the actor is the expected workload, running in the expected environment, at the expected time and requesting an action that its current role permits. This is the logic behind zero-trust architectures and modern workload-identity systems.
For banks, insurers, payment firms and asset managers, the practical challenge is scale. A large institution may already operate far more machine identities than human identities. Cloud-native applications create ephemeral workloads; microservices call one another; third-party platforms connect through APIs; automation bots proliferate across functions. AI agents could multiply that population again, particularly if each task, workflow or agent instance receives its own identity.
The battle is really over control planes
The phrase “machine identity” can sound like another cybersecurity niche. In reality, it points to a contest over the control plane of digital finance. Whoever governs machine identity governs which software can reach which data, use which tools and trigger which actions.
That control plane may become strategically important for several reasons. First, it creates a persistent map of machine relationships across an institution. Second, it becomes the natural enforcement point for least-privilege access. Third, it can create the audit trail needed to reconstruct autonomous workflows after an error or incident. Fourth, it can connect security policy with financial authority — for example, limiting which agents can create beneficiaries, move funds, change models or execute transactions above defined thresholds.
The regulatory direction reinforces this logic. The EU’s Digital Operational Resilience Act (DORA) requires financial entities to maintain comprehensive ICT risk-management frameworks and protect information and ICT assets against unauthorised access or use. DORA does not prescribe an “AI agent identity” architecture, but its requirements around governance, access, resilience and third-party risk make machine-level accountability increasingly relevant.
Regulation is moving closer to the identity question
AI regulation adds another layer. In Europe, the AI Act entered broad application on 2 August 2026, with certain high-risk requirements applying later. The legislation is not a machine-identity standard, but its emphasis on logging, traceability, human oversight, robustness and cybersecurity makes it harder to separate AI governance from identity governance.
The European Commission’s current AI Act implementation guidance highlights logging and traceability, human oversight, robustness and cybersecurity among the obligations applying to high-risk systems under the phased timetable. Its transparency rules also began applying in August 2026 for specified AI interactions and generated content.
At the same time, NIST’s AI Risk Management Framework and its Generative AI Profile encourage organisations to map, measure and manage AI risks across the lifecycle. Financial institutions increasingly need an identity layer that can operationalise those controls: who or what is acting, under which policy, with which permissions and with what evidence.
The risk of an identity explosion
One reason machine identity could become contentious is that the number of identities may expand faster than governance teams can manage. Human access programmes usually have natural anchors: employment records, job roles, managers, joiner-mover-leaver processes and periodic entitlement reviews. Machines do not fit this model neatly. A workload can exist for minutes. An agent may be instantiated for one task. A third-party service can create sub-services that the bank never sees directly.
This creates the possibility of “identity debt”: credentials and permissions accumulating faster than they are reviewed or removed. Orphaned service accounts, excessive privileges and stale secrets can persist because no person feels direct ownership. In an agentic environment, the problem is more serious because a stale identity may retain the power to call tools or create new actions.
A robust control model therefore needs lifecycle management, not just authentication. Each non-human identity should have an owner, a purpose, a defined permission boundary, an issuance event and an expiry or revocation process. Institutions may also need policy that distinguishes between an identity allowed to read, one allowed to recommend and one allowed to execute.
Third-party AI makes the trust chain longer
The machine-identity challenge becomes even more complex when the agent, model, cloud service, data source and execution system come from different providers. A bank might operate an internally governed agent that calls an external model, retrieves information through a third-party API and then uses an enterprise tool to execute a task. Each boundary introduces another identity decision.
The BIS Financial Stability Institute noted in March 2026 that AI-related data risks in financial services are intensified by third-party dependencies and concentration among major service providers. Machine identity is one mechanism for reducing that opacity because it can make external actors and delegated permissions more visible, but it cannot eliminate concentration or outsourcing risk.
This is also where liability becomes difficult. If an agent executes an improper action because a model produced a faulty instruction, a tool permission was too broad and an external API accepted the request, the technical event spans several entities. Strong identity evidence does not automatically decide legal responsibility, but without it the institution may struggle even to establish what happened.
What a financial-grade machine identity layer may require
There is unlikely to be one universal architecture, but several design principles are emerging. Identity should be unique enough to attribute an action to a specific workload or agent instance. Credentials should be short-lived where possible. Permissions should be narrowly scoped and context-sensitive. Sensitive actions should require step-up controls or human approval. Machine-to-machine activity should be logged in a way that supports reconstruction and audit. And ownership should remain clear even when the machine is autonomous within a defined mandate.
Financial institutions may also need to separate identity from authority more explicitly. Authentication answers whether an actor is genuine. Authorisation answers what it may do. Delegation answers who granted that authority and for what purpose. Agentic systems add a fourth question: whether the action is consistent with the agent’s mandate at that moment. That final layer is likely to require policy engines that understand task context rather than relying only on static role assignments.
Machine identity could become a competitive infrastructure market
As the problem grows, vendors from several adjacent markets are likely to compete for the control point. Identity-and-access-management providers can extend from workforce identities into non-human identities. Cybersecurity companies can approach the problem from secrets, certificates and privileged access. Cloud providers can embed workload identity into their platforms. API-security firms can govern machine-to-machine calls. AI-platform vendors can attempt to make agent identity native to orchestration layers.
For financial institutions, the strategic question will be whether to centralise this control or allow several overlapping systems. A single control plane can improve visibility, but it can also create concentration risk and dependence on a critical provider. A federated model can preserve flexibility but may produce inconsistent policy and fragmented audit trails. The right answer will vary with architecture, regulatory exposure and operational complexity.
The counterargument: do not invent a new identity category unnecessarily
There is a legitimate counterargument to the excitement around machine identity. Banks already possess mature disciplines for identity and access management, privileged access, certificates, API security, model risk and operational resilience. Much of the “new” problem can be addressed by applying those controls more consistently to non-human actors rather than creating a separate governance empire.
That caution is useful. New terminology can encourage unnecessary platforms and duplicate controls. AI agents should not automatically receive novel treatment if existing workload identity, least privilege and change-management systems can govern them. The test should be functional: does autonomous or dynamic behaviour introduce risks that current controls cannot see, attribute or constrain? If the answer is no, existing infrastructure may be enough. If the answer is yes, additional control layers become justified.
Why the issue matters beyond cybersecurity
The biggest reason machine identity will matter to finance is that it sits at the intersection of cybersecurity, operational risk, model governance and financial authority. An identity system for machines is not simply a login system for software. It is the mechanism through which an institution proves that a digital actor was legitimate, constrained and accountable when it touched a regulated process.
The BIS governance work on AI adoption emphasises that AI can amplify existing risks around data security, confidentiality, models and reputation, and that governance must adapt accordingly. As autonomous systems move from analysis toward action, identity becomes one of the practical ways to translate governance into enforceable controls.
This will influence bank architecture, vendor selection, internal audit and even product design. A bank may be comfortable letting an AI agent summarise information but not change a beneficiary. It may permit automated liquidity recommendations but require a human to release funds. Over time, as confidence and controls improve, that boundary may move. Machine identity will be one of the mechanisms that makes such graduated autonomy possible.
Conclusion
Financial services is moving toward an environment in which software will not merely support decisions; it will increasingly participate in workflows that have financial consequences. The institutions that manage this transition well will need to know more than whether an AI model is accurate. They will need to know which machine acted, under whose authority, with which permissions, using which tools and within which limits.
That is why the coming battle over machine identity is likely to be consequential. The winner will not necessarily be the vendor with the most sophisticated authentication technology. It may be the architecture that can make autonomous software legible to the institution — visible enough to govern, constrained enough to trust and accountable enough to audit.
References
1. NIST — Zero Trust Architecture (SP 800-207)
2. NIST — Artificial Intelligence Risk Management Framework (AI RMF 1.0)
3. NIST — AI RMF: Generative Artificial Intelligence Profile
4. European Union — Digital Operational Resilience Act (DORA), Regulation (EU) 2022/2554
5. European Union — Artificial Intelligence Act, Regulation (EU) 2024/1689
6. European Commission — AI Act Regulatory Framework and Implementation Timeline
8. BIS — AI Agents for Cash Management in Payment Systems (Working Papers No 1310, 2025)