Many assume that the Claude Agent SDK can only authenticate using human‑centric credentials like passwords or interactive logins. In reality, the SDK can work with non-human identity, which means a service account or machine principal issued by an identity provider.
Teams that skip this option often embed a shared user token inside the agent’s configuration, or they grant the agent a broad IAM role that covers many workloads. The result is an over‑privileged AI that can read or modify data it never needs, and every action it takes is indistinguishable from a human operator. Auditors cannot tell whether a query came from a person or an autonomous process, and any accidental data leak leaves no clear trail.
This unsanitized state is common because the Claude Agent SDK talks directly to the target service, whether a database, a Kubernetes API, or an internal HTTP endpoint. The SDK presents the token it received from the identity provider, and the target accepts it without any additional checks. The connection bypasses any enforcement layer, so there is no inline data masking, no command‑level approval, and no session recording. The setup decides who may start a request, but it provides no guardrails once the request reaches the resource.
Why a dedicated non-human identity matters
Non-human identity solves two problems at once. First, it lets you assign the minimum set of permissions required for the Claude agent’s specific task, satisfying the principle of least privilege. Second, it creates a stable, auditable subject that can be referenced in policy decisions. When the agent is granted a service account that only allows read‑only access to a particular database schema, any attempt to write will be rejected by the identity system before it even reaches the database.
However, using a service account alone does not give you visibility into what the agent actually does. The request still travels straight to the backend, and the backend records only the fact that a service account made a connection. It cannot capture the exact SQL statements, redact personally identifiable information, or require a human to approve risky commands.
Introducing hoop.dev as the data‑path enforcement point
hoop.dev provides the missing layer that turns a bare non-human identity into a fully governed access channel. It sits in the Layer 7 data path between the Claude Agent SDK and the target service. When the agent presents its OIDC token, hoop.dev validates the token, extracts the service‑account claims, and then applies policy before forwarding the request.
Because hoop.dev is the gateway, it can enforce every required outcome:
- hoop.dev records each session, creating a replayable audit log that ties every command back to the non-human identity.
- hoop.dev masks sensitive fields in responses, ensuring that downstream logs or dashboards never expose credit‑card numbers or social security numbers.
- hoop.dev blocks commands that fall outside the approved scope, such as DDL statements when the service account is meant only for SELECT queries.
- hoop.dev routes high‑risk operations to a human approver, adding a just‑in‑time approval step before the command reaches the database.
All of these controls happen because the gateway is the only place where traffic can be inspected and altered. The identity setup alone cannot provide them.