Platform / Agent IAM
Agent IAM
Control what your AI agents can do. Set permission levels for every action -- auto-approve safe actions, require approval for sensitive ones, and block anything that should never run automatically.
Getting Started
Set up permissions in five steps
Permission policies define what your agents are allowed to do. Follow these steps to create your first policy and attach it to a configuration.
Go to Settings > Policies and click "Create Policy." Give it a name that reflects its purpose.
Select the platforms your agent should be able to interact with (Jira, GitHub, Slack, etc.)
Choose auto-approve, require approval, or blocked for each action
Specify which roles can approve actions and set how long approval requests stay open
Go to your configuration and attach the policy to activate it
Core Concept
Permission levels
Every action your agent takes is checked against your permission policy. The policy determines whether the action proceeds immediately, requires human approval, or is blocked entirely.
The agent executes the action immediately. It is logged in your audit trail.
Safe, read-oriented actions that do not modify data
The agent pauses, sends a notification, and waits for someone on your team to approve or deny.
Actions that create or modify content and need oversight
The agent is denied immediately. The attempt is logged in your audit trail.
Destructive or high-risk actions that should never run automatically
Policy Settings
What a policy controls
A permission policy defines per-integration, per-action controls plus who can approve actions that require it. Here is what you can configure for each integration.
Which categories of actions are permitted. Categories include read, write, admin, and delete. Only actions in the allowed categories will be available to the agent.
Fine-grained permission overrides for specific actions. These take precedence over the category defaults and let you tighten control on individual actions without changing the entire category.
Which roles in your organization can approve actions. Common values: admin, owner, member. Only users with these roles will see and act on approval requests.
How long an approval request stays open before it auto-denies. Set shorter times (15-30 min) for time-sensitive workflows, longer times (1-24 hours) for batch operations.
Approval Steps
How approvals work
When an agent needs to perform an action set to "require approval," it pauses automatically and a structured approval flow begins. The agent does not proceed until a designated approver makes a decision.
The action pauses immediately. Nothing happens until someone approves.
A request appears in the Telara dashboard with full context about the action and what the agent wants to do.
Designated approvers are notified via email, Slack, or in-app notifications depending on your settings.
Approve, deny, or let the request expire. All decisions are logged to the audit trail.
If approved, the agent resumes automatically. If denied or expired, the agent is notified and can continue with other tasks.
Set reasonable timeout values based on urgency. If no approver responds within the configured time, the request auto-denies and the agent is notified. This prevents actions from hanging indefinitely. Typical values: 30 minutes for interactive workflows, 24 hours for batch operations.
How They Connect
Policies attach to configurations
Policies do not exist in isolation. They attach to configurations, which define the complete setup for your agent -- including data sources and search tools.
Multiple Policies
How policies merge
When multiple policies are attached to the same configuration, they merge into a single effective policy. The rule is simple: the most restrictive setting wins per action. Adding more policies never loosens permissions.
Most restrictive setting wins
Restriction order: auto-approve require approval blocked
Templates
Pre-built policy templates
Policy templates provide pre-configured starting points so you do not have to build policies from scratch. Templates include built-in guardrails -- permission levels that are locked and cannot be relaxed, no matter what customizations you make.
A general-purpose template for agents that need to create and modify content. Destructive actions require approval, administrative actions are blocked.
A restrictive template for agents that only need to read data. All write, delete, and admin actions are blocked and cannot be changed.
A guardrail is a permission level locked by the template. You can make a setting more restrictive (e.g., change require approval to blocked), but you can never make it less restrictive. This ensures organizational safety standards are always enforced.
Action Types
Investigation vs resolution actions
Actions are categorized into two types based on their impact. Each type has a sensible default permission level, but you can override any action individually in the policy builder.
Read-only operations that gather information without modifying anything. These are safe to run automatically because they have no side effects.
Write operations that create, modify, or delete resources. These have real-world side effects and benefit from human oversight.
Defaults are starting points. In the policy builder, you can override the permission level for any individual action. For example, you can set a specific investigation action to require approval, or allow a resolution action to auto-approve if your team has validated it is safe.
Catalog Policies
Pre-built catalog policies
Catalog policies are pre-built configurations for common use cases. Instead of building a policy from scratch, select a catalog policy and customize it to fit your needs.
Pre-configured for managing build pipelines, deployments, and release workflows. Investigation actions are auto-approved, deployment actions require approval.
Optimized for code review workflows. Reading code and comments is auto-approved, posting reviews and merging require approval.
Built for on-call and incident management. Investigating alerts is auto-approved, escalating and paging require approval.
Designed for issue tracking and project coordination. Viewing boards and backlogs is auto-approved, creating and assigning tasks require approval.
Selecting a catalog policy pre-fills integrations and permission levels as a starting point. You can add or remove integrations, change permission levels for specific actions, and adjust approval settings before saving. Each catalog policy is composed of one or more policy templates that encode best practices for that workflow.
Access Control
Scope access
Policies can be scoped to control who can use and attach them. Scopes determine visibility and availability across your organization.
Available to everyone in the organization. Any user can attach this policy to their configurations.
Only members of that team can see and attach this policy. Useful for team-specific governance rules.
Only members of that project can use this policy. Ideal for project-specific workflows with custom permission requirements.
Only a specific user can use this policy. Best for individual developer workflows or personal experimentation.
If a policy is created without a scope assignment, only admins can attach it to configurations later. Assign a scope during creation to make the policy available to the right people from the start.
Recommendations
Best practices
Practical guidance for setting up effective permission policies.
Begin with a read-only policy and gradually add write actions as you build confidence in the agent's behavior. You can always relax restrictions later.
Use "require approval" for any action that creates, modifies, or deletes content. This gives your team visibility into what agents produce before it reaches external systems.
Use 15-30 minutes for time-sensitive interactive workflows. Use 1-24 hours for batch operations where immediacy is less critical. Avoid very long timeout values.
Policy templates encode best practices and safety guardrails. Start from a template and customize from there rather than building from scratch.
Create focused policies for specific use cases (e.g., "jira-triage-policy", "github-review-policy") rather than one large policy. This makes merging behavior predictable.
Actions like deleting repositories, removing team members, or deleting channels should be blocked entirely. If they are truly needed, use "require approval" at minimum.
Scope
What permissions do not cover
Permission policies focus specifically on controlling which actions an agent can take. Other aspects of agent behavior are managed by separate parts of the platform.
Configure which data sources your agent can query using the data sources settings in your Configuration
Set up triggers, scheduling, and multi-step workflows in Automations
Control how frequently an agent can call specific actions within a time window
Limit the scope and duration of individual agent sessions