Exams / AIP-C01 / Study guide / Agent safeguards (stopping conditions, timeouts, IAM boundaries, AgentCore Policy)
Agent safeguards (stopping conditions, timeouts, IAM boundaries, AgentCore Policy): AIP-C01 study notes and practice questions
What to know about Agent safeguards (stopping conditions, timeouts, IAM boundaries, AgentCore Policy) for the AIP-C01 exam, from the Implementation and Integration domain (26% of the exam guide), then 1 free question to test it. Part of the AIP-C01 study guide.
AIP-C01 describes an agent that loops, a tool that hangs, or an agent that could delete data, and asks which control contains the damage. The strongest answers enforce limits outside the model, in code, IAM or policy, because a prompt instruction can be ignored.
Stopping, timeouts and circuit breakers
Maximum iterations: cap the number of reasoning steps or tool calls. When the cap is reached, the agent returns a clear partial answer instead of looping.
Timeouts: set each tool’s timeout below the caller’s timeout. Lambda functions can run up to 15 minutes, but a lookup tool should fail fast. API Gateway REST API integrations time out at 29 seconds by default, so long agent calls need a different pattern, such as WebSockets or asynchronous invocation.
Circuit breaker: after a set number of consecutive failures, stop calling a failing tool for a while and return a fallback. Retry only transient errors, with exponential backoff and jitter.
IAM least privilege
Give each tool its own execution role that allows only the exact actions and resources the tool needs. An agent that reads one table should not share a role with an agent that can write to every bucket. Never give an agent broad, long-lived credentials.
AgentCore Policy
AgentCore Policy checks rules on each tool call that passes through AgentCore Gateway. Rules are written in Cedar, and they can restrict which tools an agent may call and which parameter values are allowed. Because the check runs outside the agent’s code, a manipulated prompt cannot switch it off.
Human confirmation and budgets
Confirmation for destructive actions: the agent proposes the action, and the workflow pauses until a person approves. See the human-in-the-loop topic for the pattern.
Per-session budget: count tokens and tool calls per session in the application, and end the session when the budget is spent. Alarm on unusual spend with CloudWatch.
How to choose
Scenario wording
Choose
“Agent loops between the same two tools”
Maximum iterations plus a circuit breaker
“A downstream API hangs and stalls the agent”
Shorter tool timeout with a fallback response
“Agent must never delete production records”
Tool role without delete permissions, plus Policy deny
“Restrict which parameter values a tool accepts, outside the code”
AgentCore Policy at the Gateway
“Stop one user’s runaway spend”
Per-session token and tool-call budget
“Agent may trigger a refund”
Approval pause before the action
Common traps
A prompt rule as the only safeguard, such as “never delete files.” Enforce it with IAM or Policy.
Retrying a failing tool forever. Retries need a limit and a backoff, and the breaker needs to open.
One shared admin role for all agent tools.
Guardrails as action control. Guardrails filter content in and out. They do not decide which tool calls are allowed.
Policy checks inside the agent’s own code, which the agent or a prompt injection can bypass.
Setting every Lambda timeout to the maximum for a tool that should answer in seconds.
A logistics company runs an agent that resolves shipment exception tickets. For each ticket, the agent loops between a model and tools for carrier status, rerouting and refunds, until it decides the ticket is resolved.
Last month a carrier API began returning errors, and the agent retried for over an hour on a single ticket. Its refund tool was also called twice for the same shipment, because a retry repeated a call that had already succeeded.
The company needs two guarantees. No run may make more than eight model calls, and a run that reaches that limit must pass the ticket to a human queue with its history. No shipment may receive a refund more than once, even when the agent retries.
Which TWO actions meet these requirements? (Choose two.)
Choose two answers.
AA. Raise the AWS Lambda timeout for the agent function to 15 minutes, so that retries against the carrier API have time to succeed before the run ends.
BB. Add a counter to the agent loop that stops the run after eight model calls, and send the ticket and its full history to a human review queue.
CC. Enable model invocation logging to Amazon CloudWatch Logs, so that the team can find runaway loops and duplicate refunds after they happen and fix them.
DD. Give the refund tool an idempotency key built from the shipment ID, store processed keys, and return the earlier result for any repeat request.
EE. Increase the model's maximum output tokens so each reply can carry the full resolution plan, which lets the agent finish a ticket in a single model call.
Show the answer and explanation
Answers: B, D
A. Wrong: A longer timeout lets the loop keep retrying for longer, which increases cost and does not stop it. It also does nothing to prevent a duplicate refund.
B. Right: A hard iteration limit in the loop is a stopping condition that the model cannot override. Handing off the ticket with its history meets the escalation requirement.
C. Wrong: Invocation logs record what happened but do not stop a loop or block a duplicate call while it runs. Detection after the fact does not meet either guarantee.
D. Right: Retries that send the same key cannot create a second refund, because the tool recognizes the request it already processed. This meets the rule that no shipment is refunded more than once.
E. Wrong: Larger output limits change how much text a reply can hold, not how many calls the loop makes. The agent would still retry and could still repeat a refund.
Explanation
A hard counter in the loop stops the agent after a fixed number of model calls and escalates the ticket with its history. An idempotency key on the refund tool makes repeated requests harmless, because the second call is recognized and rejected. Longer timeouts, invocation logs and larger output limits do not stop loops or duplicate refunds.
Want more on Agent safeguards (stopping conditions, timeouts, IAM boundaries, AgentCore Policy)? The 5 full-length practice sets have 5 more Agent safeguards (stopping conditions, timeouts, IAM boundaries, AgentCore Policy) questions, 375 in all, none of them in the free exam. One payment of $14.99, no subscription. See the practice sets →
Study Agent safeguards (stopping conditions, timeouts, IAM boundaries, AgentCore Policy)