How to Apply Non-Human Identities to Copilot

When an AI‑driven assistant like Copilot runs unattended, relying on a static password leaves no audit trail and can let a bot exfiltrate source code, spin up expensive cloud resources, or trigger data‑destruction without any human ever seeing the request. Using a non-human identity, an OIDC‑issued service token, limits the bot to a tightly scoped set of permissions and makes each action attributable.

Non‑human identity solves the first part of that problem by giving a service account, OIDC token, or SAML‑asserted identity to the automation instead of a shared static password. The token can be tightly scoped to the exact actions the bot needs, and it can be rotated automatically by the identity provider. In theory this reduces the blast radius of a compromised secret and provides a clear audit trail of which service performed which operation.

In practice, however, putting a non‑human identity on the wire does not close the loop. The bot still connects directly to the target system, be it a database, a Kubernetes cluster, or an SSH host, without any gate that can inspect the traffic. There is no place to enforce command‑level policies, mask sensitive fields that appear in responses, or require a human to approve risky actions. The connection remains a black box to security teams, and the logs that are produced live on the target, not in a tamper‑evident store.

Applying non‑human identity to Copilot

The first step is to provision a service identity that represents the Copilot instance. This is done in the identity provider (Okta, Azure AD, Google Workspace, etc.) by creating an application registration that issues short‑lived OIDC tokens. The registration should include group memberships or attribute‑based policies that limit the token to the specific resources Copilot needs, read‑only access to a code repository, write access to a staging database, or the ability to invoke a limited set of Kubernetes commands.

Those tokens are then presented by Copilot when it initiates a connection. The token proves who the caller is, and the gateway can use the token’s claims to decide whether the request is allowed to proceed. This setup satisfies the authentication and identity‑scoping part of the problem, but it still leaves the enforcement gap open.

Why a gateway is required

Only a data‑path component that sits between the Copilot process and the target can observe and control the actual traffic. That component must be able to:

• Record every command and response for later replay.
• Mask fields such as passwords, API keys, or personally identifiable information that appear in query results.
• Block commands that match a deny list or that exceed a risk threshold.
• Pause execution and route the request to a human approver when the operation is classified as high‑risk.

Without this layer, the non‑human identity provides only authentication, not authorization or audit.

hoop.dev as the enforcement layer

hoop.dev fulfills the gateway role described above. It is deployed as a Layer 7 proxy that terminates the client connection, validates the OIDC token, and then forwards the request to the target resource. Because hoop.dev sits in the data path, it can apply policy checks on every request before it reaches the backend.

hoop.dev records each session, preserving a complete replayable log that security teams can query during investigations. It masks sensitive data in real time, ensuring that logs never contain raw secrets. It blocks dangerous commands proactively, preventing destructive actions before they happen. When a request exceeds predefined risk criteria, hoop.dev routes it to an approval workflow, allowing a human to intervene before the operation is executed.

All of these enforcement outcomes exist only because hoop.dev is positioned between the identity provider and the target system. If the gateway were removed, the non‑human identity would still authenticate, but none of the recording, masking, blocking, or approval capabilities would be present.

Putting it together for Copilot

Start with the service identity configuration in your IdP. Assign the minimal set of scopes that Copilot requires. Next, deploy hoop.dev in the same network segment as the resources Copilot will access. Register each target (PostgreSQL, Kubernetes, SSH, etc.) in hoop.dev’s connection catalog, attaching the appropriate credentials that the gateway will use on behalf of the bot. Finally, define policies that reflect your risk appetite: which commands are allowed, which fields must be masked, and which operations need human sign‑off.

When Copilot runs, it presents its OIDC token to hoop.dev. hoop.dev validates the token, checks the request against the policy set, masks any sensitive data in the response, records the interaction, and either forwards the request or pauses it for approval. The result is a secure, auditable, and policy‑driven automation pipeline.

Next steps

For a step‑by‑step walkthrough of provisioning a non‑human identity and connecting it through the gateway, see the getting started guide. The learn section provides deeper coverage of policy language, masking rules, and approval workflows.

FAQ

Do I still need to rotate the service token?

Yes. The identity provider should issue short‑lived tokens, and hoop.dev will reject expired tokens automatically.

Can I use the same gateway for multiple bots?

Absolutely. hoop.dev isolates each session by token, so policies can be applied per‑identity, allowing you to manage many non‑human actors from a single deployment.

How does hoop.dev handle compliance reporting?

hoop.dev generates evidence for audit programs by storing session logs, approval records, and masking actions in a tamper‑evident store that can be queried for SOC 2 or other compliance reviews.

Explore the source code and contribute on GitHub