When a contract developer leaves a project, the CI pipeline that still runs under a non-human identity often retains the same API token it used during development. The same token is then reused by a nightly job that calls Claude Skills to generate release notes. Because the token was never rotated, a compromised CI runner can invoke the Claude integration with the full privileges of the original human engineer. The result is a silent data exfiltration channel that bypasses any human review.
Non-human identity is the practice of assigning a distinct, machine‑focused credential to an automated process, rather than reusing a human’s personal token. In the context of Claude Skills, a non-human identity should represent a specific job, a defined scope, and an auditable lifecycle. Without that discipline, every automated request looks like a regular user action, making it impossible to enforce least‑privilege, to record what the AI actually did, or to mask sensitive output before it reaches downstream systems.
Understanding non-human identity for Claude Skills
A non-human identity is typically backed by an OIDC service account or a federated SAML assertion that a CI system can exchange for a short‑lived token. The token carries only the permissions required to invoke the specific Claude skill, such as generate‑release‑notes or summarize‑logs. By binding the credential to a single purpose, you gain three immediate benefits: the ability to revoke the identity without affecting other pipelines, a clear audit trail that separates human from machine activity, and a natural place to apply data‑masking rules on the skill’s responses.
Common pitfalls when integrating AI agents
- Static, shared secrets. Storing a long‑lived API key in a repository and reusing it across multiple jobs creates a single point of failure.
- Over‑scoped permissions. Granting the token full access to all Claude skills means a compromised job can issue any request, even those that should be restricted to privileged engineers.
- Missing audit context. When a machine uses a human credential, logs cannot distinguish whether a command came from a person or an automated process.
- No response sanitization. Sensitive data returned by Claude (e.g., internal identifiers) can be forwarded to downstream services without redaction.
Each of these mistakes survives the initial identity setup and only becomes visible after a breach or compliance audit. The root cause is that the enforcement point, where the request is examined, lies outside the data path that actually carries the Claude traffic.
Architectural pattern with hoop.dev
hoop.dev provides the required data‑path control. It sits between the identity provider that issues the non-human token and the Claude skill endpoint. Because hoop.dev proxies the wire‑level protocol, it can inspect every request and response before they reach the Claude service.
When a CI job presents its OIDC‑derived token, hoop.dev validates the token, extracts the group or role information, and then decides whether the request matches the allowed skill scope. If the request is within policy, hoop.dev forwards it; otherwise it blocks the command. For every successful interaction, hoop.dev records the full session, applies inline masking to any fields marked as sensitive, and records the activity together with the originating non-human identity.
How hoop.dev enforces policy for Claude Skills
hoop.dev enforces three core outcomes that directly address the pitfalls listed earlier:
- Just‑in‑time access. The gateway checks the token against the skill’s allowed list at request time, ensuring that a CI job can only call the skill it was provisioned for.
- Inline data masking. Any response containing fields identified as sensitive (for example, internal ticket numbers) is redacted before it leaves the gateway, preventing downstream leakage.
- Full session audit. hoop.dev records each request and response, linking the activity to the non-human identity that originated it. This audit trail is available for replay during incident investigations or compliance reviews.
Because these controls live in the data path, removing hoop.dev would instantly eliminate the masking, the JIT check, and the audit record, even though the OIDC identity setup remains unchanged. That demonstrates that hoop.dev is the sole source of the enforcement outcomes.
Getting started with non-human identity and Claude Skills
Begin by defining a service account in your identity provider that represents the specific CI job. Configure the account with a minimal set of claims that map to the Claude skill you intend to use. Deploy hoop.dev using the quick‑start Docker Compose file, which automatically provisions the OIDC verification layer and the masking engine. Register the Claude skill as a connection in hoop.dev, attaching the service account’s credential to the connection definition. From this point forward, any request that presents the service account’s token will be mediated by hoop.dev, gaining the JIT, masking, and audit guarantees described above.
For detailed steps on deploying the gateway, see the getting‑started guide. The broader feature set, including how to configure masking rules and approval workflows, is documented in the learn section. The open‑source repository contains the full implementation and example configurations.
Explore the open‑source repository on GitHub to dive deeper into the code and contribute improvements.
FAQ
- Can I reuse a human token for a CI job? While technically possible, doing so defeats the purpose of non-human identity. Using a dedicated service account ensures that policies can be scoped, audited, and revoked without impacting human users.
- What happens if a token is compromised? hoop.dev will reject any request that does not match the allowed skill scope. You can also rotate the service account’s secret in the identity provider; hoop.dev will pick up the new credential on the next connection.
- Do I need to modify my existing Claude client code? No. hoop.dev works at the protocol layer, so standard Claude client libraries continue to function unchanged; they simply point to the hoop.dev endpoint instead of the direct Claude service URL.
