AIP-C01 Input and Output Safety Controls Guide

Study AIP-C01 safety controls for harmful prompts, jailbreaks, hallucination reduction, structured outputs, and defense-in-depth filtering.

AIP-C01 safety questions are about where to place the control and how many layers are needed. AWS is usually not asking for one “best guardrail feature.” It is asking how to prevent harmful inputs, constrain harmful outputs, reduce hallucinations, and make misuse harder across the whole request path.

What AWS is testing in this task

The current AIP-C01 domain page points to five recurring safety areas:

  • filtering harmful user inputs
  • preventing harmful model outputs
  • reducing hallucinations and enforcing more reliable responses
  • building defense-in-depth safety systems
  • detecting prompt injection, jailbreaks, and adversarial misuse

That means this task is broader than moderation alone.

Safety-control chooser

Requirement Strongest first fit Why
Need to block harmful or policy-violating prompts Input filters, guardrails, or moderation workflow Stop unsafe input before it reaches the FM
Need to prevent unsafe model outputs Output filters, Bedrock guardrails, or policy checks Output control belongs after generation too
Need to reduce hallucinations in factual answers Grounding, fact verification, structured outputs, or confidence checks Hallucination reduction is not the same as toxicity filtering
Need deterministic result shape JSON Schema or constrained output pattern Format control can reduce unsafe or unusable responses
Need stronger protection against jailbreaks or injected instructions Layered defenses across input, retrieval, tool use, and output One filter layer is usually not enough

Input and output are different control surfaces

Many weak answers collapse them together.

Input controls are strongest when the risk is:

  • malicious prompts
  • adversarial content
  • unsafe source documents
  • injected instructions in retrieved material

Output controls are strongest when the risk is:

  • harmful generated content
  • policy-violating responses
  • unsafe instructions or tool suggestions
  • structured-output failures

The strongest architecture often uses both.

Hallucination reduction is not just “be safer”

AWS explicitly includes accuracy verification systems. That means you should separate:

  • toxic or unsafe content control
  • factual grounding and verification

If the problem is “the system sounds confident but invents facts,” the stronger answer is often:

  • RAG or grounded context
  • fact-checking workflow
  • confidence scoring
  • structured response enforcement

not only a generic moderation layer.

Defense in depth is the exam habit

AIP-C01 increasingly rewards layered safety patterns:

  • pre-processing filters
  • Bedrock or model-native guardrails
  • retrieval hygiene and source trust checks
  • post-processing validation
  • safe execution boundaries for tools

If a question mentions prompt injection plus unsafe tools plus private data, a single control is usually incomplete.

Prompt injection clue

If retrieved content or user content can tell the model to ignore prior instructions, the real problem is broader than prompt quality. Strong answers usually add:

  • source trust or filtering
  • execution boundaries on tools
  • validation before action
  • output review for high-risk actions

Common traps

  • using one moderation control as if it solves hallucinations
  • treating jailbreak defense as a model-size problem
  • constraining output format but ignoring unsafe source content
  • solving a retrieval-trust problem only with output filtering
  • forgetting that structured output can also be a safety control

Fast decision rule

When the system is unsafe, ask separately: what enters, what the model sees, what it can do, and what leaves.

Quiz

Loading quiz…
Revised on Monday, June 15, 2026