Welcome to Part 3 of our complete study series for the AI-103 Certification. After setting up security in Part 2, we now focus on keeping systems safe. In Microsoft Foundry (formerly Azure AI Foundry), you must know how to stop jailbreaks, block indirect prompt injections, detect hallucinations, and evaluate AI agents before putting them in front of real users.
| Microsoft Foundry Responsible AI & Safety: AI-103 Practice Questions |
In this free AI-103 practice exam module, you will solve 20 realistic questions on Azure AI Content Safety, User vs. Document Prompt Shields, Groundedness detection, and agent evaluation metrics. Each question has a clear, straightforward explanation so you know exactly why an answer is right or wrong.
Microsoft Foundry Responsible AI & Agent Safety Questions (Part 3)
Q1: Sensitive Data Privacy & Compliance (PII Detection)
You are developing an AI agent named Agent1 using Azure AI Foundry.
You need to configure the agent to meet organizational data privacy and compliance requirements by ensuring that sensitive user data is identified and handled appropriately.
Which feature should you use?
• D is correct: Personally Identifiable Information (PII) detection identifies and redacts sensitive information, such as names, addresses, and financial data. This is essential for meeting security and compliance requirements regarding data privacy (e.g., GDPR, HIPAA).
• A is incorrect: Prompt shields are used to protect the model against jailbreak attempts and indirect prompt injection attacks. They do not identify or manage sensitive data for compliance purposes.
• B is incorrect: Self-harm content filtering is a safety feature that detects and mitigates content related to self-harm. It does not address data privacy compliance requirements.
• C is incorrect: Violence content filtering is designed to detect and block violent or gory content. It is a safety measure, not a data privacy or compliance tool.
Q2: Defending Against Indirect Prompt Injection (Prompt Shields for Documents)
You are developing an application named App1 that uses a multimodal model deployed in Azure AI Foundry.
App1 performs optical character recognition (OCR) on user-uploaded images and appends the extracted text to the model's prompt as additional context. You discover that users might upload images containing embedded text with malicious instructions designed to manipulate the model's behavior.
You need to prevent these indirect prompt injection attacks from being processed by the model.
Which Azure AI Content Safety feature should you configure?
• D is correct: Prompt shields for documents are specifically designed to detect indirect prompt injection attacks. Because the OCR output is appended to the prompt as external context or "document" data, this shield will analyze the extracted text to ensure it does not contain hidden instructions meant to manipulate the model.
• A is incorrect: Protected material for text is used to detect and block known copyrighted or protected content from being generated by the model. It does not protect against prompt injection attacks.
• B is incorrect: Prompt shields for user prompts are designed to detect direct prompt injection attacks (jailbreaks) where the user's primary text input attempts to bypass model safety rules.
• C is incorrect: Image moderation analyzes visual content for categories like hate, violence, sexual content, and self-harm. It does not evaluate extracted OCR text for prompt injection instructions.
Q3: Governance of Irreversible Agent Actions (Human-in-the-Loop Approvals)
An enterprise risk committee is defining safety guardrails for autonomous agents that interact with transactional line-of-business systems (such as issuing financial refunds, updating credit limits, or modifying user records).
For each of the following statements regarding the implementation of safety controls for high-risk and irreversible actions, select Yes if the statement is true. Otherwise, select No.
1. Implementing a Human-in-the-Loop (HITL) approval flow ensures the agent pauses execution and waits for human sign-off before invoking tools that perform irreversible actions.
2. Fully autonomous execution without intermediate approval checkpoints is the recommended architectural pattern for tools that execute permanent database writes or financial transfers.
3. Increasing the model's maximum context window length inherently acts as a safety barrier that prevents the agent from calling unauthorized tools.
• Statement 1 is Yes: A Human-in-the-Loop (HITL) approval pattern is the industry standard for high-risk agentic actions. When the model decides to invoke a sensitive tool (e.g., executing a bank transfer), the workflow pauses, emits an approval request to a human operator, and only proceeds to invoke the tool after receiving explicit authorization.
• Statement 2 is No: Granting full autonomy with zero checkpoints on irreversible or destructive actions introduces critical compliance, financial, and operational risks, directly violating Responsible AI principles.
• Statement 3 is No: The context window simply determines how many tokens of conversation history the model can process at once. Expanding context size provides more memory capacity, but it provides zero guardrails or permission controls over tool execution.
Q4: Data Pipeline PII Redaction Sequence (Privacy by Design)
A healthcare contact center processes recorded patient consultations. The data pipeline must ingest raw audio transcriptions, generate concise diagnostic summaries, and store the transcripts in cold storage. To satisfy strict healthcare compliance standards, Personally Identifiable Information (PII) must never be exposed to generative model prompt logs or written unmasked to persistent storage.
Which sequence of actions should you execute? To answer, arrange the actions in the correct execution order.
- Ingest the raw conversation transcript from the audio pipeline.
- Execute Azure AI Language PII detection to identify and redact sensitive entities.
- Submit the redacted transcript to the language model for clinical summarization.
- Persist the sanitized transcript and clinical summary to Azure Data Lake Storage.
• Why this sequence is correct:
- Step 1 (Ingest): The pipeline first receives the raw transcript generated by speech recognition.
- Step 2 (Redact PII): Privacy-preserving architectures require PII masking before downstream processing. Calling Azure AI Language's PII detection replaces names, national IDs, and contact numbers with redaction markers (such as [REDACTED_NAME]).
- Step 3 (Summarize redacted text): Passing sanitized text to the generative language model ensures that confidential patient data is never logged in LLM telemetry, cached in prompt buffers, or inadvertently repeated in the generated output.
- Step 4 (Persist sanitized data): Storing only the redacted records guarantees that persistent storage complies with privacy regulations (such as HIPAA and GDPR).
• Why alternative approaches are incorrect:
- Summarizing before redacting: Exposes raw patient identifiers to the generative model, increasing the risk of data leakage in LLM logs and summary outputs.
- Translating to bypass redaction: Translating text does not remove personal data; identifiers are simply converted to another language.
- Rasterizing transcripts into images: Converting text to images adds processing overhead without removing PII, and optical recognition would still expose the underlying sensitive information.
Q5: Pre-Deployment Model & App Safety Evaluations (Yes/No)
A risk assessment team is establishing pre-deployment evaluation pipelines in Azure AI Foundry to evaluate safety risks in a customer-facing conversational agent.
For each of the following statements regarding the model-and-app safety evaluation process, select Yes if the statement is true. Otherwise, select No.
1. Automated safety evaluations in Azure AI Foundry simulate adversarial prompt attacks (jailbreaks) to test application resilience before the model is exposed to end users.
2. The primary goal of safety evaluation is to automatically downscale model hosting tiers to decrease per-token API operational costs.
3. Azure AI Foundry safety evaluators compute empirical defect rates across critical harm categories, including hate speech, sexual content, self-harm, and violence.
• Statement 1 is Yes: Azure AI Foundry provides built-in adversarial testing tools (red-teaming and prompt-injection simulators) that probe the application with adversarial jailbreak inputs to evaluate how effectively system prompts and content filters block unauthorized exploitation.
• Statement 2 is No: Safety evaluations assess governance, compliance, ethical alignment, and safety risks. They do not manage hardware tiering, compute provisioning, or token billing optimization.
• Statement 3 is Yes: Safety evaluations generate numeric defect rates (severity metrics) across Microsoft’s core responsible AI harm categories (Hate and Fairness, Sexual, Violence, and Self-Harm), allowing teams to measure whether harmful outputs are successfully blocked before reaching end users.
Q6: High-Risk Financial Agent Safeguards (Tool Constraints & Escalation)
A financial services company is deploying an AI agent built on Azure OpenAI to assist customers with account inquiries. The agent has access to tools that can read account balances, retrieve transaction history, and initiate fund transfers. The company's compliance team has defined the following requirements:
• The agent must never initiate a fund transfer exceeding $500 without explicit human approval.
• The agent must not respond to questions about investment advice or competitor products.
• If the agent cannot resolve a customer issue with high confidence, it must route the conversation to a human representative.
Which configuration approach best satisfies all three requirements within the agent's design?
• Why this answer is correct: This option addresses all three compliance requirements with standard, secure agentic patterns:
1. Financial Safeguard (Human-in-the-Loop): In enterprise agent architecture, critical or irreversible financial actions must never rely solely on probabilistic model text refusals. Enforcing an explicit Human-in-the-Loop (HITL) approval gate at the tool-execution level ensures transactions exceeding $500 physically pause execution until authorized by a human supervisor.
2. Topic Governance (System Prompt Instructions): Defining clear behavioral boundaries, forbidden topics (investment advice, competitor comparisons), and canned refusal guidelines in the system message establishes the baseline scope of the agent.
3. Escalation Pattern (Confidence-based Handoff): Setting a confidence/certainty threshold ensures that ambiguous queries, low-probability intents, or unresolved issues trigger an immediate, graceful live handoff to a human representative during the active session.
• Why the other options are incorrect:
- Why the read-only / remove tool option is incorrect: Completely removing the fund transfer tool breaks the agent’s core capability to perform valid transfers under $500. Additionally, transferring every customer interaction to a human representative regardless of confidence completely defeats the purpose and ROI of deploying an automated customer support agent.
- Why relying on post-processing filters and database logging is incorrect: Tools execute before or during prompt resolution, meaning an unauthorized fund transfer would already be executed on the backend database before any text-based post-processing filter inspects the output. Furthermore, writing low-confidence interactions to a database for review after the chat ends leaves the customer stranded with an unresolved issue during their live session.
- Why relying on model refusal and session timeouts is incorrect: Relying solely on the LLM's internal refusal behavior to guard financial transaction thresholds is non-deterministic and prone to jailbreaks. Disconnecting the user session after 5 minutes creates a terrible customer experience and directly contradicts the requirement to escalate to a human representative.
Q7: Input Moderation & Harm Prevention (Azure AI Content Safety)
You are developing a public-facing support agent within an Azure AI Foundry project.
To comply with corporate governance, you must ensure that any user inputs containing hate speech, harassment, or other harmful language are intercepted and blocked before the language model processes the request.
Which solution should you implement?
• B is correct: Azure AI Content Safety provides text moderation capabilities that detect unsafe, policy-violating, or harmful language (such as hate speech, self-harm, or violence) in user prompts before they are sent to the foundational model.
• A is incorrect: The max_tokens parameter limits the length of the response generated by the model. It does not inspect or filter user input for harmful content.
• C is incorrect: While uploading reference media (like policy documents) is useful for grounding the model in a Retrieval-Augmented Generation (RAG) pattern, it does not act as an active filter to detect and block malicious user input.
• D is incorrect: Provisioned Throughput (PTU) is a billing and deployment model that guarantees latency and throughput for model inference. It has no relation to content filtering or safety policies.
Q8: Quality vs. Safety vs. Agent-Specific Evaluators (Yes/No)
For each of the following statements about Azure AI Foundry's built-in evaluators, select Yes if the statement is true. Otherwise, select No.
1. Groundedness, Relevance, and Coherence are classified as quality evaluators, while Hateful and Unfair Content, Sexual, Violence, Self-Harm, Protected Material, and Indirect Attack are classified as risk-and-safety evaluators.
2. Running only the risk-and-safety evaluators against an agent's outputs is sufficient to confirm the agent is both safe to deploy and functionally accurate.
3. The Intent Resolution, Tool Call Accuracy, and Task Adherence evaluators are specific to evaluating agentic workflows, rather than being general-purpose text-quality evaluators.
• Statement 1 is Yes: Azure AI Foundry's evaluation suite separates quality evaluators (Groundedness, Relevance, Coherence, Fluency, and similar) from risk-and-safety evaluators (Hateful and Unfair Content, Sexual, Violence, Self-Harm, Protected Material, Indirect Attack, among others) — the two groups measure different dimensions of an application's behavior.
• Statement 2 is No: Risk-and-safety evaluators only measure whether outputs avoid harmful categories; they say nothing about whether the agent's responses are accurate, relevant, or coherent. Confirming both safety and functional quality requires running evaluators from both groups.
• Statement 3 is Yes: Intent Resolution, Tool Call Accuracy, and Task Adherence are agent-specific evaluators built to assess how well an agent understood the user's request, selected and used its tools, and stayed within its assigned task — capabilities that don't exist in a simple text-generation scenario without tools.
Q9: Proprietary Term & Codename Filtering (Custom Blocklists)
A company's internal codename for an unreleased product ("Project Falcon") must never appear in any output from their customer-facing support agent, regardless of the phrasing or the severity classification the text would otherwise receive from standard harm categories.
Which Azure AI Content Safety feature should you configure to guarantee this specific term is always caught?
• Why B is correct: Custom blocklists let you define your own exact terms or phrases to block, independent of the default harm categories (Hate and Fairness, Sexual, Violence, Self-Harm). Since "Project Falcon" isn't inherently hateful, violent, sexual, or self-harm-related, it would never be caught by those default categories no matter how their thresholds are set — a custom blocklist is the mechanism built for exactly this case.
• Why A is incorrect: The four default harm categories only classify content related to their specific harm type. A benign internal codename doesn't fall into any of them, so raising their thresholds has zero effect on catching it.
• Why C is incorrect: Groundedness detection checks factual accuracy against source material; it has no concept of a forbidden term list.
• Why D is incorrect: Prompt Shields detects adversarial injection attempts, not specific forbidden vocabulary in output.
Q10: Compliance Auditing for Sensitive Agent Actions (Select 2)
A regulated enterprise requires that whenever its agent attempts a high-risk action (such as issuing a large refund), the action must not only be paused for a human decision, but the entire event must also be reconstructable later during a compliance audit — including who approved or rejected it, and exactly when.
Which TWO capabilities must be implemented together to satisfy this? (Each correct selection forms part of the complete solution.)
• Why B is correct: A human-in-the-loop gate enforced at the point the tool actually executes ensures the high-risk action cannot proceed without explicit human sign-off — this is the control that creates the pause in the first place.
• Why D is correct: Satisfying an audit requirement means the approval decision itself must be durably recorded and tied to the specific run/event — who decided, what they decided, and when — so it can be reconstructed later. Without this, even a real approval gate leaves no auditable trail.
Why the other options are incorrect:
• Why A is incorrect: The model's own self-generated justification isn't a human decision and provides no independent verification; relying on it defeats the purpose of a human-in-the-loop control.
• Why C is incorrect: An aggregate daily count cannot be traced back to any specific event, approver, or timestamp, which is exactly what an audit of "this one action" would require.
• Why E is incorrect: Auto-proceeding after a timeout removes the human decision entirely for any case where no one responds in time — the opposite of guaranteeing human sign-off before the action executes.
Q11: Copyrighted Source Code Protection (Protected Material Detection)
A company builds a coding-assistant agent on Azure AI Foundry. During testing, the agent occasionally reproduces large verbatim snippets of copyrighted open-source code (with the original license header) in its responses to unrelated prompts.
Which Azure AI Content Safety feature should you configure to detect and block this specific behavior?
• Why B is correct: Protected material detection for code is specifically designed to identify known, existing source code (including matches to public repositories) appearing in a model's output, so it can be flagged or blocked before reaching the user — directly addressing verbatim reproduction of copyrighted code.
• Why A is incorrect: Prompt Shields detects adversarial inputs (jailbreak attempts or hidden instructions in external content); it has no role in detecting copyrighted output content.
• Why C is incorrect: Groundedness detection checks whether a model's output is factually supported by provided source material — it addresses hallucination, not copyright matching.
• Why D is incorrect: Custom blocklists match against exact terms or phrases you define yourself; they aren't designed to recognize arbitrary copyrighted code against a broad reference corpus the way protected material detection is.
Q12: Safety Thresholds & Filter Modes (Annotate vs. Filter)
A team configures Azure AI Content Safety on their Azure OpenAI deployment. They lower the severity threshold for the Hate and Fairness category from Medium to Low, so that even mildly borderline content gets blocked, and they set the filter mode to "Filter" rather than "Annotate."
Which statement correctly describes a consequence of this specific configuration change?
• Why A is correct: A Low severity threshold is more restrictive — content classified at Low, Medium, or High severity for that category will be actioned, versus a Medium threshold only actioning Medium and High. "Filter" mode means matching content is actually blocked (the API returns a filtered result), whereas "Annotate" mode would only attach severity labels without blocking, leaving enforcement to the calling application.
• Why B is incorrect: Content filtering severity/threshold configuration is independent of the deployment billing type (Standard, Global Standard, or Provisioned); it applies the same way regardless of deployment type.
• Why C is incorrect: This reverses the actual behavior — "Annotate" only labels content with a severity score without blocking it; "Filter" is the mode that actively blocks. Annotate mode does not block automatically.
• Why D is incorrect: Severity thresholds apply to both text and image content categories; they are not limited to images only.
Q13: Agent-Specific Evaluators (Intent, Tools, Adherence)
Match each evaluation description to the specific Azure AI Foundry agent evaluator that measures it. Each evaluator is used exactly once.
1. Measures whether the agent correctly identified and scoped what the user was actually asking for.
2. Measures whether the agent called the right tool with the correct parameters, in the correct order, based on prior steps.
3. Measures whether the agent's final actions and responses stay within the boundaries of its assigned task and policy constraints.
4. Measures whether the agent chose only the tools genuinely needed for the task, without calling unnecessary or redundant ones.
• 1 → Intent Resolution: Measures how well the agent identifies the user's actual intent, including whether it scopes the request correctly and asks clarifying questions when needed.
• 2 → Tool Call Accuracy: Checks whether the agent's tool invocations used correct parameters extracted from prior context and were called in a sensible order to accomplish the task.
• 3 → Task Adherence: Checks whether the agent's behavior and output stayed consistent with its assigned task, system instructions, and any policy constraints throughout the interaction.
• 4 → Tool Selection: Specifically measures whether the agent picked the appropriate tools for the job without selecting extra, unnecessary ones — a distinct concern from whether a called tool was used correctly.
Q14: Automated Adversarial Testing (AI Red Teaming Agent & PyRIT)
Before launching a new customer-facing agent, a safety team wants to automatically and systematically probe it with simulated adversarial behavior — including jailbreak attempts, encoding-based bypass tricks, and multi-turn escalation strategies — and receive a scored Attack Success Rate (ASR) report, rather than relying only on manual expert testing.
Which Azure AI Foundry capability should the team use?
• Why C is correct: The AI Red Teaming Agent integrates Microsoft's open-source PyRIT (Python Risk Identification Tool) framework directly into Azure AI Foundry, automatically simulating adversarial probing against a model or agent endpoint using a variety of attack strategies, then scoring the results (including Attack Success Rate) — exactly the automated, systematic adversarial testing described.
• Why A is incorrect: Custom blocklists match against specific terms you define; they don't simulate adversarial attacker behavior or produce attack-success metrics.
• Why B is incorrect: Running the standard Risk and Safety Evaluators against a static dataset measures how outputs score on harm categories for the inputs you already have — it doesn't itself generate novel adversarial attack strategies or escalate across multiple turns the way red teaming does.
• Why D is incorrect: Groundedness detection checks whether output is supported by source material; it has no adversarial-simulation function.
Q15: Conversation Audit & Tool Inspection (OpenTelemetry Tracing)
A compliance officer needs to investigate a specific past customer conversation with an agent, reconstructing exactly which tools the agent called, in what order, with what parameters, and what intermediate reasoning steps led to its final response.
Which capability should have been configured on the agent to make this reconstruction possible?
• Why A is correct: Tracing captures the full execution path of an agent's run — each model call, each tool invocation with its inputs/outputs, and the intermediate steps — which is exactly the level of detail needed to reconstruct what happened in one specific past conversation, and can be retained and queried via Application Insights.
• Why B is incorrect: Content Safety diagnostic logs only record content that was evaluated against harm categories (and typically only what was flagged); they don't capture the agent's tool calls, parameters, or reasoning steps.
• Why C is incorrect: Aggregate metrics (like hourly token counts) show volume trends, not the step-by-step detail of one specific conversation.
• Why D is incorrect: A chat transcript typically records only the user-visible messages exchanged — not the underlying tool calls, parameters, or intermediate reasoning the agent performed to get there.
Q16: Hallucination & Fabrication Detection (Groundedness Detection)
An enterprise RAG-based assistant summarizes internal policy documents for employees. During review, the team notices the assistant sometimes states specific numeric figures or dates that don't actually appear anywhere in the retrieved source documents — the model is inferring or fabricating details not present in the grounding data.
Which Azure AI Content Safety capability should be added as a runtime check to catch this specific failure mode before the response reaches the user?
• Why this is correct: Groundedness detection evaluates whether a model's generated claims are actually supported by the source material it was given, and is specifically built to catch fabricated or unsupported details — i.e., hallucinations — which is exactly the failure mode described (numbers/dates not present in the retrieved documents).
• Why "Violence content filtering" is incorrect: This category detects violent content; it has nothing to do with factual accuracy or hallucinated details.
• Why "Prompt Shields for documents" is incorrect: This detects hidden malicious instructions embedded in third-party documents used as context; it does not evaluate whether the model's own output is factually consistent with that context.
Q17: Provenance & Tamper-Evident Metadata (Content Credentials C2PA)
A media company generates promotional images using an image-generation model deployed in Azure OpenAI. They need every generated image to carry tamper-evident, cryptographically signed metadata proving it was AI-generated and identifying the generating system — verifiable later even after the image has been redistributed — without building any custom solution themselves.
Which capability satisfies this requirement?
• Why D is correct: Content Credentials are automatically applied to images generated by Azure OpenAI's DALL-E and image-generation models, with no extra setup required. The credential is a manifest cryptographically signed by a certificate tracing back to Azure OpenAI, recording that the image is AI-generated and which system produced it — and it can be independently verified later using a Content Credentials verification tool.
• Why A is incorrect: Alt text is plain descriptive metadata with no cryptographic signature — it's trivially editable or removable and provides no tamper-evidence or verifiable authenticity.
• Why B is incorrect: A visible watermark can indicate AI origin visually, but on its own it isn't cryptographically signed, structured provenance metadata, and can be cropped or edited out without technical detection.
• Why C is incorrect: Content Safety image moderation detects harmful visual content (violence, sexual content, etc.); it has no function related to proving an image's origin or authenticity.
Q18: Risk-Proportionate Oversight Modes (Autonomous vs. Supervised vs. HITL)
Match each agent scenario to the oversight mode that correctly fits its risk level. Each mode is used exactly once.
1. A read-only agent that summarizes public news articles for an internal newsletter, with no ability to modify any system or contact anyone externally.
2. An agent that drafts and automatically sends customer support replies, where an occasional poor reply is recoverable but reputationally undesirable.
3. An agent with a tool that permanently deletes customer records from the production database.
• 1 → B: With no irreversible or harmful consequence possible, requiring a human to approve every summary would add friction with no safety benefit — periodic audit review is proportionate to the risk.
• 2 → C: The risk is real but recoverable, so real-time monitoring with the ability to intervene (a kill-switch) balances responsiveness against safety, without the throughput cost of gating every single reply.
• 3 → A: A permanent, irreversible action on production data warrants a mandatory per-action approval gate — the consequence of an unauthorized or mistaken call is severe enough that no lesser oversight mode is appropriate.
Q19: Enforcing Least-Privilege Tool Scoping for Agents
A single agent definition currently has five tools registered: send_email, delete_database_record, read_calendar, create_calendar_event, and issue_refund. The team wants to deploy a "Customer FAQ" persona of this same agent that should only ever need to answer scheduling questions.
To correctly enforce least-privilege tool access for this persona, the team should:
• Why this is correct: Least privilege means the agent has no technical capability to invoke a tool it doesn't need — not merely an instruction telling it not to. A dedicated configuration that never registers send_email, delete_database_record, or issue_refund makes it impossible for this persona to call them, regardless of prompt injection, hallucination, or reasoning errors.
• Why relying on the system prompt alone is incorrect: Instructions are a non-deterministic control. A jailbreak, an indirect prompt injection, or a plain reasoning mistake can still cause the model to attempt a call to a tool that remains technically registered and available, even if told not to use it.
• Why keeping all five tools and relying on Content Safety is incorrect: Content Safety screens text content for harm categories; it has no mechanism to gate which tools an agent is permitted to invoke, so it would not prevent an unintended delete_database_record or issue_refund call at all.
Q20: Closing Multi-Agent Delegation Gaps (Select 2)
A multi-agent system has an Orchestrator Agent that delegates tasks to a Finance Sub-Agent (authorized to call issue_refund, gated by human approval above $500) and a Support Sub-Agent (never authorized to touch financial tools). The architecture team is concerned that the Orchestrator itself, or the Support Sub-Agent acting through it, could end up triggering issue_refund without the required approval gate ever being enforced.
Which TWO design choices correctly close this gap? (Each correct selection forms part of the complete solution.)
• Why A is correct: Enforcing the approval gate at the actual tool-execution layer means it applies no matter which agent or path led to the call, closing off any delegation route that might otherwise slip past a check that only existed earlier in the chain.
• Why D is correct: Explicit per-agent tool scoping ensures the Support Sub-Agent and the Orchestrator itself never have direct technical access to issue_refund in the first place — the least-privilege half of the fix, complementing the approval gate that governs the Finance Sub-Agent's legitimate access.
Why the other options are incorrect:
• Why B is incorrect: Relying on the Orchestrator's own prompt instructions is a non-deterministic control, vulnerable to reasoning errors or unanticipated delegation paths — precisely the risk the scenario describes.
• Why C is incorrect: This increases the exposed attack surface by giving a second agent direct access to a sensitive tool, working against the goal instead of closing the gap.
• Why E is incorrect: After-the-fact daily logging doesn't prevent an unauthorized refund from happening; it only supports investigating it once the harm may already be done.
Microsoft Foundry Safety & Governance Cheat Sheet
Passing the official Azure AI Apps and Agents Developer Associate exam requires knowing which safety tool solves which problem. Use this quick comparison to keep your safety guardrails straight on exam day:
| Safety Capability | What It Detects | Where It Applies | Default Action & Enforcement |
|---|---|---|---|
| Azure AI Content Safety | Four core harm categories: Hate and Fairness, Sexual, Violence, and Self-Harm across a 0 to 7 severity scale. | User prompts and model completions (text and images). | Blocks content outright if mode is set to Filter. Only attaches labels if set to Annotate. |
| Prompt Shields (User Prompts) | Direct prompt injection and jailbreak attempts coming straight from the user's text input. | Inbound user prompts. | Blocks the request before it reaches the language model. |
| Prompt Shields (Documents) | Indirect prompt injection attacks hidden inside third-party data (like web pages, emails, or OCR text). | External context, RAG search chunks, and tool outputs. | Scans and strips malicious instructions before context is injected into the model prompt. |
| Groundedness Detection | Hallucinations, unsupported claims, and made-up facts (like fake dates or numbers). | Model completion vs. grounding source data. | Assigns an ungroundedness severity score. Can be set to flag for review or block responses. |
| Protected Material (Text & Code) | Verbatim matches against copyrighted text and publicly known software repository code. | Model completions. | Blocks or redacts matching code snippets to protect intellectual property. |
| Human-in-the-Loop (HITL) | High-risk, irreversible operations (like issuing bank transfers or deleting production records). | Agent tool execution layer. | Physically pauses tool execution until a human reviewer signs off in real time. |
Key Takeaways for AI-103 Domain 1 (Responsible AI & Safety)
• Severity Levels (0 to 7): Content Safety uses a scale from 0 to 7 grouped into four buckets: 0 (Safe), 2 (Low), 4 (Medium), and 6 (High). Setting a threshold to Low is stricter because it blocks Low, Medium, and High content. Remember: Filter mode blocks the call, while Annotate mode only tags it.
• User Shield vs. Document Shield: User Prompt Shields catch direct jailbreaks typed by the person chatting. Document Shields catch indirect prompt injections hidden inside files, emails, or web search results that an agent reads via RAG or tool calls.
• Groundedness vs. RAG Quality: Groundedness detection checks whether the model's answer is actually supported by the source text it received. This stops hallucinations. It is different from retrieval quality, which only checks whether your search index found the right documents in the first place.
• Agent-Specific Evaluators: Testing agents requires more than just checking text fluency. Microsoft Foundry provides four agent-specific evaluators: Intent Resolution (did the agent understand the goal?), Tool Selection (did it pick the right tools?), Tool Call Accuracy (did it pass correct parameters?), and Task Adherence (did it follow system instructions?).
• Hard Tool Scoping vs. Prompts: Never rely only on system prompt instructions to stop an agent from using a dangerous tool. An agent can always hallucinate or get jailbroken. True least-privilege security means deploying a configuration where sensitive tools are completely unregistered.
Frequently Asked Questions (Responsible AI & Agent Safety FAQ)
Here are straightforward answers to the most common safety and governance questions tested on the AI-103 exam:
What is the difference between Prompt Shields for User Prompts and for Documents?
User Prompt Shield blocks direct jailbreaks where a user tries to trick the model through chat input. Document Shield catches indirect prompt injections hidden inside third-party content—like uploaded PDFs, emails, or search results—that the user never wrote but that the agent reads as grounding context.
Does Groundedness Detection stop hallucinations, or just flag them?
It can do both depending on your setup. Groundedness detection checks whether model claims match the provided source documents and produces a severity score. You can configure it to simply log warnings for audit review, or actively block ungrounded responses before the user sees them.
What is the difference between quality evaluators and risk-and-safety evaluators?
Quality evaluators (Groundedness, Relevance, Coherence, Fluency) measure whether an answer is helpful, accurate, and easy to read. Risk-and-safety evaluators (Hate, Sexual, Violence, Self-Harm, Protected Material, Indirect Attack) measure whether output is harmful. You need both to confirm an agent is safe and working correctly.
Can Azure AI Content Safety block words that are not hateful or violent?
Yes, by using custom blocklists. The four default harm categories only detect hate, violence, sexual content, and self-harm. Harmless terms—like unreleased internal project codenames or competitor brand names—will not trigger default categories. Creating a custom blocklist lets you match and block exact terms independently.
Why is a system prompt instruction not enough to stop an agent from misusing a tool?
System prompt instructions are non-deterministic. A jailbreak, an indirect prompt injection, or a simple reasoning mistake can cause a model to call any tool that remains technically registered. Enforcing least privilege requires deploying an agent configuration where sensitive tools are completely removed from its registration.
Next Step in Your AI-103 Certification Journey
Congratulations on completing Part 3! You now understand how to protect your AI solutions using Azure AI Content Safety, stop direct and indirect prompt attacks, detect hallucinations, and establish Human-in-the-Loop governance for enterprise agents.
Now that safety and security are locked down, it is time to build. In Part 4 of our series, we focus on Building Generative AI Applications with Foundry (RAG & Workflows). We will explore vector indexing in Azure AI Search, chunking strategies, hybrid search reranking, and orchestrating RAG pipelines.
Whenever you are ready to continue your preparation, use the navigation below: