Many teams assume that giving an AI agent a shared service account is enough to keep risk under control. In practice, the agent can still execute any command the account permits, and no central policy can see or limit what it does. A non-human identity, issued by your OIDC provider, changes that equation. The misconception disappears once you separate the idea of a credential from the idea of an identity that the platform can evaluate.
Shared service accounts are static secrets stored in a namespace. They are convenient for scripts and for legacy tools that expect a username and password. However, they provide no link to a user, a role, or a time‑bound request. When an AI agent authenticates with such an account, the platform treats the request as a generic “service” operation. Auditors cannot tell which agent performed a query, and operators cannot enforce per‑request approval or mask sensitive fields in the response.
A non‑human identity, on the other hand, is an identity object that lives in your identity provider (OIDC or SAML). It can be tied to groups, policies, and just‑in‑time (JIT) approvals. The identity is presented as a token that the gateway can evaluate before any traffic reaches the target Kubernetes cluster. hoop.dev then enforces fine‑grained controls, records who asked for what, and applies inline data masking.
Why non‑human identity matters
Non‑human identities give you three essential capabilities:
- Policy evaluation at the moment of access, allowing JIT approval workflows.
- Full audit trails that include the identity that initiated the request, not just a shared secret.
- Dynamic masking of sensitive fields based on the caller’s group membership.
Because the token is verified by the gateway, the system can reject a request before it reaches the Kubernetes API server. The enforcement point is the data path, not the downstream resource.
Limits of shared service accounts
When an AI agent uses a shared service account, the following gaps appear:
- There is no way to tie a specific request to a specific agent without external logging.
- Inline masking cannot be applied because the gateway does not see a verifiable identity.
- Any command the account is allowed to run will be executed without a human‑in‑the‑loop approval step.
These gaps mean that the organization cannot demonstrate compliance with standards that require per‑user evidence, nor can it limit blast radius when a compromised agent starts issuing privileged commands.
How hoop.dev enforces control at the data path
hoop.dev acts as a Layer 7 gateway that sits between the AI agent and the Kubernetes control plane. The gateway verifies the non‑human identity token, checks the request against policies, and then decides whether to allow, mask, or route the request for approval. Because hoop.dev is the only point that can see both the token and the traffic, every enforcement outcome originates there.
- Session recording: hoop.dev records each request and response, preserving the identity that initiated it.
- Inline masking: Sensitive fields in API responses are redacted according to the caller’s group.
- JIT approval: Risky operations are paused and presented to an approver before they reach the cluster.
- Command blocking: Prohibited kubectl verbs are rejected outright by the gateway.
All of these controls rely on the data path provided by hoop.dev; the underlying Kubernetes cluster never sees an unchecked request.
Putting it together: when each approach suffices
If an AI workload only needs read‑only access to a namespace that contains non‑sensitive data, a well‑scoped shared service account can be acceptable. The risk is low, and the operational overhead of issuing a separate identity may not be justified.
When the workload performs any of the following, a non‑human identity combined with hoop.dev becomes necessary:
- Access to secrets, config maps, or custom resources that contain credentials.
- Execution of mutating operations such as deployments, role bindings, or network policies.
- Requirement to demonstrate per‑request audit evidence for compliance reviews.
- Need to apply dynamic masking to API responses based on the caller’s group.
In those scenarios, the shared service account alone cannot provide the required visibility or control. By pairing a non‑human identity with hoop.dev’s gateway, you gain both policy enforcement and the evidence needed for auditors.
Getting started with hoop.dev
To adopt this model, start with the getting‑started guide. The guide walks you through deploying the gateway, registering a Kubernetes connection, and configuring OIDC authentication for non‑human identities. For deeper details on policies, masking rules, and approval workflows, refer to the feature documentation.
FAQ
Can I use both a shared service account and a non‑human identity for the same agent?
Yes, but the gateway will always prefer the non‑human identity for policy evaluation. The shared account can serve as a fallback only for legacy tools that cannot present a token.
What happens if an AI agent compromises its token?
hoop.dev can revoke the token in real time, terminate the session, and trigger an alert. Because every request is recorded, you can replay the session to understand the impact.
Do I need to modify my existing Kubernetes manifests?
No. hoop.dev works as a transparent proxy; your manifests continue to point at the same API server endpoint, while the gateway intercepts traffic.
Ready to see the code? Explore the open‑source repository and start building a safer AI‑driven pipeline.
