Agent restrictions

Agents are powerful — they can read data, create issues, send messages, and modify code. Restrictions let you control exactly what each agent can do, following the principle of least privilege.

Why restrictions matter

Without restrictions, an agent has access to everything you've connected to Stilla. That's fine for personal agents you run manually, but for automated agents running on a schedule or responding to channel mentions, you often want tighter controls.

Restrictions let you:

• Prevent agents from accidentally sending messages to the wrong channel
• Limit code changes to specific repositories
• Keep agents read-only for monitoring and reporting tasks
• Allow specific actions while blocking others

Access levels

Configure per agent at three levels:

Granularity

Set restrictions at three levels of specificity. The most specific level wins:

1. Default: A baseline for all connected apps (e.g., read-only by default)
2. Per app: Override for a specific app (e.g., GitHub = read-only, Linear = full access)
3. Per resource: Override for a specific resource within an app — a Slack channel, an email address, a Linear team, etc. (e.g., allow writing to #deployments but read-only everywhere else in Slack)

Action-level control

Beyond read/write access, you can allow or block specific action types. For example:

• Allow commenting on GitHub issues but not creating new ones
• Allow creating Linear issues but not changing status on existing ones
• Allow sending Slack messages to specific channels only

Asking before executing

Configure agents to always create change proposals that require human approval, rather than executing actions directly. This is useful for:

• High-stakes agents that modify production systems
• New agents you're still testing
• Compliance requirements that mandate human review