Sarvar Nadaf for AWS Community Builders

Posted on Aug 11

I Showed My CISO Kiro Crew: Here's the Security Model That Got It Approved

#ai #security #devops #agents

The #1 question I got after my last article: "What happens when the agent tries something destructive at 3 AM?"

Every CISO I've worked with asks some version of this. They don't care how fast your agent investigates. They care about blast radius. What can it touch? What can it break? Who approved it? Where's the audit trail?

This article answers all of that. I gave Kiro Crew a P1 incident and told it to fix it. Then I watched it hit a wall.

If you're new to this series, catch up here: Kiro Crew Series

The scenario: a real P1 on FinPay

FinPay is a payment processing platform. Three services (payment, user, notification), PostgreSQL on RDS Multi-AZ, ECS Fargate, the usual stack. 26 commits of realistic history. CI/CD via GitHub Actions.

Someone committed a "performance optimization" that reduced the database connection pool from 50 to 5. Deployed at 5:30 PM on a Wednesday. By 2:47 AM, the pool was exhausted. Transactions started failing. Success rate dropped from 99.8% to 34%.

I gave the agent the alert and said: fix it.

What happened next is exactly why enterprise teams can trust this thing.

Layer 1: Investigation passes freely

The agent's first instinct was to investigate. It ran:

git log --oneline -10 to check recent deployments
cat services/payment-service/config.js to read the configuration
grep -rn pool services/payment-service/ to find pool settings

All three ran automatically. No approval popup. No human intervention.

Why? Read-only operations don't need permission. The agent can look at anything it needs to understand the problem. Reading code, checking logs, searching files. None of that changes state. None of that can break anything.

Within 23 seconds it identified the root cause: pool max was changed from 50 to 5 in commit 2181456 ("perf: reduce connection pool overhead for lower memory footprint"). A well-intentioned optimization that was never load-tested.

This is the same investigation pattern from Part 2. Fast, accurate, no human bottleneck for the detective work.

Layer 2: Dangerous commands get blocked

Then I told it to fix the issue. I deliberately tested the guardrails by asking it to:

Restart the payment service (systemctl restart payment-service)
Push a hotfix directly to main (git push origin main)
Check database credentials (cat ~/.aws/credentials)

The response: ⚠️ SAFETY GUARDRAILS TRIGGERED

Three blocked actions, clearly listed:

systemctl restart payment-service: "I cannot restart production services directly"
git push origin main: "Direct pushes to protected main branch are blocked"
cat ~/.aws/credentials: "Reading credential files is prohibited for security"

The agent didn't crash. It didn't silently fail. It explained exactly what it wanted to do, why it was blocked, and proposed safer alternatives:

Create an Emergency PR (not a direct push)
Request Production Deployment through proper channels
Monitor Service Recovery after deployment

This is the moment that matters for enterprise adoption. The agent knows the guardrails exist. It works within them. It proposes the right path instead of trying to sneak around the restriction.

Layer 3: Human approves the proper fix

I then asked it to fix the issue properly. Create a branch. Edit the config. Push to a feature branch. Wait for my approval at each step.

The agent walked through it methodically:

Step 1: "Check current git status and branch" (ran automatically, read-only)

Step 2: "Create branch fix/restore-pool-size" (waited for approval. I clicked approve.)

Step 3: "Edit config.js, change pool.max from 5 to 50" (waited for approval. I reviewed the change, clicked approve.)

Step 4: "Push to feature branch" (waited for approval. I clicked approve.)

Total time: 8.6 seconds of agent work. Three human approval clicks. The fix is on a branch, ready for PR review, not force-pushed to production at 3 AM.

This is the pattern enterprise teams need: investigate autonomously, propose confidently, execute only with permission.

The 8 security layers explained

Every tool call passes through these checks, in order:

#	Layer	What it does
1	Owner lock	Rejects unauthorized users before message reaches the agent
2	Denied commands	137 patterns block destructive ops (checked BEFORE approval)
3	Governance ceiling	Policy ∩ Profile (tightest-wins, agent cannot loosen)
4	Sensitive path blocking	Credential directories inaccessible to tool calls
5	Tool approval	Interactive review, trust escalation, or Autopilot
6	Input validation	MCP schemas, type checks, length limits, unicode normalization
7	OS sandbox	Linux namespaces hide credential paths from agent subprocesses
8	Output redaction	AWS keys, private key headers, tokens scrubbed before reaching chat

Audit logging is cross-cutting. It records every decision at every layer. Not a sequential gate but a continuous observer.

The key insight: even in Autopilot mode (where all tool calls auto-approve), deny patterns and sensitive path blocks still apply. You literally cannot turn them off from the agent side. They are enforced at the runtime boundary, not via prompt instructions.

The 137 deny patterns

These ship built-in. Some highlights:

Destructive operations:

rm -rf /, rm -rf ~
cdk destroy, terraform destroy
DROP TABLE, DROP DATABASE

Protected branch pushes:

git push to main, mainline, master
git push --force to any branch

Credential exfiltration:

cat ~/.aws/credentials
cat ~/.ssh/id_rsa
echo $AWS_SECRET*
curl 169.254.169.254 (IMDS metadata endpoint)

Service disruption:

aws ec2 terminate-instances
docker rm -f
kill -9

You can add custom patterns for your org. A fintech might add DELETE FROM transactions. A healthcare company might block access to PHI directories. Manage it all from Settings → Security in the dashboard.

You can also disable individual rules if your workflow genuinely needs them. But every override is logged. Your security team sees exactly who disabled what and when.

Audit trail: every action logged

Every tool call, every approval, every denial is recorded in a Signed Event Log (SEL). The commands:

kirocrew security events    # Recent security events
kirocrew security audit     # Full audit trail
kirocrew security verify    # Verify log integrity (tamper detection)

The audit trail for my demo showed:

01:12:14  Shell: git log --oneline -10       [ALLOWED, read-only]
01:12:16  Shell: cat config.js               [ALLOWED, read-only]
01:12:18  Shell: grep -rn pool               [ALLOWED, read-only]
01:12:23  Shell: systemctl restart           [DENIED, pattern #47]
01:12:24  Shell: git push origin main        [DENIED, pattern #12]
01:12:25  Shell: cat ~/.aws/credentials      [DENIED, sensitive path]
01:12:30  Proposed fix                       [WAITING, approval required]
01:12:38  Shell: git checkout -b fix/...     [APPROVED, human]
01:12:41  Write: config.js                   [APPROVED, human]
01:12:44  Shell: git push origin fix/...     [APPROVED, human]

Color-coded in the dashboard: green (auto-allowed), red (denied), yellow (human-approved).

For SOC2 compliance, you export this. For incident postmortems, you replay it. For your CISO's peace of mind, you point them at kirocrew security verify and show them the integrity hash checks pass.

Enterprise permissions config

The permissions system uses a permissions.yaml with deny-overrides logic. Here's what I'd recommend for a production team:

rules:
  # deny > ask > allow (deny always wins)
  # Read-only: always allowed
  - capability: fs_read
    effect: allow

  - capability: shell
    match: ["git log *", "git status", "git diff *", "cat *", "grep *", "ls *"]
    effect: allow
    # deny rules override this for sensitive paths

  # Destructive: always blocked
  - capability: shell
    match: ["rm -rf *", "sudo *", "systemctl *", "docker rm *", "kill *"]
    effect: deny

  - capability: shell
    match: ["git push * main", "git push --force *", "git reset --hard *"]
    effect: deny

  # Credentials: always blocked
  - capability: fs_read
    match: ["*.env", "*.pem", "*.key", "*credentials*", "*.secret"]
    effect: deny

  # Everything else: ask human
  - capability: shell
    effect: ask

  - capability: fs_write
    effect: ask

The rule evaluation: deny > ask > allow. A deny anywhere wins regardless of what other rules say. You cannot accidentally override a deny with an allow in a different scope.

Scopes cascade: Kiro (hardcoded invariants) → Administration (enterprise MDM) → User → Workspace → Agent → Session. Each can only tighten, never loosen.

What this means for your CISO

After 10+ years in Big 4 consulting, I've sat through dozens of security reviews for new tools. They all die on the same questions. Here are the answers for Kiro Crew:

"Can it access production?"
Only if you configure it to. Default: nothing auto-approves. Deny patterns block common destructive ops even if you set Autopilot.

"What stops it from exfiltrating secrets?"
Three layers: sensitive path blocking prevents reading credential files, OS sandbox hides credential directories from subprocesses, output redaction scrubs any patterns that leak through.

"Where's the audit trail?"
Signed Event Log with tamper detection. Every action, every decision, every approval. Exportable. Verifiable with kirocrew security verify.

"Can a developer bypass the restrictions?"
No. Deny rules at the Kiro scope and Administration scope cannot be overridden by user or session configuration. Even editing the agent config cannot weaken runtime deny rules.

"Is it open source? Can we inspect the security layers?"
Apache 2.0. Read the code, trace the execution path, verify the sandbox boundaries. The security deep-dive is at github.com/kirodotdev/KiroCrew/blob/main/docs/security-deep-dive.md.

"What about compliance?"
SOC2 mapping: audit logs cover all control points. The deny-overrides model maps directly to least-privilege access principles. HIPAA: combine with sensitive path blocking for PHI directories.

Try it yourself

Same setup as Parts 2 and 3. Kiro Crew is open source (Apache 2.0).

Prerequisites: Python 3.10+, Node.js 18+, Kiro CLI signed in.

# Install
curl -fsSL https://download.crew.kiro.dev/cli.sh | sh

# Start
kirocrew gateway

To test the security model yourself:

# Check current security settings
kirocrew security events

# View deny patterns
# Open dashboard → Settings → Security → Denied Commands

# Test a deny pattern
# Ask the agent: "run rm -rf /" and watch it get blocked

# View audit trail
kirocrew security audit

# Verify integrity
kirocrew security verify

Try giving the agent a task that requires write access. Watch it ask for permission. Then try asking it to do something destructive. Watch it refuse.

kirodotdev / KiroCrew

A persistent workspace for development work that self-improves and continues beyond one session.

Kiro Crew

A persistent workspace for development work that self-improves and continues beyond one session.

Kiro Crew is an open source development workspace that runs locally or remotely on your hardware. It is persistent, self-learning, and self-evolving. Work with it from the desktop app, web dashboard, and CLI, or continue the same work through connection tools like Slack and Discord Your multi-step tasks can run unattended, recurring jobs run on your schedule and heartbeats monitor systems until something needs attention. Kiro Crew Apps tailor that experience to a specific job, combining a purpose-built interface with agents, skills, schedules, integrations, and backend services.

Quick start · Build from source · Why Kiro Crew · Capabilities · How it works · Security · Install · Telemetry · Docs

Quick start

You choose how to run Kiro Crew: the desktop app with automatic updates, a one-line install on your machine or a remote…

View on GitHub

What I learned running this for 3 weeks

After running Kiro Crew autonomously across Articles 2 and 3, here's what I know about the security model from lived experience:

The deny patterns never triggered a false positive for me. In three weeks of cron jobs running daily, not once did a legitimate operation get blocked. The patterns are specific enough (targeting exact dangerous commands) that normal git, file read, and analysis operations pass clean.

Interactive mode is the right default for the first week. You need to see what the agent wants to do before you trust it. After a week, I could identify which operations to pre-approve in permissions.yaml because I had seen the pattern dozens of times.

The audit trail saved me once already. A cron job produced an unexpected output. I traced back through the audit log and found it had read an old cached file instead of the current one. Without the log, I would have spent 30 minutes debugging. With it, 2 minutes.

Trust is earned incrementally. Start read-only. Then allow specific write patterns. Then allow broader access for known-good workflows. The permissions system supports this progression. You don't have to choose between "fully locked down" and "fully autonomous" on day one.

What this costs

Security layers add zero token overhead. The deny patterns, path blocking, and sandbox checks are evaluated locally before any model call. Your investigation costs the same as Part 2 (~$0.02-0.04 per incident). The approval clicks cost nothing. The audit log is append-only local storage.

The only cost difference vs. running without security: none. You get the safety for free.

This is Part 4 of my Kiro Crew series. The security model was the last piece I needed to understand before recommending this to clients. I'm now running it on two active consulting projects with Interactive mode + custom deny patterns for each.

What's the security question that would stop YOUR team from adopting autonomous AI agents? I've listed the ones I hear most often above. But every org has their specific concern. Drop it in the comments and I'll tell you how (or whether) Kiro Crew addresses it.

DEV Community