# Enroll your agent (/docs/prisma-compute/agent-enrollment) > For the complete Prisma documentation index, see [llms.txt](https://www.prisma.io/docs/llms.txt). A markdown version of any docs page is available by appending `.md` to its URL. Give a coding agent its own Prisma credential and a permission policy you control, so it asks you before sensitive API actions and every request it makes is logged. Location: Prisma Compute > Enroll your agent Enrolling a coding agent lets it set up Prisma for you: it can create projects and databases, connect a GitHub repository, and configure deploys through the [Prisma REST API](https://www.prisma.io/docs/rest-api). It does this with a credential of its own, and you decide which of its actions need your approval first. Without enrollment, an agent uses your signed-in CLI session, so to Prisma the agent is you. It has all of your access, the audit log records its actions as yours, and you can only stop it by signing yourself out. An enrolled agent gets its own credential instead, so you can pause or revoke it without affecting your own access. It also gets a permission policy: by default it works freely on [preview branches](https://www.prisma.io/docs/compute/branching), the non-production copies of a project with their own apps and databases, and asks you before it changes production or does anything destructive. The person who approves the enrollment becomes the agent's sponsor, and every request the agent makes is recorded under its own name with that sponsor attached. ## Prerequisites [#prerequisites] * A [Prisma account](https://pris.ly/pdp). You approve the enrollment while signed in to [Prisma Console](https://console.prisma.io/?utm_source=docs\&utm_medium=content\&utm_content=%28index%29), Prisma's web dashboard. * A coding agent that can make HTTP requests and write files in your project, such as Claude Code, Codex, or Cursor. * To deploy, a GitHub repository for your app. An enrolled agent deploys through a GitHub Actions workflow. ## How enrollment works [#how-enrollment-works] Enrollment pairs the agent with your account through a short code, the same way you sign in to a streaming app on a TV. The agent never sees your password or your session. ## 1. Copy the enrollment instructions [#1-copy-the-enrollment-instructions] Prisma Console gives you a block of instructions that an agent follows to enroll itself. In Prisma Console, open any of your workspaces (it doesn't matter which), go to **Settings → Agents**, and click **Enroll agent**. You can also open [console.prisma.io/enroll](https://console.prisma.io/enroll?utm_source=docs\&utm_medium=content\&utm_content=%28index%29) directly. Under **No pairing code yet?**, click **Copy instructions**. The instructions tell the agent how to: * request a pairing code and wait for your approval * save its credential to a file that Git ignores (the instructions suggest `.prisma/agent-token`), and reuse the credential in later sessions * handle requests that need your approval * connect a GitHub repository and deploy through GitHub Actions ## 2. Give the instructions to your agent [#2-give-the-instructions-to-your-agent] Paste the instructions into your agent's chat. The agent starts an enrollment and shows you an eight-character pairing code, such as `KQ7M-R4TX`. The code expires after 10 minutes. While it waits, the agent keeps checking with Prisma for your approval, so leave the session running. > [!NOTE] > After the agent is enrolled, also paste the same instruction block into your project's `AGENTS.md` or `CLAUDE.md`, as its own section, so future sessions reuse the credential. The block starts by telling the agent to use its saved credential when the file exists, and to enroll again only when the file is missing or Prisma rejects the credential. ## 3. Approve the pairing code [#3-approve-the-pairing-code] Back in Prisma Console, enter the code on the **Enroll agent** page and click **Continue**. Before you approve, check that: * the code on screen matches the one your agent showed you * **Client** and **Device** name your agent (for example, Claude Code) and your machine * **Workspaces** shows what the agent will be able to reach: every workspace you belong to. You can't limit the agent to fewer workspaces. After enrollment you can hide individual projects from it with a [project override](#what-the-agent-can-do), but the agent can still reach projects created later until you add an override for them too. When you click **Approve enrollment**, you become the agent's sponsor. Within a few seconds, the agent receives its credential and saves it. If anything doesn't match, click **Deny**, and the agent gets no credential. If the page says **Enrollment expired**, more than 10 minutes passed. Ask the agent to start again, then enter the new code. ## 4. Confirm the agent is connected [#4-confirm-the-agent-is-connected] Ask your agent to list your Prisma workspaces. It should answer with the workspaces you saw in step 3. The agent checks that Git ignores its credential file before saving it, but it's worth confirming, because a committed credential would give anyone with the repository the agent's access. If your agent saved the credential somewhere other than `.prisma/agent-token`, ask it for the path and use that in the commands below. First, check that Git isn't already tracking the file: ```bash git ls-files .prisma/agent-token ``` If the command prints nothing, the file isn't tracked. If it prints the path, the credential is committed, and an ignore rule won't remove it. [Revoke the agent](#pause-or-revoke-an-agent), because the credential stays in your Git history. Then stop tracking the file with `git rm --cached .prisma/agent-token`, add `.prisma/` to `.gitignore`, and enroll the agent again. Then check that Git ignores the file: ```bash git check-ignore -v .prisma/agent-token ``` When the file is ignored, the output names the `.gitignore` rule that covers it: ```text no-copy .gitignore:12:.prisma/ .prisma/agent-token ``` If the command prints nothing, the file is not ignored. Add `.prisma/` to `.gitignore` before your next commit. In Prisma Console, the agent now appears as **Active** under **Settings → Agents**: ![The Agents page in Prisma Console, listing four enrolled agents with their sponsors, permission policies, and statuses, plus two pending approval requests waiting for review.](https://www.prisma.io/img/prisma-compute/agent-enrollment/agents-list.png) Every member of a workspace can see the agents listed there. The agent has one policy for all of your workspaces. You, or an admin of any workspace the agent can reach, can change that policy, pause the agent, or revoke it, and the change applies in all of them. ## What the agent can do [#what-the-agent-can-do] Every agent starts with the default policy, which decides what happens to each REST API request the agent makes: | Rule | Covers | Default | | -------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------- | ------- | | Preview branches | Viewing, creating, and changing anything on a preview branch, such as databases, apps, buckets (file storage), and environment variables | Allow | | Production branches, read | Viewing anything on a production branch | Allow | | Production branches, write | Creating or changing anything on a production branch, including linking a GitHub repository to the project | Ask | | Admin actions | Deleting anything, creating a workspace, and creating service tokens (workspace API keys) or database connection strings | Ask | These rules refer to the branches of a Prisma project. The branch a project starts with (usually `main`) is its production branch, and every other branch is a preview branch with its own databases and apps. See [Branching](https://www.prisma.io/docs/compute/branching) for how they relate to your Git branches. A preview app still connects to whatever database its `DATABASE_URL` points to. If a preview's `DATABASE_URL` points at your production database, changes the policy allows on that preview can reach production data. Give each preview its own preview-scoped `DATABASE_URL`, as described in [Environment variables](https://www.prisma.io/docs/compute/environment-variables). Deleting anything or creating a connection string asks even on a preview branch, because both are admin actions; a connection string is a lasting credential for the database. Creating a project doesn't ask. Creating a database on a preview branch doesn't ask either, but creating one on the production branch does, and a database created without choosing a branch counts as production. The policy covers the agent's REST API requests only. When the agent pushes code, the deploy runs in GitHub Actions and signs in to Prisma separately, not with the agent's credential, so the policy can't stop it. See [Build and deploy with your agent](#build-and-deploy-with-your-agent). > [!WARNING] > Enrolling an agent doesn't sign you out. If you're signed in to the Prisma CLI on the same machine, an agent can still run CLI commands as you, outside its policy, and the same goes for a Prisma MCP server you connected to your agent with your own account. The policy also doesn't cover database connection strings the agent can already read, such as `DATABASE_URL` in your `.env` file: with one of those, the agent connects to the database directly. The enrollment instructions tell the agent to use its own credential. If you want the policy to be the only way the agent reaches Prisma, sign out of the Prisma CLI while the agent works: > > > > > #### bun > ```bash > bunx prisma@latest auth logout > ``` > > > #### pnpm > ```bash > pnpm dlx prisma@latest auth logout > ``` > > > #### yarn > ```bash > yarn dlx prisma@latest auth logout > ``` > > > #### npm > ```bash > npx prisma@latest auth logout > ``` > > > > Sign back in with `npx prisma@latest auth login` when you want to deploy from your terminal again. To change the policy, open the agent from **Settings → Agents** and select the **Permissions** tab. Set each rule to **Allow**, **Ask**, or **Block**; each change saves as soon as you click. A blocked request fails right away, without asking you. ![The Permissions tab for an agent, showing the default policy: preview branches and production reads set to Allow, production writes and admin actions set to Ask.](https://www.prisma.io/img/prisma-compute/agent-enrollment/permissions.png) To make an exception for a single project, use **Project overrides** below the rules: choose a project, choose **Full access** or **No access**, and click **Add override**. * **Full access** allows every request in that project, production writes included. * **No access** hides the project from the agent entirely. ## Approve requests [#approve-requests] When a request matches an **Ask** rule, Prisma doesn't run it. It waits for your decision, and after you approve, the agent sends the same request again and continues its task. The agent sends you a link to the request in its chat. The request also appears in Prisma Console as an approvals counter in the header, in the **Pending approvals** list on the Agents page, and on the agent's **Approvals** tab. Each card shows what the agent wants to do, the exact API request, whether it targets production, and the agent's reason when it gave one: ![An approval card showing that an agent wants to create a database, with operation and production-branch chips, the exact API request, the agent's stated reason, and Approve once, Approve for 1 hour, and Deny buttons.](https://www.prisma.io/img/prisma-compute/agent-enrollment/approval-card.png) Choose one of three responses: | Response | What it allows | | ---------------------- | ------------------------------------------------------------------------------------------------------------------------------------------ | | **Approve once** | This exact request, one time. | | **Approve for 1 hour** | The same action for the next hour, such as creating databases, in the same project and on the same kind of branch (production or preview). | | **Deny** | Nothing. The request is not run, and the agent learns that you denied it. | Use **Approve for 1 hour** when the agent will repeat a step, so you don't approve each request separately. Requests of any other kind still ask. You don't need to tell the agent what you decided, because it checks for your decision on its own. Each request waits 5 minutes for your decision, and the card shows a countdown. If you miss it, the agent tries again and a new card appears for you to approve. For 24 hours, you can also approve an expired request from the history on the agent's **Approvals** tab by clicking **Approve anyway**, and the next time the agent sends that request, it goes through. If the agent has stopped, ask it to retry. The agent's sponsor or an admin of the workspace the request targets can decide. Requests that don't belong to a workspace yet, such as creating a new workspace, can only be decided by the sponsor. ## Review what the agent did [#review-what-the-agent-did] Open an agent from **Settings → Agents** to see its history. The **Activity** tab lists every request the agent made and what the policy decided: allowed, approved, approval required (paused for your decision), or denied. Requests that a **Block** rule stopped show as denied. You can filter by decision and time range, and export the list as CSV. The **Approvals** tab shows what the agent asked for, who decided, and the outcome. A check mark next to **Approved** means the agent used the approval. Expand a row to see the agent's reason and the full timeline. ![The approval history table for an agent, showing requests with their targets and outcomes: approved with a check mark showing the agent used it, approved for one hour, denied, and expired.](https://www.prisma.io/img/prisma-compute/agent-enrollment/approval-history.png) Agent requests also appear in the workspace audit log under **Settings → Audit log**. ## Pause or revoke an agent [#pause-or-revoke-an-agent] Both controls are at the bottom of the agent's **Permissions** tab: * **Pause agent** makes Prisma reject all of the agent's requests, starting immediately. The credential stays valid, and **Resume agent** restores access. To the agent, a paused credential looks like a rejected one, so it may start a new enrollment. Deny any pairing code it shows you while paused; after you resume, its existing credential works again. * **Revoke agent** permanently cancels the agent's credential. Its activity and approval history stay. To reconnect the agent, enroll it again. An agent also loses access when: * its credential expires, about 90 days after enrollment. Prisma then rejects the credential, so the agent starts a new enrollment for you to approve. Each enrollment creates a new agent with the default policy, so reapply any policy changes and project overrides afterward. * you leave a workspace. Your agents lose access to that workspace at the same time. * you delete your Prisma account. ## Build and deploy with your agent [#build-and-deploy-with-your-agent] With the agent enrolled, ask it to deploy your app: ```text Deploy this app to Prisma Compute from its GitHub repository, using your enrolled Prisma credential. ``` If you already deployed the app from your terminal, tell the agent the names of the project and database to use, as shown in Prisma Console, so it doesn't create new ones. The agent works through the REST API and pauses where your policy asks: 1. It finds or creates a workspace and a project. Creating a workspace asks for your approval. 2. It creates a Prisma Postgres database for production, which asks for your approval. 3. It connects your GitHub repository. If the Prisma GitHub App isn't installed on the repository yet, the agent gets a link from Prisma for you to open and install it. Linking the repository to the project also asks. 4. It adds a `.github/workflows/prisma-deploy.yml` workflow that runs [prisma/cloud-deploy-action](https://github.com/prisma/cloud-deploy-action). Because the repository is connected to Prisma, the workflow can sign in to Prisma without a token stored in the repository. 5. It pushes to GitHub, using the Git access already set up on your machine. Pushes to your default Git branch deploy to the project's production branch, and pushes to other Git branches deploy to preview branches. > [!WARNING] > A push to your default Git branch deploys to production without asking you, because the deploy runs with the workflow's credential, not the agent's. To review production deploys first, [protect your default branch](https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches) in GitHub and tell the agent to open pull requests instead of pushing to it. You can put that rule in your prompt or in `AGENTS.md`, for example: `Never push to main. Open a pull request for every change.` See [Deploy on push](https://www.prisma.io/docs/compute/deploy-on-push) for how the workflow deploys and cleans up preview branches. ## Limitations [#limitations] * Agent credentials work with the Prisma REST API. The Prisma MCP server (Prisma's tool server for AI assistants) doesn't accept them yet. * You learn about pending approvals from the link the agent sends you and from Prisma Console. Email and mobile notifications aren't available yet. * Prisma doesn't offer agents read-only connection strings for production databases yet. Creating any connection string is an admin action, so each one asks for your approval. ## For agent builders [#for-agent-builders] The enrollment instructions already teach an agent how to handle approvals. If you build your own integration, a request that needs approval fails with the error code `approval_required`, and the response carries a link for the sponsor and an approval to poll. Send the link to the sponsor, then [poll the approval](https://www.prisma.io/docs/rest-api/endpoints/agents/get-agent-approvals-by-approval-id) until the sponsor decides. After an approval, send the original request again, unchanged. To show the sponsor why the agent needs an action, send a `Prisma-Agent-Reason` header with one sentence of justification. It appears on the approval card. ## Next steps [#next-steps] * [Deploy on push](https://www.prisma.io/docs/compute/deploy-on-push): how the GitHub workflow deploys production and preview branches. * [REST API](https://www.prisma.io/docs/rest-api): the API your agent calls. * [Deploy your first app](https://www.prisma.io/docs/prisma-compute/deploy): deploy from your own terminal instead. ## Related pages - [`Deploy your first app`](https://www.prisma.io/docs/prisma-compute/deploy): Take a TypeScript app from your terminal to a live URL on Prisma Compute with Prisma Composer, starting from scratch or from an app you already have.