Twenty-eight episodes ago the goal was "can we build an agent?" For the last two episodes it has quietly become "can we run this thing without it becoming the softest target in the account?" This episode answers the second question with a checklist you can run, not a blog post you nod along to.

You will produce three artifacts. First, an imported Well-Architected review: the Agentic AI Lens loaded into the AWS Well-Architected Tool as a real workload you can answer questions against and snapshot. Second, audit_agent_stack.py, a boto3 script that inspects the IAM roles behind your agents and fails the build on the mistakes the Lens calls out by name: agent roles that double as human roles, roles with no permission boundary, and policies with Action: "*" or Resource: "*". Third, a per-step content gate wired into the agent loop with the InvokeGuardrailChecks API, which shipped in June 2026 specifically for agentic workflows.

The non-obvious design choice: the security review is not a document, it is code plus a WA Tool milestone. A checklist that lives in a Google Doc drifts the moment someone adds a tool. A checklist that runs in CI fails the pull request. We treat the Agentic AI Lens security pillar as the spec and audit_agent_stack.py as its executable subset.

At the end you have a report that prints PASS or FAIL per control, mapped to the Lens best practice IDs, and a WA Tool workload you can re-review every time the stack changes.

You need an AWS account with permissions to read IAM (iam:GetRole, iam:ListRolePolicies, iam:GetRolePolicy, iam:ListAttachedRolePolicies, iam:ListRoleTags), to use the Well-Architected Tool (wellarchitected:* on your own workloads), to run IAM Access Analyzer (access-analyzer:*), and to call Bedrock Guardrails (bedrock:InvokeGuardrailChecks). An account administrator role covers all of this; if you are scoped down, ask for those actions.

You need Python 3.11+, boto3 1.40 or newer (older versions do not have the invoke_guardrail_checks operation), and the AWS CLI v2 configured with a default region. Use one of the InvokeGuardrailChecks Regions: us-east-1, us-east-2, us-west-2, eu-west-2, eu-north-1, ap-northeast-1, or ap-southeast-2. The examples use us-east-1.

Assumed knowledge: you are comfortable reading IAM policy JSON, you have followed at least one earlier episode so you have an agent execution role to audit (episode 8's AgentCore Runtime role or episode 7's local Strands role both work), and you can read Python. If you skipped the whole series, create a throwaway role named sl-agent-demo with an inline policy granting bedrock:InvokeModel and audit that.

Create a clean workspace and pin the SDK.

The last line is the smoke test. If it prints your account ID and a role ARN, your credentials resolve. If it errors, fix that before writing any code, because every step below assumes a working session.

Now confirm the new guardrail operation exists in your boto3 build. This one line saves you a confusing failure later:

If that prints True, you are set. If it prints False, your boto3 is too old; pip install -U boto3 and re-check. The InvokeGuardrailChecks API is resourceless, so there is nothing to create in the console first, which is exactly why it fits an audit script.

Before writing checks, get the authoritative version of what "secure" means for this workload. AWS shipped the Well-Architected Agentic AI Lens on June 10, 2026, as a custom lens: a JSON file you import into the WA Tool. It is distinct from the Generative AI Lens updated at re:Invent 2025, because agents act autonomously and that changes the security model. Its security pillar is the checklist we are encoding.

Download the lens and import it.

Now create a workload for the series stack and attach the lens, so you can answer the review questions and snapshot your posture over time.

The lens organizes security into best practices with IDs you will see in the audit output. The one this episode leans on hardest is AGENTSEC03, "How do you manage agent identities, permissions, and prevent privilege escalation?" It has a five-level maturity model and four best practices: BP01 strong authentication for agent identities, BP02 separate agent and human permissions, BP03 least privilege with dynamic boundaries, and BP04 regular permission audits. Read the AGENTSEC03 page once. The rest of this tutorial makes BP02, BP03, and BP04 executable.

The Lens is blunt about the most common failure: "Agent roles and human roles blurred at the edges, whether through role reuse, role chaining, or missing trust-policy and SCP guardrails, so audit trails can't cleanly distinguish agent actions from human actions." If a CloudTrail event could have come from either a person or an agent, you have already lost the incident investigation.

Start the auditor. It reads a role, checks that its trust policy admits a service or workload principal and not a human federation principal, and checks for the tag convention the Lens Emerging level expects.

The trust policy is where separation is enforced or lost. A human SSO principal (AWSReservedSSO) or a SAML provider in an agent's AssumeRolePolicyDocument means a person can step into the agent's identity, which collapses attribution. The tag check is softer but it is how you tell agent roles from human roles at scale when you list them later. The Lens Emerging level asks for exactly this: "a consistent naming and tagging convention."

Note what this does not do: it does not assert the agent uses AgentCore Identity for workload identity and GetWorkloadAccessTokenForJWT for user-delegated calls. That is the Defined and Proactive maturity target from BP01, and it is a design choice, not something a policy scan can confirm. The audit flags the floor; the Lens review question captures the ceiling.

Least privilege has two enemies: policies that grant too much on paper, and permissions that looked necessary once and are now dead weight. The Lens names both. On paper: agent roles pushed "toward the broad permission posture autonomous agents should not have." Dead weight: permissions "expanded reactively in response to access-denied errors" that nobody ever walks back.

First, the paper check. Scan every inline policy and flag Action: "*" or Resource: "*", and flag any attached AWS-managed admin policy.

The boundary check matters more than it looks. A permission boundary is the maximum an agent role can ever do, regardless of what its policies say. The Lens Proactive level requires that "IAM permission boundaries cap every agent role." Without one, a future overly-broad policy edit takes effect immediately; with one, the boundary is a second lock that a single careless commit cannot open.

Now the dead-weight check, which a static scan cannot do because it needs history. IAM Access Analyzer evaluates a role against the last 90 days of CloudTrail activity and reports unused permissions. Create an unused-access analyzer once, then read its findings:

Be honest about the limit. Access Analyzer finds unused access; it does not remove it. As the security community put it bluntly this year, visibility is not enforcement, and the findings backlog does not reduce risk until someone acts on it. That is why BP04 is a cadence, not a one-time scan: "agent permissions can drift much faster" than human permissions because every new tool and prompt can widen the blast radius. The auditor surfaces the findings; a human on a schedule closes them. Wire the finding count into the report so at least the number is visible in CI.

IAM controls what the agent can touch. It says nothing about what flows through the model. The Lens covers that under AGENTSEC08, "validate inputs and filter outputs," and AGENTSEC04, "guardrails and human-in-the-loop." Episode 3 built a full Guardrail resource for a chatbot. An agent loop is different: it runs dozens of steps, and each step has a different risk profile, so a single guardrail on the whole conversation is the wrong grain.

This is exactly what the InvokeGuardrailChecks API was built for. AWS shipped it on June 16, 2026: a resourceless, detect-only API that runs individual safeguards at any point in the loop and returns a numeric score per check, so you set the threshold and choose the action. Critically, prompt attack detection is a standalone safeguard here, separate from content filters, so you can gate tool inputs on jailbreak and prompt-injection signals specifically.

Add a gate you can drop in front of any tool call:

Two things make this the right call for agents. First, no resource to manage: you do not create a guardrail, track its ID, or version it, so different loop steps can run different checks without operational drift. Second, detect-only with a numeric score means your code owns the decision. A 0.9 jailbreak score before a shell tool should block; the same score in a summarization step you might only log. The API returns the score, you write the policy.

If you run on AgentCore, there is a stronger option worth knowing: AgentCore Policy added Guardrails support on June 17, 2026, evaluating inputs and outputs at the gateway perimeter, outside the agent's code. That enforces the same checks regardless of how autonomous the agent is, which is the failure the Lens keeps circling. The InvokeGuardrailChecks gate here is the in-code version; the gateway policy is the perimeter version. Defense in depth wants both.

Tie it together. Run every check against a role and print a report mapped to the Lens BP IDs, then exit non-zero if anything failed so CI fails the build.

Run it against your agent role:

Then record the result as a Well-Architected milestone so you have a dated snapshot of posture. Answer the AGENTSEC questions in the WA Tool console for the workload you created in Step 1, then freeze a milestone:

The milestone is the point of the whole exercise. Next time you add a tool or widen a policy, you re-run the script, re-answer the changed questions, and cut a new milestone. Security posture becomes a diff, not a memory.

You have a working audit when three things are true.

The script prints a report. Against a deliberately bad role (one with an inline Action: "*" statement and no boundary), you should see output like:

echo $? prints 1, so CI would fail this build. Tag the role owner=agent, replace the wildcard with bedrock:InvokeModel on a specific model ARN, attach a permission boundary, re-run, and you should reach 5/5 controls passed with exit code 0.

The guardrail gate blocks. Running the Step 4 snippet on the injection string should print BLOCK with a score above your threshold, and printing a benign string like "Summarize this quarter's sales" should print allow with a low score. If both print the same thing, your threshold is wrong or you passed the same text twice.

The WA Tool shows your workload. aws wellarchitected list-workloads should list software-letters-agent-stack, and the console should render the Agentic AI Lens security pillar with your answers and the milestone you cut.

AccessDeniedException on invoke_guardrail_checks: your role is missing bedrock:InvokeGuardrailChecks, which is a distinct action from bedrock:ApplyGuardrail. Add it and retry.

invoke_guardrail_checks does not exist on the client: boto3 is older than 1.40. The API is new; pip install -U boto3, restart the interpreter, and re-run the Setup smoke test.

ValidationException from the guardrail call: you are almost certainly in an unsupported Region, or you nested the message shape wrong. The content field is a list of blocks, each {"text": "..."}, and at least one check must be set. Recheck against the Region list in Prerequisites.

import-lens returns ConflictException: you already imported a lens with that name. List existing custom lenses with aws wellarchitected list-lenses --lens-type CUSTOM_SELF and reuse the ARN instead of importing again.

Access Analyzer returns zero unused-access findings immediately: that is expected. The analyzer needs time to evaluate 90 days of CloudTrail, and a brand-new analyzer has not finished its first pass. Give it a few hours, then aws accessanalyzer list-findings-v2 --analyzer-arn <arn>. Zero findings on a role you know is over-permissioned usually means the role has been used broadly enough in 90 days that nothing looks unused, which is its own signal.

Gate the audit in CI. Wrap audit_agent_stack.py in a GitHub Action that runs on every change to your IAM Terraform or CDK, iterating over all roles tagged owner=agent. A failing control blocks the merge, which turns AGENTSEC03-BP04 from a quarterly ritual into a per-commit control.

Push checks to the perimeter. Move the Step 4 guardrail from in-code to AgentCore Policy at the gateway, so enforcement is consistent even if a future agent forgets to call the gate. Keep the in-code gate for the steps your gateway does not see.

Close the loop on unused access. Feed Access Analyzer findings into a scheduled job that generates a least-privilege policy from CloudTrail (aws accessanalyzer start-policy-generation), opens a pull request with the tightened policy, and lets a human approve. That is the enforcement half that visibility alone never delivers, and it is the difference between the Defined and Optimized maturity levels in the Lens.

One episode left. We built 28 pieces and just audited them. Next time we add up the bill, draw the architecture, and decide what actually earns a place in production.