When AI creates issues, updates documentation, and adjusts schedules, a deployment must define what it can see, what it can change, and when it must ask for confirmation. Those decisions affect access, spending, and day-to-day project operations.
Start with four questions: Which account does it use? Which tools are available? What is the monthly budget? How can you inspect what happened? Define those controls before expanding autonomous work.
1. Review the bound Redmine account
Each AI Employee corresponds to a Redmine account. Redmine uses project membership and roles to determine permissions, and a user may have different roles in different projects. Bunny follows its bound account's permissions; it does not receive administrator access merely because it is AI.
A QA assistant might use an account participating only in selected testing projects. Test permitted projects, editable fields, and denied access explicitly. See Redmine's official roles and permissions documentation for the underlying permission model.
2. Restrict tools as well as account access
An account's permissions do not mean every AI needs every available tool. System administrators can configure tools for each AI Employee. Begin a reporting assistant with lookup and reporting tools; enable issue creation only when assignment and review rules are defined.
For MCP Client connections, review the other system's tools, service account, and data scope too. Redmine permissions cannot replace authorization in another service. Prompts specify confirmation behavior but should not replace account and tool restrictions.
3. Set monthly budgets before enabling schedules
Customers provide model API keys. System administrators control model and tool configuration. Bunny supports company-wide and individual AI Employee monthly budgets; project-level budgets are not currently available. Execution stops when the configured limit is reached.
Distinguish plugin or hosting fees, model-provider usage charges, and charges from connected services. A Bunny budget does not cap every external service's bill. Reconcile model charges with the provider, and compare task costs with the usefulness of the result.
4. Keep records that can be inspected
Execution information is retained as structured JSON, including tool operations, outcomes, and relevant usage. Large image files are excluded from complete retention. Records are currently retained indefinitely; periodic deletion or a different retention policy must be discussed during implementation.
Records help investigate which AI acted, which operations failed, and what happened around an incident. They do not guarantee that AI decisions are correct. Sensitive content, attachments, backups, and retention still need to follow organizational policy.
5. Define approval points and stopping controls
Approved actions can take effect directly, while Prompts can require confirmation for selected actions. Teams can define review rules for important status changes, issue closure, or key dates. System administrators can stop execution when needed.
Validate a small workflow first
Choose one project and purpose. List allowed operations, monthly budget, approval behavior, and acceptance criteria. Test successful work, denied access, exhausted budgets, and administrator stops; inspect whether the records explain each result. Expand tools and departments after validating the controls rather than granting broad access on day one.