They increase risk because organisations often grant broad access to keep automation working, especially when the identity stack cannot express narrow task boundaries. Once that happens, a single agent account can reach multiple systems or datasets, and any execution error or compromise can move across those boundaries much faster than a human workflow would allow.
Why autonomous agents change the identity equation
Autonomous and semi-autonomous agents are different from ordinary software because they do not just execute a fixed integration path, they make runtime decisions, invoke tools, and move across systems on a user’s behalf. That means the identity question shifts from “can this service connect?” to “what is this actor allowed to do, and under what conditions?” In financial services, that boundary matters because the same agent may touch trading, customer, risk, and reporting workflows.
When the identity stack cannot express narrow task boundaries, teams often compensate by giving the agent broader standing access than they would give a human user. That creates a mismatch between intent and authority. The agent may be legitimate, but the account behind it becomes a high-leverage execution path, especially when business pressure favours speed over granular authorisation.
For practical context, the issue is not just machine identity in the abstract. It is the combination of delegation, tool access, and privilege scope. NHIMG’s AI Agent Identity Security Buyer's Guide is useful here because it frames the control problem as selection and evaluation of identity capabilities, not just deployment of another automation layer.
Where identity risk grows in financial services
Financial institutions operate with dense control requirements, segmented systems, and high consequence workflows. An agent account that can read customer data, submit instructions, call internal APIs, or trigger operational actions has a larger blast radius than a human operator with a narrow role. If the agent is reused across environments or business functions, the same credential path can become a bridge between systems that were supposed to be separated.
That risk is amplified by lifecycle weaknesses. Agents are often provisioned quickly, reused across pilots, and left active after the original use case changes. The most common failure pattern is not a dramatic exploit at the outset, but slow privilege creep: temporary access becomes permanent, exception paths become normal, and ownership becomes unclear. NHIMG’s Top 10 NHI Issues and Ultimate Guide to NHIs, Why NHI Security Matters Now both capture why overpermissioned automation becomes a governance problem, not just an implementation detail.
In financial services, that broad access also interacts with auditability. A human reviewer can usually explain intent, but an agent may chain actions across tools in ways that are hard to reconstruct unless logging, attribution, and approval boundaries were designed in from the start. NHIMG’s AI Agent Observability, Audit and Incident Response Guide is a practical companion because it focuses on the evidence needed when agent behaviour has to be reviewed after the fact.
Why compromise or error spreads faster than with a human workflow
Once an agent account can reach multiple systems or datasets, a single bad decision can propagate quickly. A flawed prompt, poisoned input, misrouted tool call, or stolen token does not need a human to copy and paste the next step. The agent can execute the chain automatically, which shortens the time between initial misuse and downstream impact.
This is why the threat is not limited to external attackers. Internal misconfiguration, overbroad delegated authority, and accidental cross-system action all matter. In practice, the same trust path that improves automation can also amplify error, because the agent is trusted to keep going even when the context is ambiguous. For threat-oriented analysis, Agentic AI Security Guide and Threat Modelling AI Agents both help practitioners reason about tool use, trust boundaries, and failure propagation.
External guidance points in the same direction. The OWASP Agentic AI Top 10 highlights identity and privilege abuse as a first-order risk, which is exactly what becomes dangerous when an agent can act across finance operations, customer systems, or internal control planes.
Risk and Threat Considerations
In financial services, the main risk is blast-radius expansion. If one agent credential is over-scoped, compromise or misuse can expose customer data, initiate transactions, or move laterally across systems that were intended to remain separate. The operational concern is just as important as the security one, because automation makes bad actions faster to repeat and harder to intercept.
Failure mechanism: Broad standing access, reused agent credentials, and weak task scoping let a single agent account become a high-value execution path. If the agent is compromised, misconfigured, or influenced by bad input, it can traverse multiple systems before controls detect the abnormal sequence.
Impact: The result can be data exposure, unauthorised action, control bypass, or cross-environment movement, with material financial, regulatory, and client-trust consequences.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP Agentic AI Top 10 address the attack surface, NIST SP 800-53 Rev 5 sets the technical controls, and DORA and PCI DSS v4.0 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Agents often receive broad standing access, which directly matches overprivilege risk. |
| NHI-07 — Long-Lived Secrets | Agent accounts commonly rely on persistent credentials that expand blast radius. | |
| NHI-01 — Improper Offboarding | Agent identities can remain active after pilots or role changes, creating residual access risk. | |
| Recommendation — Enforce least-privilege scopes and remove standing access from agent identities. Replace long-lived agent secrets with short-lived, tightly bound credentials. Revoke unused agent identities and automate offboarding when purpose ends. | ||
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Autonomous agents can be over-scoped or misused through their runtime authority. |
| ASI02 — Tool Misuse | Agent tool chains can spread a single error across multiple systems quickly. | |
| Recommendation — Bind each agent action to explicit authorization and limit privilege by task. Constrain tool access to approved actions and validate each tool invocation. | ||
| NIST SP 800-53 Rev 5 | IA-9 — Service Identification and Authentication | Agent identities authenticate as services or workloads in machine-to-machine flows. |
| AC-6 — Least Privilege | The core issue is broad access granted to keep automation working. | |
| Recommendation — Use service-level authentication that uniquely binds each agent to its workload role. Assign only the minimum permissions required for each agent task. | ||
| DORA | ICT third-party and operational resilience obligations | Financial firms must manage operational resilience and third-party ICT exposure created by agent dependencies. |
| Recommendation — Assess agent dependencies in resilience testing and third-party risk processes. | ||
| PCI DSS v4.0 | 7 — Restrict access by business need to know | Agent access should be limited to business need, not convenience-driven broad access. |
| 8.6 — System and application accounts with interactive login | Agent or system accounts with broad interactive use create high-risk access paths. | |
| Recommendation — Limit each agent to the minimum business need required for the workflow. Harden system accounts and remove unnecessary interactive access paths. | ||
Practitioner Guidance
What to prioritise: Treat agent permissions as a design decision, not a deployment afterthought. The first question is whether the task can be expressed with narrowly bounded authority, short-lived access, and explicit approval points, rather than with a persistent broad token.
What to verify: Confirm that each agent has a named owner, a documented purpose, and a revocation path. If you cannot show who can shut the agent down, what it can reach, and how its actions are attributed, the control model is not ready for production use.
Common mistake: Teams often measure whether the automation works and ignore whether the identity model is safer than a service account they would have rejected for a human workflow. That is the wrong test. The right test is whether the agent can fail or be abused without crossing material trust boundaries.
Practitioner takeaway: In financial services, the most important control objective is not to stop agents from having access, but to keep their access narrow enough that a single mistake cannot become a multi-system incident.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 12, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org