Starburst AI Guardrails #

Guardrails are policies that govern how AIDA behaves: what it refuses, how it handles oversized inputs, and which topics it engages with. They apply to all AI models and agents on the account.

An administrator configures guardrails once, at the account level, and Galaxy applies them on every request. Prompt limiting validates the size of each message before it reaches the model. Agent protection, data product protection, and topic filtering adjust the model’s instructions for each turn. Guardrails are on by default. You can turn off any protection that is too strict for your environment.

Guardrails govern how AIDA behaves. They do not replace your existing security controls such as Database permissions, row-level security, column masking, and data product access which govern the data AIDA can reach.

Configuration #

Only users with the MANAGE_SECURITY privilege can view and edit guardrails. To edit the default guardrails, follow these steps:

1. Click AI > Guardrails in the Galaxy navigation menu.
2. On the Guardrails page, locate the Default policy. This policy applies to all AI models and agents on the account.
3. In the Default row, click the more_vert options menu, then select Edit.
4. In the Edit default guardrails dialog, select or clear the checkboxes for the protections you want, then click Save.

The following table lists the configurable guardrails and their default state:

Configurable guardrails #

The following sections detail each configurable guardrail protection.

Agent protection #

When on, AIDA resists two categories of misuse:

• Configuration extraction: AIDA refuses requests to reveal its instructions, list its rules, translate them, or document them through role-play.
• Indirect prompt injection: AIDA treats command-like text found in tool results or query rows as data, not as directives.

When turned off, AIDA uses a friendlier baseline. It might describe its own setup and is more likely to follow instructions embedded in tool results.

Data product protection #

Every chat session is scoped to one data product. When on, AIDA treats that scope as a hard boundary and:

• Refuses to run SQL against tables outside the data product, even if the user has direct Trino permissions for them.
• Refuses to display or template out-of-scope SQL.
• Refuses to display scope-expansion framings such as hypothetically, just this once, or as an admin.
• Refuses to use built-in tools as a general calculator, translator, or trivia engine.

External Model Context Protocol (MCP) tools attached to the session are unaffected and remain available. When turned off, AIDA receives the data product’s name and description as context only, and runs any SELECT query the user has permission for.

Prompt limiting #

When on, Galaxy rejects any message longer than the configured limit before it reaches the model. No tokens are consumed, and the user sees the following error:

Your request was too long. Please rephrase your question with less detail.

The limit ranges from 1 to 1,000,000 characters. The default is 50,000 characters.

When off, Galaxy enforces no length limit. The model’s own context window still applies.

Topic filtering #

When on, you provide a list of topic keywords or phrases, and AIDA refuses any request that touches one. The filter is semantic. For example, adding comedy refuses tell me a joke as well as the literal word.

Topic filtering suits organizations that want a narrowly focused analytics agent, such as a financial-services deployment that should not offer investment advice.

Topic filtering is off by default. No topic filter is applied.

How configuration changes affect chat sessions #

When an administrator saves a change to the guardrail settings:

• Galaxy writes an audit line to the coordinator log that records the acting user and the new settings.
• The updated settings apply to new chat sessions immediately.
• The updated settings also apply to existing chat sessions.

Changes to Prompt limiting take effect immediately. Galaxy enforces the new limit on the next message in any session.

Agent protection, Data product protection, and Topic filtering work by adjusting the model’s instructions on each turn. Because earlier replies remain in the conversation history, the model tends to stay consistent with what it has already said. In practice:

• Tightening protections mid-chat works for new topics. The next question is governed by the new setting.
• Tightening protections mid-chat does not redact earlier answers. Information already disclosed to the model stays visible, and the model might keep referring to it.
• Relaxing protections mid-chat does not always unblock prior refusals. After AIDA refuses a class of request, it tends to keep refusing similar follow-ups.

A guardrail block does not end the session; it only returns a message. The session continues in every case.

Limitations #

• Configuration is global: One configuration applies to the entire account. There are currently no per-data-product, per-user, or per-model overrides.
• Refusal logging is not yet aggregated: Galaxy logs guardrail configuration changes, including the acting user and the changed settings to the coordinator log. Individual block events appear in the chat session itself, but are not yet aggregated into a dashboard.
• External MCP tools are not actively scanned: When an external MCP tool returns a response, AIDA is instructed to treat that content as untrusted data rather than as commands. The response is not independently evaluated by an external LLM or security provider.

Troubleshooting #

You can turn off each of the four configurable controls individually.

Diagnose which guardrail is responsible #

1. Reproduce the problem in a new chat. If the refusal does not happen, it was caused by earlier turns in the previous session, not a guardrail.
2. If the new chat still refuses, match the symptom to a guardrail:
   • Rejected before any response: check Prompt limiting.
   • Refused to discuss its instructions or tools: check Agent protection.
   • Refused on a specific table: check Data product protection.
   • Responded with a statement that it cannot help with that topic: check Topic filtering.
3. Turn the guardrail off, retest in a new chat session, then turn it back on. This confirms the cause without leaving the account with relaxed protections.

Turn off a guardrail #

Open the Edit default guardrails dialog as described in the section, then clear the protections you want to turn off:

• Agent protection: The agent reverts to a friendlier baseline.
• Data product protection: The agent still receives the data product as context, but the scope is no longer a hard boundary. Any SELECT query the user has permission for runs.
• Prompt limiting: Galaxy enforces no length limit. The model’s own context limit still applies.
• Topic filtering: Galaxy preserves the topic list when off, so you can re-enable it later without retyping.

FAQ #

Q: Do guardrails replace row-level security and column masking?

A: No. Queries still run under the user’s identity, subject to the same row-level security and column-masking policies. Guardrails govern what the agent attempts; your existing controls govern what it can return.

Q: Are guardrails configured per data product, role, or user?

A: No. Guardrail settings are currently global. One configuration applies to the entire account, including every data product, model, chat session, and user.

Q: Should I raise the prompt limit?

A: The default of 50,000 characters is large enough for most pasted logs and short documents. Raise it only if you see legitimate messages being rejected. The maximum is 1,000,000 characters.

Q: I changed a guardrail mid-chat, but AIDA still behaves the old way. Why?

A: Most guardrail changes are sticky within an existing chat session. Agent protection, data product protection, and topic filtering adjust the agent’s instructions on each turn, but the model tends to stay consistent with its earlier replies. Start a new chat session to apply the changes. For more information, see .

Q: Why did topic filtering refuse a question that did not seem to match?

A: Topic filtering is semantic, so it refuses any request related to a listed topic, not only exact matches. For example, a comedy topic also refuses tell me a joke. Start with narrow, specific terms, and broaden them only as needed.

Q: Does AIDA log what it blocks?

A: Galaxy logs configuration changes to the coordinator log, including the acting user and the new settings. Individual block events appear in the chat session itself, but are not yet aggregated into a dashboard.