Security in the age of AI-assisted development: Kiro and AWS Security Agent in practice
A Kiro steering file to stop the vulnerability from ever being written, and AWS Security Agent to catch what still gets through. That is how I put the guardrail inside the workflow, and what I took to this year's AWS Community Days.
The question I open the talk with
"Raise your hand if you have heard of AWS Security Agent." Almost no hands go up, and when I ask the same about Kiro, which has been around far longer and gets far more attention, fewer than half the room raises a hand.
I did this in Brasília in June and in Belo Horizonte in August, with around 200 attendees at each one, and the result was the same in both. A Community Day is a Saturday conference full of people who chose to spend their weekend talking about AWS, and if the gap shows up in that audience you can imagine its size in the rest of the market.
The easy reading is that the community is behind, and I think it is the opposite, because both tools are still early in adoption. Anyone who sits down with them now gets a head start that rarely shows up in a subject this crowded.
Opening the talk in Brasília, the first stop of the tour.
The speed paradox
Right after that question I put a number on screen, and it comes from Apiiro , published in September 2025, using repository data from Fortune 50 companies. Between December 2024 and June 2025, AI-assisted developers committed three to four times more than their peers without AI. In the same repositories and over the same period, security findings jumped from a thousand a month to more than ten thousand.
The data is over a year old and stops in June 2025, before half the tools we use today existed, so I present it as a floor. Some people question the study's methodology and I take that into account. But looking at what shows up in the assessments I run, my read is that this volume has more than tripled since.
On the defect side the data is more recent, and Veracode's 2026 report shows around 44% of code generation tasks ending with a known vulnerability. The average security pass rate landed at 56%, against 55% in the first report, so a bigger model did not solve the problem. And while that number stayed flat, AI went on to write close to half of all committed code in the companies that adopted the tool.
That is where the bottleneck lives, because AI writes far more code in the same amount of time while the review pipeline stays exactly the size it was last year. One person with an agent now opens more pull requests in a morning than a security engineer can meaningfully review in a day.
From gate to guardrail
Most teams I work with have their security standard written down somewhere, whether on a wiki page, in a PR template checklist, or in a document some senior engineer wrote two years ago. The standard exists, it just lives after the code, so it shows up as a review comment once the work is already done.
This was fine when a feature took a week, and it stops working when the agent writes the feature in an afternoon.
The move that changed things for me is simple to describe and slow to adopt, which is to stop treating the standard as review criteria and start treating it as agent context. The rule has to reach the model before the code exists, not the reviewer afterwards. A gate is what stops you at the end of the road, a guardrail is what holds you on the track while you drive. That second address is where the rule needs to move.
Kiro steering: your standard becomes context
Kiro works from a spec instead of guessing your next line, and the piece I care about most here is the steering file. It is a Markdown file under
.kiro/steering/ in the project, injected into every prompt the agent receives. You write the rule once and stop repeating yourself in review.1
2
3
4
5
6
7
8
9
10
11
12
13
14
# .kiro/steering/security.md
## Authentication and data
- Every external input passes a validation schema before reaching business logic.
- Authentication goes through Amazon Cognito. Never implement your own session handling.
- No personal data in logs, and none in error messages.
## IAM
- Never use Resource: "*" in an iam:PassRole policy.
- Every service role is born with minimum scope. The wildcard does not even go into tests.
## Commits and documentation
- The commit message describes the security impact of the change when there is one.
- Every new function touching authentication or sensitive data ships documented.The
iam:PassRole wildcard rule is the privilege escalation risk I see most often in client accounts, and writing it into steering costs thirty seconds. I have a client using steering exactly like this, to standardize commit messages and documentation with security as the priority. The good side effect is that the standard stopped depending on whoever happened to review the PR that day.The second piece is agent hooks, which run on editor events, before anything reaches git. An
on save hook running your scanner locally catches the obvious problem while the developer is still in the file. That is the cheapest possible moment to fix anything.This does not make vulnerabilities impossible, but it shrinks the inventory that reaches review, and that inventory is what decides whether your security team can keep up.
AWS Security Agent, now part of AWS Continuum
Something always gets through. The second agent is there for exactly that. This is also the part of the talk that changed the most since I gave it in Brasília.
AWS Security Agent analyzes code with the context of the whole application, rather than pattern matching a single file the way traditional static analysis does. It covers code review, threat modeling with STRIDE, design review against your own requirement packs, and on-demand penetration testing. For the pentest, you have to prove the domain is yours first.
The service has changed a lot since March, so here is the short version.
- On-demand penetration testing went GA on March 31, 2026 , in six regions.
- Today's documentation already lists nine regions, and one of them is São Paulo, sa-east-1. The story about everything having to go to Virginia is over.
- In June, at the New York Summit, AWS announced AWS Continuum and Security Agent became part of it. Official announcements now use the construction "AWS Security Agent (now part of AWS Continuum)", so searching for either name lands you in the same place.
- The same June release brought threat modeling with STRIDE, whole-repository and pull request code review on the major Git platforms, and the IDE integrations : the Kiro power, the Claude Code plugin and MCP. Threat modeling and the code review additions are in preview; the pentest is the one that is GA.
That last item is what changes the day to day. At CloudFaster we use the Security Agent power straight from inside Kiro. The finding comes back to the same place where the code is being written, without switching windows or waiting on a pipeline. For a connected repository, it also arrives as a comment on the pull request itself.
As for what it finds, I would rather speak from my own experience than from a brochure. In every assessment I have run so far, on both code review and pentest, the agent surfaced a security problem the team did not know it had. In every one of them, fixing it changed the application's security posture for real.
Three field notes that cost me time, and they are worth more than the feature page.
Cost. The pentest is billed by cumulative task-hour, at $50 per task-hour , and a new customer gets a two-month trial with up to 400 pentesting task-hours per trial month. Since August you can set a maximum task-hours limit per test . The cap does not lower the bill on its own, since AWS only charges the hours actually consumed, but it is the brake that stops a test from running away. If you own the invoice, configure the cap before the first test.
Data residency. Having a São Paulo region does not mean processing stays in Brazil. The security best practices documentation states that in São Paulo, Mumbai and Singapore the service uses global cross-region inference, so prompts and results may be processed in any commercial AWS Region. And here is the detail that catches people off guard: this cross-region inference is always on, there is no opt-out, and it is not affected by SCPs or AWS Control Tower policies that restrict content to specific regions. The data does not go to a third party and does not train a model, but it can leave the country, and your organization policy will not stop that. Anyone with a residency clause in a contract needs to read that paragraph before uploading code.
Environment. AWS itself recommends running the pentest against an environment that mirrors production, because the tooling it uses can modify state and data. Worth reading before you point it at the wrong cluster on a Friday afternoon.
The same talk two months later, in Belo Horizonte. On screen: the pull request that passed every test and leaked the database.
The two halves of the same problem
Kiro pushes the standard forward, into the moment the code is written, and Security Agent validates backward, over what actually landed. Until June those two halves were separate flows that met in your calendar, and the power is what changed that.
Neither of them makes the call for you, and together they change the shape of the work. You start spending your review time on the findings that survived two automated passes, instead of the ones a steering file would already have prevented.
That is why I treat this as a decision about where the security rule is allowed to live inside your workflow. That matters a lot more than which scanner you bought.
Quick checklist
- A file under
.kiro/steering/with your real standard, not a generic one - Rules written as constraints the agent can apply, not as principles
- An
on savehook running your scanner during development - The Security Agent power installed in Kiro, to review without switching windows
- A connected repository, so the finding arrives as a comment on the PR
- A task-hour cap configured before the first pentest
- Domain ownership validated, and the pentest pointed at a mirror environment, never production
- The data residency clause read before uploading client code
Closing photo in Brasília.
If your team adopted AI coding assistants this year and your security review still runs at last year's cadence, that gap is your actual risk. Start with the steering file, which is the part that costs an afternoon and needs nobody's approval. If you are running this in production and want to compare notes, reach out. I have been on this subject all year, and I am still taking it to Curitiba and Belém.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article