You are implementing a multi-agent claims-processing workflow in Microsoft Foundry. Subagents receive instructions assembled from shared system prompts plus per-task user context. Security review finds that a malicious user message can override the underwriting agent's refusal rules by injecting "ignore previous instructions." What should you implement first in the prompt design?
Select an answer to reveal the explanation.
Short Explanation
Answer A. In multi-agent Foundry solutions, untrusted user text must never be able to rewrite agent policy. Put hard refusal and scope rules in immutable system/policy sections, clearly separate them from user/task content, and teach each agent that user text cannot override those rules. Raising temperature does not stop injection. Parking messages only in memory skips the live prompt path where injection happens. Collapsing to one tool-less model avoids the symptom but throws away the multi-agent design you still need to secure.
Full Explanation
Correct answer: A. Advanced prompt engineering for multi-agent systems includes defensive guidelines and prompt lifecycle management. Policy, persona, tool boundaries, and refusal rules belong in privileged prompt sections that are not treated as mutable by later user content. Each agent should have explicit non-override language and scoped behavioral guidelines so a claims user cannot reassign the underwriter as a general assistant.
B is incorrect because temperature affects sampling randomness, not instruction hierarchy or injection resistance.
C is incorrect because long-term memory is a storage concern; the attack surface is how untrusted text is composed into the active context window for tool-capable agents.
D is incorrect because removing tools and agents is an architecture rollback, not a prompt-hardening control, and does not address defensive multi-agent prompting skills measured on AI-500.
Exam focus: immutable policy blocks + clear separation of trusted vs untrusted content in multi-agent prompts.