Using Kiro to Implement the AWS Well-Architected Agentic AI Lens

Why best practices don't stick

A recommendation like "implement tool authorization with least-privilege scoping" is unambiguous. But without enforcement at authoring time, it depends on every developer remembering to apply it to every feature, in every sprint, forever.

Six pillars, adapted for agents

The Agentic AI Lens extends the Well-Architected Framework for systems that reason, act autonomously, behave stochastically, collaborate, and remember.

Four mechanisms that enforce the Lens

Each maps directly onto a control the Lens asks for. Examples target Kiro CLI 3.0 / IDE 1.0.

What the controls actually look like

Three representative artifacts: a steering standard, a blocking hook, and a least-privilege config that pauses for a human on risky writes.

# Security Guardrails

## Tool Authorization
- Agents MUST NOT be granted blanket access to all tools.
- Mutating operations (write, delete, update) MUST require human approval
  (enforce with an `ask` effect in the permissions model, not prose alone).
- Tool invocations MUST propagate user identity context.

## Prompt Injection Defense (defense-in-depth)
- Treat input delimiting as ONE layer, not the primary control.
- Never embed raw user input directly into tool invocation parameters.
- The agent itself is NOT a trust boundary: validate memory reads,
  tool I/O, and agent-to-agent messages alike.

{
  "version": "v1",
  "hooks": [{
    "name": "scan-credentials",
    "trigger": "PreToolUse",
    "matcher": "write",
    "action": { "type": "command",
      "command": "bash .kiro/scripts/scan-credentials.sh" },
    "timeout": 15,
    "enabled": true
  }]
}

{
  "name": "customer-service-agent",
  "tools": ["read", "write", "shell"],
  "permissions": { "rules": [
    { "capability":"fs_read",  "match":["src/**"],             "effect":"allow" },
    { "capability":"fs_read",  "match":[".env","secrets/**"], "effect":"deny"  },
    { "capability":"fs_write", "match":["src/**"],             "effect":"allow" },
    { "capability":"fs_write", "match":["migrations/**"],      "effect":"ask"   },
    { "capability":"shell",    "match":["rm -rf*","sudo *"],  "effect":"deny"  }
  ]}
}

Pillar → Lens best practice → Kiro control → runtime

Leaf best-practice IDs are from the Lens's own Appendix A (41 questions, 150 practices). The priority column carries the Lens's own risk rating — encode the High-rated controls first.

Best practices encoded, by pillar

The practices this session wires into Kiro, split by the Lens's own risk rating. Most are High — the handful of Mediums sit in Reliability, Cost, and Sustainability. Start where the bars are tallest and darkest.

Counts reflect the leaf best practices referenced in the mapping matrix above, rated per Lens Appendix A. Not the full 150-practice set.

Kiro is one layer of a closed loop

Kiro owns author-time. The Lens spans the whole lifecycle — and the layers reinforce each other.

↺ Build in Kiro → enforce at runtime → detect in ops → feed fixes back into Kiro.

Each Kiro standard has a runtime home in AgentCore

The standard you write once in Kiro is enforced at runtime by a specific service — that's what makes the loop genuinely closed rather than aspirational.

Building a Lens-compliant agent from scratch

The demo arc — a customer-service agent, end to end in Kiro.

Three things to remember