Restrictions

Restrictions are runtime access controls for what Stilla can read and do on its own. They apply when Stilla reads connected data, calls a tool, accesses the network, or executes a change proposal.

Restrictions are not limited to agents. Organization and user-group policies apply in direct chats and channels as well as agent runs. An individual agent can then have a narrower policy for its particular job.

How policies compose

Stilla can evaluate policies from several layers:

1. Organization restrictions set the baseline for every user and interaction in the organization.
2. Group restrictions customize that baseline for members of a user group. When a group defines the same default, app, or resource layer as the organization, the group value takes precedence. If a user belongs to several groups that define the same layer, the most permissive group value wins.
3. Agent restrictions are evaluated in addition to the user's effective organization and group policy. Both policies must allow an operation, so an agent can narrow what its user may do but cannot widen it.

In a regular chat without an agent policy, the user's effective organization and group policy still applies.

Administrators can also configure default agent restrictions. This policy is copied to each newly created agent and can then be adjusted by its owner. Changing the default does not change existing agents.

Levels of control

A policy starts with default access and can become progressively more specific:

1. Default access provides the baseline for connected systems.
2. App or connection rules override the default for a native integration or for an individual MCP or Pipedream connection.
3. Resource rules override the app rule for a particular channel, repository, recipient, drive, folder, file, or canvas.

The most specific matching rule wins within a policy. For example, a file rule takes precedence over its folder and drive, and an exact email address takes precedence over an email-domain rule.

Access levels

Most apps and resources support these access levels:

Network access has additional modes for using the organization's network settings or limiting access to trusted sources.

Individual tools and actions

Instead of granting every operation on an app or resource, select the individual tools and change types Stilla may use. Tool-level controls work across native integrations and the discovered tools on individual MCP and Pipedream connections.

For example, a policy can:

• Allow GitHub reads and issue comments without allowing issue creation or other GitHub writes.
• Allow a monitoring agent to search Slack without allowing it to send messages.
• Allow selected tools from one MCP connection while denying the rest of that server's tools.
• Allow one action in a specific repository or channel without allowing every write action there.

For MCP servers, Stilla also uses the server-provided readOnlyHint tool annotation to distinguish reads from mutations. Tools Stilla treats as mutating are routed through change proposals.

Resource rules

Resource rules let you separate what Stilla may learn from where it may act. A policy can allow broad access to an app while granting or denying access for particular resources.

Supported resource rules include:

• Stilla canvases and folders
• Google Drive files, folders, and drives
• OneDrive folders and drives
• Slack, Discord, and Microsoft Teams channels
• GitHub repositories
• Exact email addresses and email domains for Gmail, Outlook Mail, Google Calendar, and Outlook Calendar
• URL and domain patterns for network access

Some resource types provide convenient virtual targets. Slack rules can cover all public channels or the current user's own direct message, and email rules can target the current user.

Examples include:

• Read email broadly, but send only to the current user, selected recipients, or approved domains.
• Read only public Slack channels and send only to the current user's DM or #incident-response.
• Use Google Drive broadly while denying access to sensitive documents in selected shared drives or folders.
• Read all GitHub repositories but open issues or comments only in one repository.
• Read the Stilla workspace but edit only canvases in a project folder.

When an operation has several targets, Stilla evaluates each one independently. An email or calendar invitation with several recipients is allowed only if every address passes the policy.

Enforcement

Restrictions are checked at runtime against the actual tool, operation, and target resource. Stilla checks them again when an agent executes a change proposal, using the live policy and current target rather than only the values that existed when the proposal was created.

Restrictions control what Stilla can do on its own:

• Stilla can still draft a change proposal that it is not allowed to execute.
• An authorized person can review and accept that pending proposal in the app.
• To require human review for a class of changes, give the agent read-only access or select only the read operations for that app or resource. The agent can prepare the proposal, but it cannot execute it.

Some actions have additional safeguards. Agents cannot execute messages or reactions in Slack Connect channels. They also cannot execute non-draft Gmail or Outlook Mail sends, or Google or Outlook Calendar invitations and updates, involving external addresses unless every address is an organization member or is explicitly allowed by an email-address or domain rule.

Network restrictions use the same policy composition. They apply to regular web search and fetch as well as HTTP and HTTPS traffic from Stilla's sandboxed computer.

Configure restrictions

Organization administrators manage organization, group, and default-agent restrictions under Settings → Organization → Restrictions. Organization restrictions apply to direct chats, channels, and agents; default-agent restrictions affect only agents created after the setting is changed.

Agent owners configure an individual agent's restrictions from the agent canvas. These restrictions can tighten the user's effective policy but cannot override an organization or group restriction that blocks an operation.

For a least-privilege agent, start with No access or Read only, then add only the apps, tools, and resources required for its job. This is especially important for agents that process email, documents, web pages, or other untrusted content.

For the security model behind these controls, see Prompt injection security at Stilla.