How-To Guides / Admin

Create a Global Permission Policy

Permission policies define what actions agents can take across your organization. Set once at the org level and apply everywhere — with the option to override per configuration.

Admin

Permissions

Overview

How permission levels work

For every action an integration can perform, you set one of three permission levels. The policy applies to every agent using that configuration unless a stricter override is in place.

Auto-approve

The agent performs the action immediately without interrupting the user. Best for low-risk, read-only, or high-frequency actions.

Examples: Search code, read Slack messages, look up tickets

Require approval

The agent pauses and sends a notification to designated approvers. The workflow resumes after a human signs off.

Examples: Create a PR, send a Slack message, close a ticket

Blocked

The agent is not allowed to take this action at all, regardless of context. Use this for destructive or out-of-scope operations.

Examples: Delete a repository, remove users, purge data

How To

Creating a permission policy

Open Capabilities → Policies → New Policy

In the Telara dashboard, open Agents → Capabilities from the sidebar, select the Policies tab, and click New Policy.

Name your policy

Give the policy a clear, descriptive name that reflects its intent — for example, "Engineering Standard", "Read-Only Baseline", or "Security Team Full Access".

Select which integrations this policy covers

Choose the integrations this policy applies to. You can cover all connected integrations or target specific ones.

Policy builder showing the integration selector with checkboxes for each connected platform

Set permission levels per action

For each integration, you'll see a table of all available actions. Set each to Auto-approve, Require approval, or Blocked.

Action permission table with three columns: auto-approve, require approval, and blocked — with radio buttons per action row

Configure approval step for 'Require approval' actions

For any action set to "Require approval", configure who gets notified when an agent needs sign-off — by role (e.g., all admins) or specific users. Also set the timeout: how long the agent will wait before the request expires.

Approval step configuration showing notified users selector, notification channel, and timeout duration

Choose Tenant scope to govern broadly

To make a policy govern across the organization, set its scope to Tenant when you create it. A tenant-scoped policy can be attached by anyone in the organization to their configurations, and it can be used in scope assignments. The org-wide baseline is the tenant Default policy — to change the floor, edit that policy rather than replacing it.

Save and publish

Click Save Policy. The policy is live immediately — any configurations using it will apply the new rules on the next agent action.

Policy inheritance

The global org-level policy is always the floor. A configuration can attach a custom policy, but that policy cannot be more permissive than the org default — it can only be equal to or stricter. If no custom policy is attached, the org default applies automatically.

Templates

Common policy templates

These starter configurations cover the most common needs. You can use them as a starting point and customize individual action permissions from there.

Read-Only Baseline

All write and destructive actions are blocked. Search, read, and list actions are auto-approved. Good for external contractors or read-only analyst access.

Engineering Standard

Developer tool read actions (search, browse, fetch) are auto-approved. Write actions (create PR, open issue, merge) require approval. Destructive actions are blocked.

Fully Autonomous

Low-risk actions are auto-approved. Only explicitly destructive actions (delete, remove, purge) are blocked. Suitable for senior engineers or trusted automated pipelines.