**Problem** The current chatbot access model requires administrators to configure both: The access deepchat api Drupal permission The Assistant entity's allowed roles These checks overlap and can become inconsistent. When they do not match, users may either not see the chatbot at all or see it but encounter access errors. This makes chatbot permissions harder to understand and configure. **Proposed solution** Remove the access deepchat api permission and rely on Assistant access checks as the single source of truth. **Potential implementation:** - [ ] Move to a more lenient permission (access content?) or open it up completely without access. - [ ] If we open up completely without access we have to think about possible implications - DDOS against CSRF etc. or people sending direct request. - [ ] One more complex implentation is to have one endpoint per assistant and derive the route permission from that assistant. Administrators configure chatbot access in one place (the Assistant's allowed roles), while chatbot visibility and API access remain consistent and aligned. **Parent issue** This issue is a child of the broader permission simplification effort tracking chatbot, Assistant, and agent access controls.