Written by: Jakub Pietroszek, Partnership Manager, Digital Colliers
A VentureBeat survey of 107 enterprises put a number on something a lot of us have been muttering about for months. 54% have already had an AI agent security incident. The most common root cause: agents running on borrowed human credentials.
In finance, that pattern is everywhere. Someone builds a reconciliation copilot in a weekend. It needs to read the ERP, pull bank feeds, write to a close workbook, maybe post a journal. So the builder does the fast thing. They hand it their own SSO token, or a shared service account that already has the right permissions because nobody wants to file another access ticket. The agent works. Nobody logs what it did with any granularity. And now you have a non-human process with human-level access, and no clean way to answer the question your auditor will ask next quarter: who posted this entry.
The credential-sharing anti-pattern in finance stacks
Most mid-market finance teams still run month-end close in spreadsheets, pulling numbers across systems by hand. When an AI agent lands in that environment, it inherits the shape of what came before. The controller's login already touches the GL, the consolidation tool, the tax package, and three bank portals. Point an agent at that login and you have handed a script the keys to the entire close.
The risk is not theoretical. Consider what happens when things go wrong:
- An agent loops on a bad instruction and posts 400 journal entries at 2am. The audit trail says the controller did it.
- A prompt injection through an emailed invoice tricks the AP agent into changing a vendor bank account. Same problem, same log.
- A developer leaves. Their credentials get rotated. Six agents silently break, and nobody knows which ones until close week.
Under DORA, which has been in force across the EU since 17 January 2025, financial entities have to demonstrate operational resilience and ICT risk controls that cover exactly this class of failure. "The agent used Sarah's password" is not going to be an acceptable answer.
What per-agent identity actually looks like
Per-agent identity is not exotic. It borrows directly from how we already handle service accounts, just with more discipline. The winning shape has four parts.
- Every agent gets its own principal. A service principal, a workload identity, a machine user, whatever your IdP calls it. One agent, one identity, one lifecycle. When you retire the agent, you retire the credential.
- Scopes are narrow and named after the job. The AR aging agent gets read on the AR subledger and write on a specific staging table. Nothing else. If it needs to post a journal, that is a second agent with a second identity and a second approval path.
- Every action lands in a log tied to the close checklist. Not a generic audit log nobody reads. A log that maps agent actions to close tasks: "reconcile intercompany", "post accruals", "flag AR over 90 days". The log entry says which agent, which scope, which input, which output.
- Human approval sits at the posting boundary. Agents can prepare, calculate, and stage. A named human approves anything that touches the ledger. This is the control your auditor wants to see, and it is the control that saves you when an agent misbehaves.
The cost of not doing this
Best-in-class finance teams close in under 5 days. Mid-market teams typically run 8 to 10. The whole reason people are pointing AI at close is to compress that gap. But if you get an agent security incident during quarter-end, you will lose more days than the agent ever saved you. And if the incident touches personal data or automated decisioning on customers, the regulatory exposure is real. GDPR fines reach up to €20M or 4% of global turnover. The SCHUFA ruling from the Court of Justice in December 2023 already extended that exposure to automated credit scoring. EU AI Act high-risk obligations layer on top from 2 December 2027, with fines up to €15M or 3% of turnover.
The teams that will still be shipping agents in 2027 are the ones treating identity as a design decision now, not a cleanup project later. If your first finance agent is running on a human's SSO token, the cheapest fix is to stop before the second one ships.