Rovo Chat lacks consistent guardrails — falls back to general LLM knowledge instead of staying scope

I'm currently exploring and learning agentic AI frameworks, and while testing Rovo Chat's guardrail behavior as part of that learning, I noticed some inconsistencies in how it enforces domain/scope boundaries.

Rovo Chat currently answers out-of-domain questions by falling back to the underlying LLM's parametric (pre-trained) knowledge rather than staying grounded to indexed organizational context (Teamwork Graph / connected knowledge sources). This fallback behavior seems inconsistent depending on the topic category, suggesting category-specific filters rather than a genuine domain-relevance check.

Examples (generalized):

Asked about a public figure's role at an unrelated company - answered directly from parametric knowledge, ungrounded in any indexed Atlassian data.
Asked to generate a full script for an unrelated coding project - complied, functioning as a general-purpose code assistant rather than staying scoped to work-context tasks.
Asked about a different type of public-figure/role query, in a more politically sensitive category - declined and redirected to an external source. This is inconsistent with example 1, since both are equally out-of-domain, ungrounded queries.

Could Atlassian add a genuine domain/scope-relevance guardrail to default Rovo Chat, one that evaluates whether a query is grounded in Atlassian/org knowledge sources before falling back to ungrounded LLM generation, rather than applying category-specific content filters?

Domain-scoped AI assistants typically implement a hard guardrail, such as a scope-relevance classifier or system-level instruction, that rejects out-of-domain queries outright regardless of topic sensitivity, rather than relying on grounding/RAG only when convenient and falling back to raw LLM output otherwise. This reduces hallucination risk, keeps outputs auditable and traceable to a knowledge source, and avoids the assistant being used as an unscoped, ungrounded general-purpose tool.

Has anyone else noticed this inconsistency while building or testing Rovo agents? Would appreciate any suggestions, workarounds, or views on how you're handling scope/guardrail enforcement in your own agentic setups.