The CFO signs. The service account acts.
Every quarter a CFO signs a Section 302 certification that the company's internal controls over financial reporting are effective. Every quarter the actual posting, reconciliation, and movement of cash between the systems behind that certification is performed in overwhelming majority by non-human identities: service accounts, API keys, OAuth clients, IAM roles, certificates, and now AI agents with delegated tool access.
In most environments the human access review for those financial systems is rigorous. The non-human access review is a spreadsheet from 2022, an owner field that points to a person who left the company, and a quiet assumption that "the integration has always worked." That is the gap auditors are starting to walk into.
This article is for the controller, the SOX program lead, the internal audit director, and the CISO who jointly own ITGC. It explains why non-human identity is now a SOX problem, what a defensible NHI control environment looks like under SOX 404, and what evidence to put on the table at the next walkthrough.
Why NHIs are in scope now, not later
Three shifts have moved non-human identities from a backstage IT concern to a front-of-house SOX concern.
The financial close runs on integrations. A modern close pipeline pulls subledger data from billing, payroll, expense, and revenue systems into the GL through service accounts and API keys. Each of those credentials is the actor that posts the entry. The human approves a process. The NHI performs the transaction.
AI agents now hold tool access. Finance, FP&A, and accounting teams are deploying agents that read from the ERP, draft journal entries, reconcile accounts, and prepare flux analyses. Those agents authenticate. They sign API calls. They are non-human identities with delegated authority over financial data, whether the SOX program has named them or not.
External auditors are asking. PCAOB inspection findings on ITGC have shifted toward access management completeness, and the question "who reviewed the service accounts" is now a standard walkthrough question for in-scope systems. "We do not have an inventory" is no longer a quiet answer.
What SOX actually requires of NHIs
SOX itself does not name service accounts. It requires that internal controls over financial reporting be designed, operating, and evidenced. The IT general control areas that auditors test under SOX 404 - access management, change management, computer operations - apply to every actor that can affect financial data, human or not.
In practice, that means an NHI in scope for a financial system needs the same five things a human user needs:
- A named owner accountable for its access.
- A documented business purpose tied to a financial process.
- Least-privilege scope, reviewed periodically.
- Lifecycle controls from provisioning to termination.
- Audit logging that survives the SOX seven-year retention window.
The Section 302 certification then asks one further thing: the CFO needs to be able to say, with evidence, that those controls were effective for the quarter. Not "we have a policy." Effective, evidenced, current.
The control gaps most environments have today
When we walk a SOX-scope environment with a controller and a CISO together, the same five gaps surface in almost every engagement.
No real-time NHI inventory. Spreadsheets from a point-in-time export, scoped to one cloud, missing federated identities entirely. The auditor asks "is this complete" and the honest answer is "we believe so."
Ownership decay. The owner field points to a person who has changed roles, left the company, or never agreed to own the identity in the first place. Certification campaigns sent to that owner get rubber-stamped because the owner has no context.
No segregation of duties for non-human actors. SoD matrices are built for humans. The same matrix applied to NHIs would flag the integration account that can both create a vendor and pay a vendor, or the agent that can both post and reverse a journal entry. Most environments have never run that analysis.
Static, long-lived credentials. API keys created years ago, never rotated, often shared across multiple systems and multiple humans. The compromise blast radius is the full SOX-scope environment.
Disabled rather than deleted. Terminated NHIs are switched off but not removed. They reappear in incident timelines because "off" is a configuration, not a deletion.
Each of these is a defensible audit finding today, and each compounds when AI agents enter the picture with their own credentials and their own delegated authority.
A practical NHI control environment for SOX
The control objectives below map to the IT general control areas auditors already test. They are written so a SOX program lead can lift them into the existing control matrix without rewriting the framework.
Inventory and ownership
Maintain a real-time inventory of every non-human identity with read or write access to a SOX-scope system. Assign a named business owner to each. Record the financial process the identity supports and every downstream system it reaches. No identity without an owner. No owner without context.
Provisioning
Route every new NHI through a documented intake with requester, business owner, purpose, expiration, and approver. Default scope is read-only. Write paths require justification. One identity, one purpose, no shared credentials.
Periodic access review
Review every in-scope NHI at least quarterly. Annual reviews are no longer defensible in a modern audit. Send the certification to the named business owner, not to an IT manager. If the identity has not authenticated in 90 days, the default disposition is revoke.
Segregation of duties
Build an SoD matrix for non-human actors. Block any single NHI from holding both initiation and approval rights in the same financial process. Flag any identity that can both create a vendor and pay a vendor, or both post and reverse a journal entry. Treat AI agents with tool access as first-class SoD subjects.
Credential management
Rotate static secrets on a defined cadence, ninety days maximum. Forbid hard-coded credentials in code, config, or CI. Store every secret in a managed vault with audit logging on access. Replace long-lived API keys with short-lived federated credentials wherever the target system supports it.
Termination
Tie every NHI to the lifecycle of a human owner, a project, or a vendor relationship. When the parent terminates, the NHI terminates. Detect orphans within thirty days. Delete, do not disable.
Monitoring
Log every NHI authentication and every privileged action against a SOX-scope system. Make logs immutable for the seven-year retention window. Alert on first-time access, off-hours privileged calls, and impossible-travel-equivalent anomalies for service identities.
Third-party and AI agent exposure
Inventory every external service that holds credentials into your SOX-scope environment, including AI platforms. Require the same controls on credentials held by third parties as on credentials held internally. Map every AI agent in scope to the financial process it touches and the human accountable for its output.
The Section 302 question
Before every quarterly certification, the SOX program lead should be able to answer four questions on the non-human side of the access environment with the same confidence as on the human side.
- Is the NHI inventory complete and current for every in-scope financial system?
- Was the quarterly access review completed by the named business owners, with evidence?
- Did the SoD analysis for non-human actors run this quarter, and were exceptions remediated?
- Are there any orphaned, unrotated, or unowned identities in scope, and what is their disposition?
If the answer to any of these is uncertain, the Section 302 certification is being signed against an unknown control state. SOX does not have an exception for service accounts.
Where Avistar fits
Avistar is a non-human identity discovery and risk-scoring platform. Read-only, agentless, deployed across AWS, Azure, and on-premises Entra ID, with Google Cloud support in active development. We give the SOX program lead and the CISO one inventory of every non-human identity touching the in-scope financial environment, with owner, last-used, privilege scope, and a risk score the external auditor can read.
We do not replace the SOX control matrix. We give it ground truth. The quarterly access review goes to the right owner because the owner is current. The SoD analysis runs against a real graph of who-can-do-what. The orphan report is generated, not estimated.
The deliverable that ends the conversation
A SOX walkthrough for non-human identity should end with a single page per in-scope financial system. That page lists every NHI with access, its owner, its purpose, when it was last used, when it was last reviewed, and its disposition. It is signed by the business owner of the financial process.
When that page exists for the general ledger, the treasury platform, the AP and AR subledgers, the payroll system, the revenue system, and the close platform, the Section 302 certification is being signed against a known control state. That is the bar. Everything short of it is the gap.
Further reading
A companion ten-section ITGC checklist for non-human identities is available as a working document for SOX program leads and internal audit teams. Use it system by system, starting with the GL.