Agent permissions

Last updated on Jul 15, 2026

---

Agent permissions control what Worker Agents can access and modify within Harness at runtime. You can configure permissions at two levels: pipeline-level permissions for runtime execution scope, and Role-Based Access Control (RBAC) permissions for managing agent lifecycle operations.

---

What will you learn in this topic?

By the end of this topic, you will be able to:

• Configure pipeline-level agent permissions for runtime execution.
• Understand supported entities and permission values.
• Configure RBAC permissions for agent management.

---

Before you begin

Before you configure agent permissions, ensure you have the following:

• Worker Agent created: At least one Worker Agent configured in your project. Go to Worker Agents for more information on creating agents.
• Admin or RBAC permissions: Access to configure roles and permissions in your Harness account.
• Pipeline edit access: Permissions to edit pipeline YAML if configuring pipeline-level agent permissions.

---

Agent permissions (pipeline-level)

Configure resource-level permissions for Worker Agents directly in pipeline stage YAML to control runtime access.

Feature flag

Currently, this feature is behind the feature flag HARNESS_TOKEN_INJECT. Contact Harness Support to enable it.

Agent permissions allow you to define explicit resource-level permissions for a Worker Agent directly in the pipeline stage YAML. When configured, the agent uses its own scoped permissions to access Harness entities during execution, rather than relying on a user's configured permissions via an Model Context Protocol (MCP) Connector.

This provides fine-grained control over what the agent can do at runtime without requiring a separate user identity or connector-level permission grants.

Configure agent permissions

The placement of the permissions block differs by stage type. Select your stage below.

CI, STO, SCS, IaCM (Stage Level)

In CI, STO, SCS, and IaCM stages, the Agent step runs directly in the stage. Add a permissions block under spec in the stage definition:

stages:
  - stage:
      name: Agent
      identifier: Agent
      description: ""
      type: CI
      spec:
        permissions:
          pipeline: view|edit|create|delete|execute|abort
          code_repository: view|edit|create|delete|push|review
          artifact_registry: view|edit|delete|uploadartifact|downloadartifact|deleteartifact|quarantineartifact|firewallexceptionapprove
          user: view|manage|invite|impersonate

CD, Custom (Step Group Level)

Add the permissions block to the Containerized Step Group, not the stage. The scoped token is injected into every step in the group and exposed as the HARNESS_TOKEN and HARNESS_BASE_URL environment variables, which steps read to authenticate with Harness APIs.

- stepGroup:
    name: Container
    identifier: Container
    permissions:
      pipeline: execute|view
      code_repository: view
      artifact_registry: view|downloadartifact
    steps:
      - step:
          type: Run
          name: Run_1
          identifier: Run_1
          spec:
            connectorRef: account.your_docker_connector
            image: busybox
            shell: Sh
            command: |-
              # Do not run 'env' in production. It dumps all environment
              # variables, including HARNESS_TOKEN, to the build log.
              echo "HARNESS_TOKEN: $HARNESS_TOKEN"
              echo "HARNESS_BASE_URL: $HARNESS_BASE_URL"
    stepGroupInfra:
      type: KubernetesDirect
      spec:
        connectorRef: account.your_k8s_connector
        namespace: your-delegate-namespace

The token is scoped to exactly the permissions declared on the step group. In the example above, every step in the Container group can execute and view pipelines, view code repositories, and view or download artifacts. No other actions are permitted, even if the agent author holds broader permissions.

---

Supported permissions

The following table lists the supported entities and their available permission values. Separate multiple permissions with the pipe (|) character.

Entity	Available permissions
pipeline	view, edit, create, delete, execute, abort. The view permission also grants access to pipeline execution data.
code_repository	view, edit, create, delete, push, review
artifact_registry	view, edit, delete, uploadartifact, downloadartifact, deleteartifact, quarantineartifact, firewallexceptionapprove
user	view, manage, invite, impersonate

---

How agent permissions work

Understand how pipeline-level agent permissions are evaluated and applied at runtime.

• The permissions block scopes the agent's access token down to only the specified entities and actions. The token cannot perform any action you do not list, even if the agent author holds broader permissions.
• The agent receives a runtime token with these permissions injected, independent of the pipeline author's personal permissions.
• This replaces the default behavior where the agent inherits the authoring user's credentials via an MCP Connector for Harness.
• Permissions are evaluated at pipeline execution time and apply for the duration of the agent step.

---

Current limitations

The agent permission token currently supports access to the following Harness entities only:

• Pipelines (including execution data)
• Code Repositories

Fetching data from the following modules is not supported with the agent permission token at this time: CI, CD, CCM, STO, SCS, and IaCM. For access to these modules, continue using user-configured permissions via an MCP Connector.

---

RBAC for Worker Agents

Worker Agents have dedicated RBAC permissions in Harness. Administrators can control who can view, create, modify, and delete agents through role-based access control.

Available permissions

Permission	Description
View	View agent definitions in the catalog
Create	Create new Worker Agents
Edit	Modify existing Worker Agent definitions
Delete	Remove Worker Agents from the catalog

Configure RBAC permissions

1. Navigate to Settings, then select Access Control.
2. Select or create a Role.
3. Under the AI Agents resource, enable the permissions you want to grant (View, Create, Edit, Delete).
4. Assign the role to the appropriate users or user groups.

Go to RBAC in Harness for more information on role-based access control. Go to Manage roles for more information on creating and assigning roles.

Next steps

• Worker Agents: Execute tasks inside Harness pipelines.
• Worker Agent examples: Explore PR review, IaC plan safety, and spec-driven development examples.