Who Authorized the Agent? Closing the Service-Account Attribution Gap in Agentic Finance

An auditor pulls a journal entry that moved $2.3M between two cost centers at 2:14 a.m. on a Sunday. The user field says svc_finance_automation. They ask the obvious question: who authorized this? And the room goes quiet, because nobody can answer. The entry was posted by an AI agent running under a shared service account that 14 other automations also use. There’s no thread back to a person, a request, or an approval. The agent did its job. The control failed anyway.

This is now the single most common finance audit finding involving AI, and it has a boring, structural cause. Agents are being wired into ERPs the same way batch jobs were wired in fifteen years ago: through a generic technical account with broad standing permissions. That was tolerable when the account ran a fixed nightly script. It is not tolerable when the account is now a reasoning system making context-dependent decisions on behalf of whichever analyst happened to ask.

Why the service-account pattern breaks under agents

A service account exists so software can authenticate without a human typing a password. Fine. The problem is what the account represents. A batch job represents itself: it does the same thing every night, and its identity is its behavior. An agent represents whoever invoked it, and that changes minute to minute. When the analyst in FP&A asks the agent to reclassify a batch of accruals, the action belongs to her judgment, channeled through the agent’s execution. Collapse both into svc_finance_automation and you’ve erased the only two facts that matter for control: which human’s intent triggered the work, and which non-human identity carried it out.

SOX has never cared whether a control is run by a person or a process. It cares about individual accountability: every action that affects the financial statements must trace to an accountable party with appropriate authorization. A shared service account fails that on its face. You can’t enforce segregation of duties when ten agents and three cron jobs all wear the same badge. You can’t revoke one agent’s access without breaking the others. And you can’t reconstruct intent, which is the question auditors actually ask.

Identity vendors have spent 2026 pointing out that non-human identities now outnumber humans in most enterprises, with ratios cited anywhere from 40-to-1 to 80-to-1. The finance subset of that population is small but high-blast-radius: these are the identities allowed to touch the general ledger. Governing them as a faceless pool of service accounts is how you get the 2:14 a.m. journal entry nobody can explain.

The two identities you have to keep separate

Closing the gap means logging two distinct things on every agent action, and refusing to let them blur:

• The non-human identity. The agent itself needs its own first-class identity, not a borrowed one. Distinct credentials, scoped permissions, an owner of record, a lifecycle. When the agent is retired, its access dies with it. When it misbehaves, you revoke exactly one thing.
• The human principal. The authenticated person whose session, request, or standing delegation set the work in motion. This is the attribution that satisfies the “who authorized this” question, and it’s the one shared service accounts destroy.

Security teams call this dual attribution: bind every privileged action to both the machine identity that performed it and the human identity that triggered it. The agent acts as itself but on behalf of a named person. Both halves get logged, every time, immutably. If an agent ever acts with no human in the chain (a scheduled run, an autonomous loop), that, too, has to be explicit and attributable to the policy and owner that sanctioned the autonomy, not silently folded into a generic account.

The distinction matters because the two identities answer different questions. The non-human identity answers what was allowed and what ran. The human principal answers who is accountable. An audit needs both, and a single user field can hold neither honestly.

Identity is necessary. It is not sufficient.

Here’s where I’ll concede the limit of identity work, because it’s where a lot of governance programs stop too early. Knowing who authorized an agent tells you nothing about whether the number it produced is correct. You can have flawless dual attribution on a figure that’s quietly wrong: an agent that confidently reported a margin it computed inside an LLM, hallucinated a reconciliation, or pulled a stale balance. Attribution makes the mistake traceable. It doesn’t prevent it.

So attribution is one layer of a trust stack, not the whole stack. The companion question, can you defend the number itself?, is what our work on audit trails that record decisions, not just actions is about: logging the reasoning and the inputs, not only the database write. And the question of what the agent is even allowed to do unsupervised is the subject of the four autonomy tiers framework. Identity tells you who. Decision logging tells you why. Autonomy tiers tell you how far. You need all three, which is the point of the agentic AI trust layer we’re building toward.

What this looks like in practice

A workable pattern, drawn from how identity-governance teams are actually closing these findings:

1. Give each finance agent its own identity in a central inventory, mapped to a business owner and a risk level. No shared svc_* accounts for agents. Ever.
2. Scope permissions to the task, not the platform. An agent that reads receivables to draft a collections summary does not need write access to the GL. Standing broad grants are how 2:14 a.m. happens.
3. Stamp every action with both identities (agent and human principal), plus the token scope, timestamp, and the request that triggered it. Make the log immutable.
4. Tie execution to a deterministic layer, not the model. This is the part most identity programs miss because it’s a finance problem, not a security one. When the agent needs a figure, it should retrieve it from a reconciled model that ties out to the ledger, and run any calculation through a deterministic engine, so the action you’ve carefully attributed is also an action you can defend on the merits.

That last point is the one Rexfin exists to handle. We sit between your AI and your accounting systems (QuickBooks, Xero, NetSuite, Sage, SAP, Oracle, your warehouse, or uploaded statements) and build a single reconciled financial model that ties out to the ledger. Agents retrieve figures from it and route calculations through a deterministic engine rather than computing inside the model. So when the auditor asks who authorized the entry, you have the human and the agent on record; and when they ask whether the number is right, you can trace it to source. Attribution and correctness, on the same action.

The takeaway

The service-account attribution gap isn’t an edge case you’ll patch later. It’s the load-bearing question for whether autonomous finance is allowed to exist inside a SOX-controlled environment at all. An agent your auditor can’t attribute is an agent your auditor will tell you to switch off. Two identities on every action, the machine that ran it and the human who authorized it, is the floor, not the ceiling. Build the floor first.

If you’re trying to put attributable, defensible numbers behind your finance agents, book a demo and we’ll show you the reconciled-model and deterministic-execution layer that makes it hold up.