Glean and Prisma add agent identities with controls that depend on the credential

Two releases separate agents from human operators

Prisma’s new coding-agent credentials require approval for direct production writes by default, but that policy does not cover deployments triggered through GitHub Actions. The company documented this distinction when it introduced agent enrollment on October 2, 2026. Approval rules govern requests authenticated with the enrolled credential; workflows use separate authentication. Dedicated identities therefore provide a specific control point, whose reach developers need to understand.

Glean’s October 1, 2026, release, version 559, made Agent Identity generally available and available by default, according to its release notes. Administrators manage service credentials and Knowledge Profiles, while builders attach credentials to agents and configure dedicated Slack and Teams apps. The release followed a public beta announcement on July 15, 2026. Both releases address attribution and access control, but the research establishes documented capabilities rather than independently tested effectiveness.

Attribution and revocation work at different layers

Glean’s model spans connected applications through credentials scoped by administrators, including Slack bots, Jira accounts, and GitHub Apps. According to its announcement, external activity such as comments and pull requests can appear under an agent’s account. Administrators can rotate or revoke credentials for individual systems or across systems. The resulting permissions depend on the connected account, integration, and Glean’s controls.

Prisma gives agents a distinct identity within its REST API. Its changelog says agents previously inherited the developer’s command-line interface (CLI) access and appeared as that developer in audit records. Enrollment supports project and database creation, repository connections, and deployment configuration; the enrollment guide says requests record both the agent and its human sponsor. Pausing or revoking the agent preserves the human’s access, according to Prisma. The distinction is practical: Glean coordinates credentials across applications, while Prisma applies policy to requests authenticated with its enrolled agent credential.

Glean’s integrations have different identity controls

Glean’s Cursor guide shows why teams need to inspect each integration’s configuration. Glean injects the API key into outbound requests without exposing the raw key to the agent runtime, while repository access follows the Cursor GitHub App’s permissions. The guide recommends a service-account key on Cursor Enterprise and also permits a user API key. With a user key, Cursor attributes runs to its owner, and access ends if that person leaves the team. Pull requests still come from the Cursor GitHub App, so the run owner and pull-request author differ. Cursor keys have no read-only mode; Glean’s credential audience controls who can attach the credential.

For GitLab, service-account memberships, role, and token scopes determine access, according to Glean’s integration guide. Glean stores the token encrypted, injects it only for the configured host, and requires approval for write requests. The guide asks administrators to make a test change and confirm both the approval prompt and service-account attribution in GitLab. It also says Glean instructs the agent to stay within a configured top-level group. That instruction does not establish a hard authorization boundary, making the guide’s separate recommendation to restrict account memberships consequential.

Prisma combines approval rules with broad enrollment access

Prisma’s default policy allows preview work but requires approval for production writes, deletion, and connection-string creation, according to its changelog. The enrollment guide describes Allow, Ask, and Block rules, with approval covering one exact request or matching actions for one hour. The broader approval matches the action, project, and branch category, allowing more than one invocation. Enrollment reaches every workspace the sponsor belongs to. Project overrides can narrow access, but newly created projects remain reachable until overridden. One policy spans those workspaces, and either the sponsor or an administrator of any reachable workspace can change it.

The enrollment guide says pairing codes expire after 10 minutes and credentials last approximately 90 days. Pausing immediately rejects requests while preserving the credential; revocation permanently cancels it and retains history. Re-enrollment creates a new agent with default policy, so custom rules and overrides must be reapplied. Existing CLI sessions, user-authenticated Model Context Protocol (MCP) connections, and readable database URLs remain outside the agent policy. Agent credentials do not yet work with Prisma MCP, and production read-only connection strings are unavailable. These limits make credential replacement and alternative access paths part of policy maintenance.

GitHub Actions uses separate deployment credentials

Prisma’s official deployment action documents how a workflow authenticates separately from an enrolled agent. For a connected repository, a GitHub-issued OpenID Connect token is exchanged for a short-lived Prisma workspace token. The job requires the id-token: write permission; an explicit PRISMA_SERVICE_TOKEN can replace that exchange and takes precedence when present. The action documents production deployments from default-branch pushes and preview deployments from other branches. Its repository labels it experimental. Because deployments use the workflow’s credentials, Prisma’s changelog says they do not require approval under the enrolled agent’s policy.

The practical implication is that authorization follows the authenticated requester, including when another actor caused the request. An agent’s direct API request and a workflow triggered by its commit reach Prisma through different identities. Approval to configure infrastructure therefore does not necessarily cover each later production change. Prisma recommends default-branch protection and pull requests to review production deployments. Instructions telling an agent to open a pull request need repository controls to enforce that boundary. Teams should also avoid assuming that revoking the enrolled credential cancels workflow credentials or stops downstream execution.

Verify the full path to production

Before adopting either system, map the identities and credentials along an operation’s path. Include the human sponsor, agent credential, connected service account, repository access, workflow identity, and available database URLs. Verify attribution at each stage: Cursor’s different run owner and pull-request author show why one visible account may tell only part of the story. For Prisma, review workspace access, project overrides, who can change the shared policy, and which rules need reapplication after re-enrollment. For Glean, check each integration’s credential type and enforceable permissions rather than assuming uniform controls across integrations.

The reviewed material did not establish independently reproducible benchmarks or verified customer reports measuring these releases’ revocation latency, approval overhead, attribution completeness, or bypass resistance. It also leaves unresolved how revocation affects queued work and running downstream jobs, and how Glean’s Knowledge Profiles interact with user and service-account permissions. An acceptance test should exercise allowed and denied operations, revoke access during execution, and repeat through alternative credential paths. Record policy versions, timestamps, identities, approvals, request outcomes, and downstream effects. Use those results to check whether operations stop at the intended boundary after another system takes over.