Skip to main content
Permissions control what agents are allowed to do when running automations or interactive sessions. Every action the agent attempts is checked against the permission system before it executes.

​
Three modes

Each action resolves to exactly one of three modes:
ModeBehavior
allowThe action executes immediately without human intervention.
require_approvalThe action blocks until a human approves or denies it.
denyThe action is rejected. The agent is informed and cannot retry.

​
Mode resolution

Permissions are resolved through a three-tier cascade. The first match wins:
1

Automation override

A mode set on a specific automation for a specific action. Highest priority.
2

Organization default

A mode set at the organization level for a specific action.
3

Inferred default

If no explicit override exists, the mode is inferred from the action’s risk level: read actions default to allow, write actions default to require_approval, and danger actions default to deny.
This means you can set broad defaults at the org level and override them per automation when needed.
Start with the inferred defaults. They are conservative — read actions auto-execute, write actions require approval, and dangerous actions are blocked. Loosen permissions as you build trust.

​
Action permissions

Configure action modes at the automation or organization level. Here is an example configuration: 
permissions:
  actions:
    linear:create_issue: allow            # auto-execute
    linear:update_issue: require_approval # ask a human first
    sentry:update_issue: require_approval
    slack:send_message: allow
    github:merge: deny                    # never allow
Each key follows the format <source>:<action>. Sources include built-in integrations (linear, sentry, slack) and MCP connectors (connector:<uuid>). Automation-level overrides take priority over org-level defaults: 
# Organization default
sentry:update_issue: require_approval

# Automation override for "Sentry Triage Bot"
sentry:update_issue: allow    # this automation is trusted to resolve issues

​
Approval workflows

When an action resolves to require_approval, the agent pauses and a notification is sent. Where approvals appear:
  • Web dashboard — The inbox tray in the session view shows pending approvals with full parameter details.
  • Slack — If notifications are configured, the approval request is posted to the automation’s Slack channel.
Approval options:
  • Approve Once — Approves this specific invocation only.
  • Approve & Always Allow — Approves this invocation and updates the org-level permission to allow for future invocations of this action.
  • Deny — Rejects the invocation. The agent is notified and adapts.
Pending approvals expire after 5 minutes. If no one responds, the action is marked as expired and the agent is notified. A session can have at most 10 pending approvals at a time.
Only users with admin or owner roles can approve or deny actions.

​
Scope limits

Beyond action permissions, you can restrict which repositories, branches, and files an automation can touch: 
permissions:
  repos:
    - myorg/frontend
    - myorg/backend
  branches:
    exclude:
      - main
      - production
  files:
    exclude:
      - "*.env"
      - "secrets/*"
This ensures automations operate only within the boundaries you define, regardless of what actions are allowed.

​
Connector drift detection

When you connect an MCP server, Proliferate hashes each tool’s schema. If a tool’s schema changes after you have configured its permissions, the system detects the drift and adjusts:
Previous modeAfter driftReason
allowrequire_approvalDowngraded until an admin re-reviews the changed tool.
require_approvalrequire_approvalNo change — already requires human review.
denydenyStays denied. Drift never upgrades a denied tool.
Drift detection prevents a connected MCP server from silently expanding what it can do. When you see a “needs re-review” indicator in the automation permissions UI, check the tool’s updated schema and confirm the permission.

​
Roadmap

Planned improvements to the permission system:
  • Granular per-user permissions — Allow different team members to have different approval authorities.
  • Audit logging improvements — Detailed logs of every permission resolution, approval, and denial for compliance.
  • Custom approval chains — Multi-step approval workflows where sensitive actions require sign-off from multiple reviewers.