How to Set Up Kiro for the AWS Enterprise Tenancy — Part 3: From Kiro to Production AI Agents with Bedrock, AgentCore, and Strands

From Discovery Tool to Production Platform

In Part 1 we set up Kiro in an enterprise AWS tenancy. In Part 2 we connected MCP servers and used Kiro as a discovery and documentation tool for Data Architects and Cloud Architects — querying live AWS accounts and databases through natural language.

This post moves up a layer. Kiro is excellent for augmenting a human who's still driving. The next step — building an AI system that takes actions on its own, within defined boundaries — needs a different platform underneath it. That's Amazon Bedrock for the foundation models, AgentCore for production agent infrastructure, and the Strands Agents SDK for writing the agent logic itself.

This is also where Kiro comes back into the picture — not as the thing you're building, but as the tool you use to build it.

The Three Layers, Explained Simply

Amazon Bedrock
├── Foundation Models           ← the "brain" — ~100 models from
│                                  Anthropic, OpenAI, Mistral, Google, etc.
├── Knowledge Bases             ← RAG — connects models to your documents
├── Guardrails                  ← content filtering, PII detection
└── Evaluations                 ← quality testing before go-live

Strands Agents SDK
└── Open-source framework for writing agent logic
    — define what the agent can do, what tools it has,
      how it reasons through multi-step tasks

Amazon Bedrock AgentCore
└── Production platform that runs the agent you wrote
    ├── Runtime         ← serverless execution, no infrastructure to manage
    ├── Memory          ← session and long-term context
    ├── Gateway         ← turns APIs/Lambda/MCP servers into agent tools
    ├── Identity        ← IAM-based permissions for what the agent can do
    ├── Observability   ← CloudWatch dashboards, full reasoning trace
    └── Evaluations     ← ongoing quality monitoring in production

The relationship: Bedrock provides the model. Strands gives you the code framework to define agent behaviour. AgentCore is where that code actually runs, with the security, memory, and observability a production system needs.

Decision 1: Bedrock Managed Agents vs AgentCore

This is the first fork in the road, and it's worth getting right before writing any code.

	Bedrock Managed Agents	AgentCore + Strands
Setup	Console-configured — point at a Knowledge Base, define instructions, done	You write agent code in Python using the Strands SDK
Best for	Single-purpose assistants, RAG-backed Q&A, simple workflows	Multi-step reasoning, multi-agent coordination, custom tool logic
Who maintains it	Can be a non-engineer with console access	Needs a developer comfortable with the SDK
Framework flexibility	None — AWS's opinionated agent loop	Any framework — Strands, LangGraph, CrewAI, LlamaIndex, or your own
Graduation path	Can export harness orchestration as Strands-based code later	N/A — already there

Practical guidance: start with Managed Agents if the use case is genuinely simple and the team maintaining it sits outside engineering. Go straight to AgentCore if the agent needs to call multiple internal systems, coordinate with other agents, or make decisions that need fine-grained, auditable permission control.

Setting Up Bedrock — The Foundation

Step 1 — Model Access

In the Bedrock console, navigate to Model access and request access to the foundation models you intend to use. Some models grant access instantly; others require a brief use-case justification.

Step 2 — Build a Knowledge Base (If Your Agent Needs RAG)

1. In Bedrock, navigate to Knowledge Bases → Create

2. Point it at an S3 bucket containing your source documents

3. Bedrock handles chunking and embedding automatically — select an embedding model (Amazon Titan Embeddings is the default starting point)

4. Choose a vector store — Amazon OpenSearch Serverless is the managed default, or bring your own (Pinecone, Aurora pgvector)

Step 3 — Configure Guardrails

Before any production deployment:

1. Bedrock → Guardrails → Create guardrail

2. Enable content filters (hate speech, violence, sexual content, prompt attacks) at moderate-or-higher severity

3. Enable PII detection — choose redact or block based on use case

4. Add denied topics specific to your domain

5. Apply the guardrail to both input and output independently

Step 4 — Run Evaluations Before Go-Live

Use Bedrock Evaluations to test the model or agent against a representative set of inputs before production release. This is the step most proofs-of-concept skip — and the reason many PoCs never make it to production with confidence.

Setting Up AgentCore — Where the Agent Actually Runs

Step 1 — Install the Strands Agents SDK

bash

pip install strands-agents --break-system-packages

Step 2 — Write the Agent

A minimal Strands agent looks like this:

python

from strands import Agent
from strands_tools import calculator

agent = Agent(
    model="anthropic.claude-sonnet-4-6",
    tools=[calculator],
    system_prompt="You are a cloud cost analysis assistant."
)

response = agent("What's 15% of our monthly EC2 spend if it's $4,200?")
print(response)

This runs locally first — exactly like testing a script before deploying it.

Step 3 — Scaffold for AgentCore Deployment

The AgentCore CLI (launched April 2026) generates the deployment structure as infrastructure-as-code:

bash

agentcore init my-cost-analysis-agent

This scaffolds a project with an agentcore/agentcore.json configuration file. Point the entrypoint at your agent's Python file.

Step 4 — Deploy to AgentCore Runtime

bash

agentcore deploy

This deploys your agent as a serverless AgentCore Runtime — no EC2 instances, no containers to manage manually, and full audit history of the deployment itself.

Step 5 — Connect Tools via AgentCore Gateway

Rather than hardcoding API calls into your agent, AgentCore Gateway turns your existing APIs, Lambda functions, and MCP servers into agent-callable tools with proper authentication:

Agent Code
    ↓ calls tool via Gateway
AgentCore Gateway
    ├── Lambda function    ← e.g. "get_account_cost_data"
    ├── Internal REST API  ← e.g. internal CMDB lookup
    └── MCP Server         ← e.g. AWS MCP Server, GitHub MCP Server

Outbound authorization is IAM-based by default — the Gateway service role authenticates to each target using AWS SigV4, rather than the agent holding its own long-lived credentials.

Step 6 — Configure Identity and Least Privilege

This is the control that matters most for a Security-First architecture. Define exactly what the agent's identity is permitted to do using standard IAM policy structure with the bedrock-agentcore: action prefix:

json

{
  "Effect": "Allow",
  "Action": [
    "bedrock-agentcore:InvokeAgentRuntime"
  ],
  "Resource": "arn:aws:bedrock-agentcore:ap-southeast-2:111111111111:runtime/cost-analysis-agent",
  "Condition": {
    "StringEquals": {
      "aws:PrincipalTag/Department": "FinOps"
    }
  }
}

For agents that take actions with real consequences, add an explicit deny on destructive operations regardless of what the agent's reasoning concludes:

json

{
  "Effect": "Deny",
  "Action": [
    "ec2:TerminateInstances",
    "rds:DeleteDBInstance"
  ],
  "Resource": "*",
  "Condition": {
    "StringEquals": {
      "aws:CalledVia": ["bedrock-agentcore.amazonaws.com"]
    }
  }
}

This means even if a prompt injection convinces the agent's reasoning to attempt a destructive action, the IAM layer stops it — security enforced at the infrastructure layer, not just the application layer.

Step 7 — Observability

AgentCore's built-in CloudWatch dashboards track token usage, latency, session duration, and error rates automatically. The trace viewer shows the full reasoning chain — which tools were invoked and how the model responded — which is what you actually need when diagnosing why an agent made a particular decision, not just that an error occurred.

Using Kiro to Build the Agent

This is where the series comes full circle. Kiro isn't just useful for querying your AWS environment — it's also the IDE you use to build the agent itself, and it's purpose-built for this.

The AgentCore MCP Server enables natural language development workflows between Kiro and AgentCore capabilities directly. In practice:

"Create a spec for a Strands agent that checks RDS backup
 compliance across all accounts and posts a summary to Slack
 if any database is missing a backup older than 24 hours."

Kiro generates the requirements, design, and task breakdown — then implements the Strands agent code against that spec, using the AgentCore-specific skills bundled with the Agent Toolkit so the generated code reflects current AgentCore patterns rather than outdated training data.

.kiro/specs/rds-backup-compliance-agent/
├── requirements.md   ← what counts as "compliant", alert threshold, Slack format
├── design.md         ← Strands agent structure, AgentCore Gateway tools needed,
│                        IAM permissions required
└── tasks.md          ← implementation broken into discrete steps

This is the same spec-driven discipline from Part 1 and Part 2 — applied to agent development instead of Terraform or schema work.

A Worked Example: Cross-Account Cost Anomaly Agent

Pulling the whole stack together — a practical agent a platform team might actually build:

Requirement: Detect unusual cost spikes across multiple client AWS accounts and alert before month-end invoicing surprises anyone.

Architecture:
├── Strands Agent (Python)
│   ├── Tool: get_cost_explorer_data (via AgentCore Gateway → Lambda)
│   ├── Tool: get_terraform_recent_changes (via AgentCore Gateway → GitHub MCP)
│   └── Tool: post_to_slack (via AgentCore Gateway → Lambda)
│
├── AgentCore Runtime
│   ├── Memory: 30-day rolling cost baseline per account
│   └── Identity: read-only Cost Explorer access, scoped per client account
│
├── Bedrock
│   ├── Model: cost-efficient model — this is a scheduled batch job, not
│   │           a real-time chat interaction, so latency tolerance is high
│   └── Guardrails: standard content filters, no PII concerns for cost data
│
└── Trigger: EventBridge scheduled rule — runs daily

Built using Kiro: the spec defines the anomaly threshold logic and Slack message format; Kiro implements the Strands agent and the AgentCore deployment configuration; the AgentCore CLI deploys it as infrastructure-as-code, version controlled in the same repo as the rest of the client's Terraform.

This is a genuinely production-appropriate pattern — not a chatbot, not a demo, but a scheduled agent doing a defined job with tightly scoped permissions and a full audit trail.

Governance Checklist Before Production

Carrying forward the Security-First principle from Parts 1 and 2:

Control	AgentCore / Bedrock Mechanism
Least privilege	AgentCore Identity — IAM scoped per agent, not per developer
Prompt injection protection	Bedrock Guardrails (input) + IAM deny statements (action layer)
Audit trail	CloudTrail (what happened) + AgentCore trace viewer (why)
Cost control	Tag every Bedrock invocation by use case; CloudWatch billing alarms per agent
Quality assurance	Bedrock Evaluations run against a regression test set before each model/prompt change
NZISM / NIST alignment	Cross-walk to AWS Well-Architected Generative AI Lens — most gaps are in agent identity and model versioning, not new categories

Series Summary

Part	Focus
Part 1	Enterprise account architecture — Control Tower, IAM Identity Center, Kiro profile placement
Part 2	MCP server setup — practical use cases for Data Architects/DBAs and Cloud Architects
Part 3	Production AI agents — Bedrock, AgentCore, Strands SDK, and using Kiro to build them

The thread running through all three: start with the governance and account architecture right, use Kiro as the discovery and build tool with live data rather than guesswork, and apply the same Security-First, spec-driven discipline whether you're documenting a VPC, reviewing a database schema, or deploying an autonomous agent into production.

References

Resource	URL
Amazon Bedrock	https://aws.amazon.com/bedrock
Amazon Bedrock AgentCore	https://aws.amazon.com/bedrock/agentcore
AgentCore FAQs	https://aws.amazon.com/bedrock/agentcore/faqs
AgentCore IAM Guide	https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/security_iam_service-with-iam.html
AgentCore MCP Server Deployment	https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/runtime-mcp.html
Strands Agents SDK	https://strandsagents.com
AWS Well-Architected — Generative AI Lens	https://docs.aws.amazon.com/wellarchitected/latest/generative-ai-lens/welcome.html
AWS GRC Guide for Responsible AI	https://aws.amazon.com/blogs/security/introducing-the-updated-aws-user-guide-to-governance-risk-and-compliance-for-responsible-ai-adoption

Read Part 1: How to Set Up Kiro for the AWS Enterprise Tenancy Read Part 2: MCP Servers and Real-World Use Cases