The long-lived key on a service account is the credential nobody owns and everybody uses. It was issued once for a integration that shipped years ago, its scope was never tightened, and it now opens a database that holds regulated data. When an FFIEC examination reaches your non-human identities, that key is where the conversation gets uncomfortable, because the institution cannot say cleanly who controls it, what it is allowed to reach, or what it actually did.
Governing non-human identities end to end is the FFIEC problem here, and it is a governance problem, not a tooling gap you patch with one more log. Service accounts, CI runners, and agents now act against regulated systems continuously, and the examiner holds them to the same access discipline as a privileged employee. This post frames that discipline around the export an examiner reviews.
What FFIEC expects for machine access
FFIEC IT guidance does not exempt accounts that lack a human behind them. The access management expectations apply to every identity that can reach a system: unique identification, authorization limited to function, and activity logging sufficient to reconstruct what happened. For a machine identity that resolves to a concrete set of records an examiner can ask for:
- An inventory of non-human identities and who is accountable for each.
- The scope each one carries, and evidence that it is reviewed rather than set once and forgotten.
- An activity record for each identity, independent of the process that holds the credential.
That set is the export. The institution either produces it on demand or spends the exam reconstructing it.
Why the export comes back in pieces
The records that should fill it live in different systems. Identity sits in the directory, scope in scattered IAM policy, activity in per-system logs, and masking nowhere. A machine identity slips through the seams between them. The directory knows the human who created the account, not the process making the call. The database logs the connection as the service account, indistinguishable from any other use of that credential. Each layer does its job, but no single layer can show governance of that identity end to end, so the export becomes a manual reconstruction every cycle.
Make the connection the unit of governance
The fix is to treat the connection to the resource as the place where governance is enforced, so end-to-end means one path rather than four loosely joined systems. Put an identity-aware proxy between the non-human identity and the infrastructure, and let it carry identity, scope, and recording together. hoop.dev is built to that shape. It is an open-source Layer 7 access gateway that proxies connections to infrastructure such as databases, Kubernetes, and internal services, and it applies the same access discipline to a machine identity that FFIEC expects for a human one.
On that path, every machine identity authenticates as a named principal, access is scoped just-in-time to the task, and each session is recorded at the command level where the identity cannot rewrite it. The export stops being a reconstruction and becomes a filter against one record. Read how hoop.dev records each connection, and to try it, route a service account through hoop.dev.
Take a nightly batch job that posts entries to a financial system and needs write access to one schema. Instead of a broad standing credential, it connects through hoop.dev under its own identity, scoped to that schema for the length of the run, with every statement recorded. When the examiner asks what that job did last quarter and on whose authority, the answer is a query on one activity stream, not a hunt across machines. The same record covers the identity, its scope, and its activity.
What the examiner sees
The difference is coherence. One source shows the identity inventory, the scope, and the activity record for every non-human access, end to end. hoop.dev does not hold an FFIEC certification, because FFIEC guidance is something an institution aligns to rather than a badge a tool carries. It generates the evidence for FFIEC, continuously and per identity, so governing machines end to end stops being a quarterly scramble and becomes a property of how access works. The model is open for inspection at hoop.dev.
FAQ
Do FFIEC access expectations really apply to service accounts and agents?
Yes. The guidance governs access to information systems regardless of whether a person or a process performs it, so a service account, CI runner, or agent that reaches a regulated system falls under the same identification, authorization, and logging expectations as an employee.
Does adding hoop.dev introduce a new service provider the exam must cover?
No. hoop.dev is self-hosted, so it runs inside your own infrastructure and never stores your data on a hoop.dev-operated service. It governs and records machine access in place and generates the evidence for FFIEC your program uses, without becoming a separate system the examination has to assess on its own.
hoop.dev is open source, so you can inspect exactly how machine access is governed and recorded at the hoop.dev repository on GitHub.
