Governance · Topic 1 of 1
Masking, Input Guardrails, Licensing and Source Mitigation
Databricks GenAI Engineer: mask PII as a guardrail, defend against prompt injection, check source licenses and fix problematic text at the source.
- 5 min
- Mask keeps the application answering; Block rejects the whole request or response.
- Mask before indexing when private values are not needed for answers.
- Defend against prompt injection in layers: input checks, system prompt, output checks, least privilege.
What it is
Governance for a generative AI application has two sides. The data side makes sure sources are legal to use and free of private or harmful text before they are indexed. The run time side uses guardrails to check what users send and what the model returns.
Masking replaces sensitive values such as names, emails and card numbers with a placeholder. It protects data while the application keeps answering, which is why the exam treats it as a guardrail that still meets a performance objective.
How it works
Masking as a guardrail
| Where you mask | How | Effect |
|---|---|---|
| Before indexing | ai_mask() or rules in the ingestion pipeline | Private values never reach the index or the LLM |
| On the table | Unity Catalog column mask | Users and agents without access see masked values |
| At the endpoint | AI Gateway PII detection set to Mask | Detected PII is replaced in requests and responses |
SELECT ticket_id,
ai_mask(ticket_text, array('person', 'email', 'phone')) AS clean_text
FROM main.support.tickets;ai_mask returns the text with each matching entity replaced by [MASKED]. It is in Public Preview and calls a Foundation Model APIs chat model. Newer docs mark the serving endpoint AI Gateway as legacy; Unity AI Gateway guardrails offer the same choice to redact or block.
The performance link is the choice between Mask and Block. Block rejects the whole request or response when PII is detected, which protects data but fails the user. Mask removes only the sensitive value and lets the answer through, so the application stays useful and available. Masking at ingestion also avoids a check on every request.
Guardrails against malicious user input
Malicious input tries to make the model ignore its instructions (prompt injection or jailbreak), reveal its system prompt or data, or produce harmful content.
| Technique | What it protects against |
|---|---|
| AI Gateway safety guardrail on input | Unsafe and harmful requests |
| AI Gateway PII detection on input | Users pasting personal data into the model |
| Jailbreak guardrail in the newer Unity AI Gateway | Prompt injection and jailbreak attempts |
| A classifier or guard model before the LLM | Off topic or attack style input, by your own rules |
| System prompt that separates instructions from user text | Weakens instruction override attempts |
| Least privilege tools and data | Limits damage if an injection succeeds |
| Rate limits on the endpoint | Abuse and automated attack volume |
Least privilege matters most for agents. An agent that calls Unity Catalog functions runs with the identity it was given, so restricting its grants caps what an injected instruction can make it do.
Layer the defenses. No single prompt or filter stops every attack, so combine input checks, a firm system prompt, output checks and narrow permissions.
Legal and licensing requirements for data sources
| Check | Why |
|---|---|
| Source license or terms of use | Some sources forbid commercial use or AI training |
| Copyright of scraped web content | Public does not mean free to reuse |
| Marketplace listing terms | Each data or model listing has its own terms |
| Model license | Some open models restrict commercial use or require attribution |
| Personal data and consent | Privacy laws limit using personal data without a basis |
| Attribution requirements | Some licenses require citing the source |
Record the license and source with each document, for example in a metadata column, so you can filter out restricted content and show sources in answers. If a license is unclear or forbids the use, the safe answer is to leave the source out or obtain permission.
Alternatives for problematic text in a data source
When a source contains toxic, biased, outdated or private text, fix it where it lives rather than relying only on output filtering.
| Option | When |
|---|---|
| Filter out the bad documents or rows during ingestion | The problem is limited to some records |
Clean or mask the text (ai_mask, rules, ai_classify to flag) | Useful content mixed with sensitive or offensive parts |
| Replace with a curated or licensed alternative source | The whole source is unreliable or unlicensed |
| Add metadata and filter at retrieval | Content is fine for some users or uses only |
| Output guardrails as a last layer | Catch anything that slips through |
Fixing the data once protects every query and every model that uses the index. A downstream filter alone keeps the bad text in the context, costs a check on every request and can still miss cases.
How the exam asks about this
- "PII detection blocks too many support answers that only mention a customer's email." Switch PII detection from Block to Mask, or mask at ingestion.
- "Users type 'ignore previous instructions' to extract the system prompt." Add input guardrails and keep tools on least privilege.
- "A forum dataset contains offensive posts mixed with useful answers." Filter or clean the source during ingestion instead of relying only on output filters.
What to remember for the exam
- Mask keeps the application answering; Block rejects the whole request or response.
- Mask before indexing when private values are not needed for answers.
- Defend against prompt injection in layers: input checks, system prompt, output checks, least privilege.
- Check the license of every data source and model before use, including commercial use and attribution.
- Fix problematic text in the source pipeline; use output guardrails as the last layer.
- Keep license and source metadata with each chunk.
"The data is on a public website" is not a license. Without terms that allow your use, leave the source out or get permission.
Common mistakes
Using Block when the goal is availability. Block stops harmful data but also stops the answer. When the question stresses keeping the application helpful, Mask is the better guardrail.
Trusting the system prompt to stop injection. Instructions in the prompt can be overridden by clever input. Combine them with gateway guardrails and narrow permissions.
Filtering only the output. Bad source text still reaches the model and can leak in ways a filter misses. Clean or replace the source first.
Check yourself
Why mask PII rather than block it to meet an availability goal?
Masking replaces only the sensitive values so the answer still reaches the user, while blocking rejects the whole request or response.
Which control limits the damage of a successful prompt injection in an agent?
Least privilege on the agent's tools and data, so the injected instruction cannot call or read more than the agent is allowed.
A source contains private customer details that answers never need. What is the better fix?
Mask or remove the details during ingestion, for example with ai_mask, so they never reach the index or the LLM.
Topic 1 of 1 in Governance
Test yourself on Governance
The full Databricks Generative AI Engineer Associate question bank has 600 questions, with timed practice exams and an explanation for every answer.
This study guide is independent and is not affiliated with, endorsed by, or sponsored by Databricks. Vendor names, certification names and exam codes are trademarks of their respective owners and are used for identification only.