Level 300 Some time ago we created a blog showing the capabilities of AI DLC and SDD to create quick and efficient prototypes as a MVP, the results were amazing, however, we omitted something: DevSecOps best practices and CICD for the workload. The prototype was built with a serverless framework and modern cloud-native application patterns. However, moving from a working MVP to a production-ready solution requires stronger alignment with DevSecOps, CI/CD, and operational excellence. That transition leaves several important questions open: Security posture • What security vulnerabilities exist in the solution? • Is the platform ready to withstand common web attacks? Code quality and production readiness • What is the overall quality of the code? • Is this truly an example of an enterprise-ready solution? Cloud compliance and misconfiguration risk • Which cloud security compliance gaps still need to be addressed? • Are there misconfigurations that could create operational or security risk? The other side of this challenge is organizational readiness. Many companies are enabling development teams with assistants such as Kiro, Claude, Cursor, and similar tools. However, without a mature process to review, scan, govern, and manage code at scale, these tools can introduce high costs, expand security risks, and growing technical debt. For the Agentic AI era, DevSecOps maturity is no longer optional. A secure software development lifecycle, policy-driven development, and zero-trust principles must become core operating requirements rather than afterthoughts. Open loop – Starter point a classical DevSecOps CICD system Suppose that the company already has a continuous integration and delivery framework and tools for that kind of workload with classical tools, in terms of maturity level and L3 Defined and Managed here we have Security gates integrated in CI/CD; SAST/SCA/secrets/IaC; centralized findings; quality gates. The maturity model we use We measure against a five-level DevSecOps maturity model. The levels are cumulative — each assumes the previous. Level Name Characteristic L1 Initial Manual builds/deploys; security is a late, manual gate (if any). L2 Repeatable Scripted CD; some automated tests; ad-hoc scanning. L3 Defined / Managed Security gates integrated in CI/CD; SAST/SCA/secrets/IaC; centralized findings; quality gates. L4 Agent-Integrated Pipelines dispatch agents to remediate; findings become PRs; developers review instead of investigate; feedback loops close. L5 Autonomous / Self-Healing Agents act on production/runtime signals with policy-bounded autonomy; the system proposes and validates its own improvements. Solid DevSecOps Level 3 Here is what is genuinely in place. Most organizations never achieve this. Delivery • Two independent, path-filtered CI/CD pipelines — backend (CDK/Lambda) and frontend (React/S3/CloudFront), separated because their lifecycles differ. o Backend: backend-{development,staging,production}.yml o Frontend: frontend-{development,staging,production}.yml • Reusable workflows for security scanning and deployment per component. • Environment promotion: dev → staging (on success) → production (on release). • OIDC hub/spoke AWS auth — no long-lived cloud credentials in CI. Security gates (the DevSecOps core) Category Tool Where Secret scanning gitleaks + git-secrets every pipeline SAST Semgrep + SonarQube sast job, per component SCA + SBOM Trivy → CycloneDX → Dependency-Track sca job, per component IaC / config thothctl (checkov, trivy) backend iac job Findings aggregation SecObserve gate job Quality gate SonarQube "Athleon Industry Standard" (Clean-as-You-Code) sast job Per-component SonarQube projects: athleon-backend, athleon-frontend, both on a Clean-as-You-Code quality gate (0 new issues, ≥80% new coverage, ≤3% new duplication, A ratings, 100% new hotspots reviewed). SBOMs published to Dependency-Track per environment (athleon-backend-<env>, athleon-frontend-<env>), CycloneDX normalized to the version DT accepts. All scanner findings imported into SecObserve for centralized triage. Kiro adoption (the differentiator) The company enables the AI adoption for devs centric on Kiro adoption (the differentiator) Spec-driven development is an established muscle: six specs under .kiro/specs/ with requirements / design / tasks. Steering docs (.kiro/steering/product.md, structure.md, tech.md) encode product and architecture context for the agent. One remediation sub-agent (.kiro/agents/sonar-fixer.json) wired to the official SonarQube MCP server. MCP configured for Kiro CLI and IDE (.kiro/settings/mcp.json). At this point the hard part is done: the gates, the aggregation, the quality bar, and — crucially — a team fluent in Kiro's spec-driven workflow. The next level is not more tools. It's connecting the tools we have to the agents we have, so the pipeline stops reporting problems to humans and starts handing humans review-ready fixes. The number of findings was significant: Also, github security and quality report 344 issues The devs could manually interact with agent and sonar to improve the code and fix the issues, however, is a manual approach. Running the sonarfixer agent that uses the MCP tools from shell interactive: kiro-cli chat --agent sonar-fixer "Fix the top criticals on athleon-backend" Using the MCP and agent: { "name": "sonar-fixer", "description": "SonarQube remediation specialist for Athleon - queries SonarQube via MCP and fixes code quality, reliability, and security issues following Clean-as-You-Code.", "prompt": "You are the SonarQube remediation specialist for the Athleon platform (multi-tenant calisthenics competition management: AWS CDK, Node.js Lambda, React/Vite frontend). Your job is to reduce SonarQube findings safely and systematically.\n\nProject key: athleon. SonarQube Server: http://sonar.devsecops.lan.\n\nCurrent baseline (improve, do not regress): Security rating D (271 issues), Reliability E (~1.2k), Maintainability A (~2k), Coverage 0-4%, Duplications ~21.7%. The active quality gate 'Athleon Industry Standard' enforces Clean-as-You-Code on NEW code (0 new issues, >=80% new coverage, <=3% new duplication, A ratings, 100% new hotspots reviewed).\n\nWORKING PRINCIPLES:\n1. Use the SonarQube MCP tools to fetch real issues - never guess. Prioritize: (a) BLOCKER/CRITICAL security & reliability first, (b) then high-impact maintainability, (c) then duplication.\n2. Fix in small, reviewable batches grouped by rule or file. One rule family per change set.\n3. Before editing, read the surrounding code and the project's steering docs (.kiro/steering/) to match conventions. Follow existing patterns (shared layer utils, DDD bounded contexts, EventBridge cross-domain comms - never direct cross-domain imports).\n4. For every fix: explain the rule, why it fired, and the fix. Preserve behavior. Do NOT introduce new dependencies without asking.\n5. Add or update tests for any behavior you touch (vitest). Raising coverage on changed files helps the new-code gate.\n6. Security issues: apply secure patterns (input validation, parameterized queries, no hardcoded secrets, least privilege). Never weaken auth/RBAC.\n7. Verify after each batch: run the relevant vitest suite and, if possible, re-check the issue in SonarQube.\n8. NEVER mark issues as false-positive/won't-fix in SonarQube without explicit human approval.\n9. Respect the safety guardrails: no destructive git ops, no production changes, confirm high-impact actions.\n\nWORKFLOW per session:\n- Ask which scope to work on (a domain, a file, a rule, or 'top criticals') if not specified.\n- Query SonarQube for that scope. Present a short prioritized plan.\n- Implement the highest-value batch. Run tests. Summarize what changed and the expected SonarQube impact.\n- Repeat or hand back for review.", "mcpServers": { "sonarqube": { "command": "docker", "args": [ "run", "--init", "--pull=always", "-i", "--rm", "--network=host", "-e", "SONARQUBE_TOKEN", "-e", "SONARQUBE_URL", "-e", "SONARQUBE_PROJECT_KEY", "-v", "${workspaceFolder}/.kiro/.sonar-mcp-storage:/app/storage", "-v", "${workspaceFolder}:/app/mcp-workspace:ro", "sonarsource/sonarqube-mcp" ], "env": { "SONARQUBE_TOKEN": "REPLACE_WITH_SONARQUBE_USER_TOKEN", "SONARQUBE_URL": "http://sonar.devsecops.lan", "SONARQUBE_PROJECT_KEY": "athleon-backend" }, "autoApprove": [], "disabled": false } }, "tools": [ "fs_read", "fs_write", "execute_bash", "@sonarqube" ], "allowedTools": [ "fs_read", "@sonarqube" ], "toolsSettings": { "execute_bash": { "allowedCommands": [ "npx vitest*", "npm test*", "npm run test*" ] } } } For example: At this stage, the key question becomes: how can DevSecOps teams evolve the existing platform into an agent-integrated DevSecOps model? The Level 4 Vision: Agent-Integrated DevSecOps Instead of simply alerting humans to problems, the pipeline should deliver review-ready fixes. Today, the developer workflow for security or quality finding typically looks like this: > pipeline fails gate → developer gets notified → opens SonarQube / SecObserve / Dependency-Track to understand it → context-switches into the IDE → reproduces, investigates, fixes → writes tests → opens PR That's minutes-to-hours of human context switching per finding, and it scales linearly with the number of findings. It is the single biggest drag on time-to-market for a team that already has good gates. The Level 4 loop: pipeline finding issue → dispatches the right agent (headless Kiro CLI, using an existing sub-agent) → agent reads the finding via MCP, fixes it, writes/updates tests, runs them → agent opens a PR with an explanation → developer REVIEWS the PR (approve / request changes) Humans are still in the loop — but at the review step, which is where human judgment is most valuable and least repetitive. This is the core TTM (Time to Marker) lever. What "closing the loop" requires Four connections must exist that don’t exist today: Trigger → Agent A pipeline event (failed quality gate, new critical vuln, new SecObserve finding) must be able to dispatch an agent without a human. Kiro CLI supports this directly: • kiro-cli chat --no-interactive --agent sonar-fixer "..." runs headless. • KIRO_API_KEY authenticates in CI with no browser flow. • Standard exit codes (0/1/2) make it scriptable. Agent → Context (the MCP mesh) An agent is only as good as what it can see. Today the sonar-fixer sees SonarQube. A Level-4 agent should see the whole security picture: SonarQube (have), Dependency-Track and SecObserve (custom MCP, APIs already mapped), GitHub (official MCP), and AWS deployed state (awslabs MCP servers). Agent → Change (PR, not commit) Agents propose via pull requests, never direct pushes to protected branches. The Clean-as-You-Code quality gate then runs on the agent's PR just like a human's — the same bar applies. This is the safety mechanism that makes autonomy acceptable. Outcome → Memory (feedback loop) In an advanced Level 4 setup, each human correction should become durable, shared agent memory—not just a one-time review comment. Approved patterns, rejected approaches, architectural decisions, and remediation lessons should be captured in steering docs and connected to the enterprise knowledge base, so every agent can reuse the same organizational context. Over time, this creates a feedback loop where agents learn from reviews, align with company standards, and reduce repeated mistakes across teams and pipelines. Principles that keep this safe Agent integration fails when it's ungoverned. Athleon's Level 4 is bounded by: • Human-in-the-loop by default. Agents open PRs; humans merge. Autonomy is earned per workflow after it proves reliable, never granted wholesale. • The same quality gate for agents and humans. An agent PR that lowers coverage or adds issues fails the gate. No special path. • Least-privilege tooling. Each agent's allowedTools and MCP scope is the minimum for its job (e.g., sonar-fixer can read/write code and run tests, but not touch production). • No secret sprawl. KIRO_API_KEY and tool tokens live in GitHub secrets, never in agent JSON committed to the repo. • Reversibility. Every agent action is a reviewable, revertable Git change. Why “company” is ready for Level 4 Most teams that attempt agent integration are missing the foundation required to make it safe and repeatable. Company is different because the core DevSecOps substrate is already in place: • Existing quality gates. Agents already have a clear definition of done: pass the quality gate and pass the tests. • Centralized findings. SonarQube, Dependency-Track, and SecObserve provide structured, queryable inputs that agents can act on. • Spec-driven execution. The team already works through .kiro/specs/, which means intent is captured precisely enough for agents to follow. • A working sub-agent. The existing sonar-fixer agent is the seed for a broader remediation fleet. > In other words, the gap is not capability. The gap is connection. The flagship Level 4 initiative If the Company takes one practical step toward Level 4, it should start here: Convert sonar-fixer from a manually invoked assistant into a pipeline-triggered agent that opens review-ready pull requests. This approach reuses the gates, findings, specs, and sub-agent that already exist. It requires only one additional secret, KIRO_API_KEY, and immediately shifts the developer workflow from manual investigation to human review. It is also the cleanest proof of value for the broader agent-integrated DevSecOps roadmap. Conclusion: Closing the Loop The second part of this journey makes one point clear: building fast with agentic AI is only half of the story. The hidden side is what happens after the prototype works—how the organization governs code quality, security, compliance, and production readiness at scale. Kiro and similar agents can accelerate development, but they become truly valuable when they are connected to mature DevSecOps foundations: quality gates, centralized findings, secure CI/CD, MCP-based context, and human review through pull requests. This is the shift from an open loop—where tools report issues and humans manually chase them—to a closed loop, where agents transform findings into review-ready fixes. For companies adopting agentic AI, the goal should not be unchecked autonomy. The goal is governed acceleration: agents operating within clear policies, limited permissions, shared enterprise context, and the same quality standards expected from human developers. In that model, humans stay in control, but their effort moves from repetitive investigation to higher-value review and decision-making. The practical next step is simple and powerful: evolve the existing sonar-fixer assistant into a pipeline-triggered agent that opens pull requests with tested, explainable remediations. That single move proves the Level 4 model while preserving safety, traceability, and human accountability. Closing the loop is not about replacing developers. It is about giving development teams a smarter operating model—one where DevSecOps signals become action, agent memory improves with each review, and enterprise knowledge turns isolated fixes into repeatable engineering practice. ✨ Alejandro Velez, Platform Engineering Latam Lead @ GFT | AWS Ambassador