Project 6: “The Custom Persona Generator” — Agent Configuration

Attribute	Value
File	KIRO_CLI_LEARNING_PROJECTS.md
Main Programming Language	JSON
Coolness Level	Level 3: Genuinely Clever
Business Potential	2. Micro-SaaS (Specialized Agents)
Difficulty	Level 2: Intermediate
Knowledge Area	Agent Configuration

What you’ll build: A security-auditor.json agent with read-only permissions and OWASP Top 10 in its prompt.

Why it teaches Custom Agents: You build specialized personas for specific SDLC phases.

Core challenges you’ll face:

• Configuring allowedTools.
• Injecting static resources.

Success criteria:

• The agent refuses to write files but can review code.

---

Real World Outcome

You’ll create a specialized security-auditor.json agent configuration that can analyze code for security vulnerabilities but cannot modify files. When you invoke this agent, it has the OWASP Top 10 embedded in its context and only has read access.

Example Output:

$ cat .kiro/agents/security-auditor.json
{
  "name": "Security Auditor",
  "description": "Reviews code for security vulnerabilities using OWASP Top 10 guidelines",
  "model": "claude-opus-4",
  "prompt": "You are a security auditor specializing in web application vulnerabilities. Your role is to identify security issues based on the OWASP Top 10:\n\n1. Broken Access Control\n2. Cryptographic Failures\n3. Injection\n4. Insecure Design\n5. Security Misconfiguration\n6. Vulnerable and Outdated Components\n7. Identification and Authentication Failures\n8. Software and Data Integrity Failures\n9. Security Logging and Monitoring Failures\n10. Server-Side Request Forgery (SSRF)\n\nAnalyze code for these vulnerabilities. Provide specific line numbers and remediation steps. NEVER modify code—only report findings.",
  "tools": ["read", "grep", "glob"],
  "allowedTools": ["read", "grep", "glob"],
  "resources": [
    "https://owasp.org/www-project-top-ten/"
  ]
}

$ kiro chat --agent security-auditor

Security Auditor: I'm the Security Auditor agent. I'll review your code for OWASP Top 10 vulnerabilities. I can read and analyze code but cannot modify files.

You: "Analyze src/api/auth.ts for security issues"

Security Auditor: [reads src/api/auth.ts]

**Security Audit Report**

File: src/api/auth.ts

**🔴 CRITICAL: SQL Injection (OWASP #3: Injection)**
- **Line 42:** Direct string concatenation in SQL query
```typescript
const query = `SELECT * FROM users WHERE email = '${req.body.email}'`;

• Risk: Attacker can inject malicious SQL (e.g., ' OR '1'='1)
• Fix: Use parameterized queries:

  const query = 'SELECT * FROM users WHERE email = ?';
  db.query(query, [req.body.email]);
  

🟠 HIGH: Weak Password Hashing (OWASP #2: Cryptographic Failures)

• Line 78: Using MD5 for password hashing

  const hash = crypto.createHash('md5').update(password).digest('hex');
  

• Risk: MD5 is cryptographically broken and fast to crack
• Fix: Use bcrypt with salt:

  const hash = await bcrypt.hash(password, 10);
  

🟡 MEDIUM: Missing Rate Limiting (OWASP #7: Auth Failures)

• Line 15-20: Login endpoint has no rate limiting
• Risk: Brute force attacks on user accounts
• Fix: Add express-rate-limit middleware

✅ GOOD PRACTICES FOUND:

• JWT tokens have 1-hour expiry (line 92)
• HTTPS enforcement via middleware (line 12)

---

Summary: 3 vulnerabilities found (1 critical, 1 high, 1 medium)

You: “Fix the SQL injection”

Security Auditor: I cannot modify files. I’m configured with read-only access (allowedTools: [“read”, “grep”, “glob”]).

To fix this, you should:

1. Exit this agent with /exit
2. Use the main Kiro agent or a developer agent
3. Implement the parameterized query fix I suggested above ```

The security-auditor agent enforces read-only behavior through allowedTools.

---

The Core Question You’re Answering

“How do I create specialized AI agents with specific expertise and restricted permissions for different phases of the development lifecycle?”

Before building this, understand: A single general-purpose agent can’t excel at everything. Kiro’s custom agents let you create personas with domain expertise (security, testing, documentation) and controlled permissions (read-only, write-only, specific directories). This project teaches you how to architect agent specialization.

---

Concepts You Must Understand First

Stop and research these before coding:

1. Agent Configuration Schema
   • What fields are required vs optional in agent JSON?
   • How does the prompt field differ from the name and description?
   • What’s the precedence: agent config → project config → global config?
   • Reference: Agent Configuration Reference
2. Tool Permissions
   • What’s the difference between tools (available) and allowedTools (auto-approved)?
   • How do wildcards work? (e.g., read* matches read, read_multiple)
   • What happens if you request a tool not in allowedTools?
   • Reference: Creating Custom Agents
3. Resource Injection
   • How do resources (URLs, file paths) get loaded into context?
   • What’s the limit on resource size?
   • Can resources be dynamically updated, or are they static at agent creation?
   • Reference: Agent Examples

---

Questions to Guide Your Design

Before implementing, think through these:

1. Agent Purpose
   • What specific task should this agent excel at? (security, performance, docs)
   • Should it be read-only, write-only, or full access?
   • What domain knowledge must be embedded in the prompt?
2. Permission Boundaries
   • Which tools should be allowed? (read, write, grep, shell, MCP tools)
   • Should it access the network? (web_fetch, MCP servers)
   • Should it execute code? (shell, bash)
3. Prompt Engineering
   • How do you encode expertise in the prompt field?
   • Should you include examples of good/bad patterns?
   • How do you prevent the agent from ignoring its role?

---

Thinking Exercise

Exercise: Design Agents for SDLC Phases

For a typical software development lifecycle, design 3 specialized agents:

1. Agent Name: __________________
   Purpose: __________________
   Allowed Tools: __________________
   Key Prompt Content: __________________

2. Agent Name: __________________
   Purpose: __________________
   Allowed Tools: __________________
   Key Prompt Content: __________________

3. Agent Name: __________________
   Purpose: __________________
   Allowed Tools: __________________
   Key Prompt Content: __________________

Questions while designing:

• Which phase needs write access, and which needs read-only?
• Should the testing agent be able to modify test files?
• Should the deployment agent have access to shell commands?
• How do you prevent the security agent from “fixing” code itself?

---

The Interview Questions They’ll Ask

1. “Explain the difference between the tools and allowedTools fields in a Kiro agent config.”
2. “How would you design a read-only code review agent vs a code-writing agent?”
3. “What security considerations exist when giving an agent shell access?”
4. “How do resources get injected into an agent’s context?”
5. “When would you use multiple specialized agents vs one general-purpose agent?”
6. “How would you test that an agent’s permissions are correctly enforced?”

---

Hints in Layers

Hint 1: Start with the Prompt Before configuring tools, write the prompt. Define the agent’s role, expertise, and constraints in natural language. Example: “You are a security auditor. NEVER modify code. Only report vulnerabilities.”

Hint 2: Test Permission Boundaries After creating the agent, intentionally try to violate its permissions. If it’s read-only, ask it to write a file. Verify it refuses or prompts for approval.

Hint 3: Use Resources for Static Knowledge Don’t put 10KB of OWASP guidelines in the prompt. Put them in resources as a URL or file path. This keeps the prompt clean and allows updates without changing the agent config.

Hint 4: Model Selection Matters Use claude-opus-4 for complex reasoning tasks (security analysis, architecture review). Use claude-haiku-4 for simple tasks (linting, formatting checks). This optimizes cost and speed.

---

Books That Will Help

Topic	Book	Chapter
Security best practices	“Practical Malware Analysis” by Sikorski & Honig	Ch. 1: Basic Static Techniques
Agent design patterns	“The Pragmatic Programmer” by Hunt & Thomas	Ch. 7: While You Are Coding
Permission models	“Working Effectively with Legacy Code” by Feathers	Ch. 4: The Seam Model

---

Common Pitfalls & Debugging

Problem 1: “Agent ignores its read-only role and suggests writing files”

• Why: Prompt doesn’t explicitly forbid writing; the agent sees write in available tools
• Fix: Remove write from the tools array entirely, and add to prompt: “You CANNOT modify files.”
• Quick test: Ask agent “fix this bug” and verify it refuses to write

Problem 2: “Agent requires approval for every read operation”

• Why: read is in tools but not in allowedTools
• Fix: Add "read" to allowedTools array
• Quick test: kiro chat --agent security-auditor → agent should read files without prompting

Problem 3: “Resources file is too large (>50K)”

• Why: Loaded entire OWASP documentation as a local file
• Fix: Use a URL resource instead, or extract only relevant sections
• Quick test: Check agent context usage with /context show after startup

Problem 4: “Agent config not found”

• Why: File is not in .kiro/agents/ directory or has incorrect JSON syntax
• Fix: Verify path: .kiro/agents/security-auditor.json and validate JSON with jq
• Quick test: kiro chat --agent security-auditor should load without “agent not found” error

---

Definition of Done

• Created .kiro/agents/security-auditor.json with valid JSON
• Configured allowedTools to include only ["read", "grep", "glob"]
• Wrote a detailed prompt including OWASP Top 10 guidelines
• Added relevant resources (OWASP URL or security checklist)
• Tested agent with kiro chat --agent security-auditor
• Verified agent can read and analyze code files
• Verified agent refuses or prompts when asked to write/modify files
• Agent successfully identified at least 1 security issue in sample code

---