Skip to main content
Guardrails keep Automations running securely and within defined boundaries. For general Ona guardrails (policies, SSO, audit logs), see Ona Guardrails.

​
Environment isolation

Each Automation runs in an isolated environment with dedicated resources. No access to other Automations or user environments. See Environments.

​
Command deny lists

Prevent Automations from executing dangerous commands (sudo, rm -rf /, cloud CLIs). Blocked commands fail immediately. Configure at the organization level. See Command deny lists.

​
Executable deny list

Block specific binaries from running inside Automation environments using kernel-level enforcement. Unlike command deny lists, executables are identified by content hash and cannot be bypassed by renaming. See Executable deny list.

​
Audit logging

Every execution is logged: commands, file changes, PRs created, errors. Use for debugging and compliance. See Audit logs.

​
Organization policy limits

Automation organization policy controls are in preview and available only to selected Enterprise organizations.
Organization administrators can configure Automation limits in Settings → Agents → Policies → Automations:
  • Automations per member limits how many active Automations each member can own. The default is 5. Disabled Automations and Automations pending deletion do not count.
  • Projects per Automation limits how many projects a member can select explicitly in one Automation.
  • Concurrent actions limits how many actions an Automation can run at once.
The policy page shows the configured values and the Enterprise maximums: 50 Automations per member, 100 projects per Automation, and 25 concurrent actions. Organization Admins and Automations Admins are exempt from organization-configured Automation limits. Plan and API maximums still apply. Lowering the ownership limit does not modify existing Automations, but members at the limit cannot create or reactivate another Automation.

​
Action limits

Control parallel execution to manage costs and prevent Automations from running excessively. Maximum values depend on your plan. Core plans enforce the caps listed above. Enterprise organizations can configure the concurrent-action policy up to the current system-wide ceiling of 25. The total-action limit remains subject to the system-wide ceiling of 100 actions per Automation. Contact sales if you need higher limits. Creating or updating an Automation with a concurrent-action value above the effective organization, plan, or API limit returns an error. Lowering the organization policy preserves existing Automation configuration, but the next action edit must comply with the current limit. Until then, new executions use the lower current limit. The same execution-time protection applies if a plan or API limit is reduced.

​
Project limits

Enterprise organization admins can limit how many projects a member may select explicitly in one Automation, up to 100 projects. This limit applies to project contexts, not repository URL or repository search contexts. Creating or updating an Automation with too many unique project IDs returns an error. Lowering the organization policy preserves existing Automation configuration, but the next project-context edit must comply with the current limit. An existing Automation that exceeds the current limit cannot start a new project-context execution until its project selection is updated.

​
Per-execution time limit

Each execution action can have an optional maximum duration. When set, actions that exceed this time are stopped automatically. Configure this in the Automation’s action limits.

​
Queue behavior

When the concurrent limit is reached, additional actions queue and start as others complete. When the total limit is reached, the Automation stops. Increase limits and re-run to process remaining targets.

​
Next steps