When every machine identity on Azure is governed by a single, auditable control plane, ffiec auditors can see exactly who accessed what, when, and why.
In many organizations, the reality looks very different. Engineers provision service principals, managed identities, or static secret keys, copy them into CI pipelines, and grant those credentials broad roles such as Contributor or Owner. The credentials live in code repositories, are shared across teams, and rarely rotate. When a job runs, the underlying request travels straight to the Azure resource, whether it is a storage account, a SQL database, or a Kubernetes cluster, without any visibility into which automation triggered the call or whether the operation complied with policy. The result is a blind spot that makes it hard to prove to an ffiec examiner that non-human access is controlled, monitored, and reviewed.
ffiec’s guidance on non-human identities focuses on three pillars: identification, authorization, and auditability. First, every machine identity must be uniquely identifiable and linked to a business owner. Second, access must be granted on a least-privilege basis, with explicit approval for privileged actions. Third, every request and its outcome must be recorded in an audit log that can be presented to regulators. The standard does not prescribe a particular technology stack; it requires that the control point be able to enforce policy and produce evidence on every transaction.
Most teams satisfy the identification pillar by registering service principals in Azure AD, but they stop there. The authorization step is often implemented by assigning static role‑based access control (RBAC) at the subscription or resource‑group level, which leaves wide‑open attack surfaces. Even when a request is blocked by a network security group, the event is logged only in Azure Monitor, and the log does not tie the activity back to the originating service principal in a way that satisfies ffiec’s “who did what” requirement. In short, the request still reaches the target directly, with no inline enforcement, no just‑in‑time approval workflow, and no guaranteed audit trail that survives the lifetime of the resource.
hoop.dev fills that missing control plane. It sits in the data path between the machine identity and the Azure resource, acting as a Layer 7 gateway that can inspect, transform, and decide on each request before it reaches the target. Because hoop.dev is the only point that can see the full protocol payload, it can enforce ffiec‑required policies such as masking sensitive fields in responses, blocking dangerous commands, and routing high‑risk operations to a human approver. Most importantly, hoop.dev records every session, captures the identity that initiated it, and writes the evidence to an audit log that auditors can query directly.
When a CI job needs to connect to an Azure SQL Database, the workflow looks like this: the job obtains an OIDC token from Azure AD, presents it to hoop.dev, and hoop.dev validates the token, extracts the service principal’s group membership, and checks the request against a policy that enforces least‑privilege access. If the policy allows the query, hoop.dev forwards the request to the database using a credential that only the gateway knows. If the query attempts to drop a table or export large data sets, hoop.dev can pause the request, create an approval ticket, and only continue once a designated owner has approved the action. Every step, authentication, policy evaluation, approval, execution, and response, gets logged with timestamps, request IDs, and the originating service principal. The log can be exported to Azure Monitor or a SIEM for long‑term retention, providing the evidence required by ffiec auditors.
Because hoop.dev relies on standard OIDC/SAML flows, it integrates seamlessly with Azure AD, Entra ID, and any third‑party identity provider that issues JWTs. The gateway runs as a Docker container or a Kubernetes pod inside the same virtual network as the target resources, ensuring that traffic never leaves the trusted perimeter. The agent that runs on the host side holds the connection credentials (for example, a managed identity or a short‑lived service principal secret) and never exposes them to the calling process. This separation guarantees that even if a compromised build agent tries to exfiltrate credentials, it cannot because the credentials never reach the process.
From a compliance perspective, hoop.dev generates the exact evidence that ffiec expects: a per‑request audit record that includes the machine identity, the resource accessed, the action performed, any approval workflow, and the full command output (with optional masking of PII). The system also supports just‑in‑time access, meaning that service principals can be granted temporary elevation for a specific task and automatically revoked afterward, reducing the attack surface and simplifying the justification required in audit reports.
Organizations that adopt hoop.dev can therefore close the gap between Azure’s native RBAC model and the granular, auditable controls demanded by ffiec. The gateway provides a single, enforceable control surface for all non‑human traffic, turning a sprawling set of service accounts into a manageable, compliant ecosystem.
To get started, follow the getting‑started guide and explore the feature documentation on the learn site. View the open‑source repository on GitHub for the full reference implementation and community contributions.
ffiec requirements for machine identities on Azure
- Unique identification: Each service principal or managed identity must be uniquely tied to a business owner.
- Least‑privilege authorization: Access rights are granted only for the duration and scope needed for a specific job.
- Auditability: Every request and its outcome must be recorded in an audit log that can be produced on demand.
How hoop.dev satisfies those requirements
- Identity‑aware proxy: hoop.dev validates OIDC tokens and maps them to policy rules before any traffic reaches Azure.
- Just‑in‑time approvals: High‑risk commands trigger a workflow that requires human sign‑off, ensuring that privileged actions are intentional and documented.
- Session recording and masking: Every command and response is stored, with optional inline masking of sensitive fields to meet privacy obligations.
- Audit log: The gateway writes a per‑session record that includes the originating service principal, timestamps, and approval metadata, ready for ffiec review.
FAQ
What does hoop.dev record for each machine‑initiated request?
hoop.dev records the identity that presented the OIDC token, the target Azure resource, the exact command or API call, any approval steps taken, and the full response (with optional masking). This record is stored in a log that can be exported to Azure Monitor, a SIEM, or any downstream audit system.
Can hoop.dev enforce least‑privilege policies without changing existing Azure RBAC assignments?
Yes. hoop.dev evaluates policies at the gateway layer, allowing you to keep broad Azure RBAC roles while enforcing finer‑grained, per‑request controls that satisfy ffiec’s least‑privilege requirement.
Is hoop.dev compatible with existing CI/CD pipelines?
Because hoop.dev works with standard clients (psql, kubectl, az, etc.) and uses OIDC tokens that CI runners already obtain from Azure AD, integration is straightforward. The pipeline simply points to the gateway endpoint instead of the raw Azure service endpoint.
Where can I find the source code and contribute?
The project is open source under an MIT license and lives at https://github.com/hoophq/hoop.
