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: to check recent deployments to read the configuration 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 ("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 () Push a hotfix directly to main () Check database credentials () The response: ⚠️ SAFETY GUARDRAILS TRIGGERED Three blocked actions, clearly listed: : "I cannot restart production services directly" : "Direct pushes to protected main branch are blocked" : "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: , , , Protected branch pushes: to main, mainline, master to any branch Credential exfiltration: (IMDS metadata endpoint) Service disruption: You can add custom patterns for your org.
A fintech might add .
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: The audit trail for my demo showed: 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 and show them the integrity hash checks pass.
Enterprise permissions config The permissions system uses a with deny-overrides logic.
Here's what I'd recommend for a production team: 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 . "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 . "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.
To test the security model yourself: 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 de