AppSec framework for AI coding agents: two pillars that scale
AI coding agents like Kiro and Claude Code can open dozens of pull requests across your repositories in a single afternoon. That productivity comes with a real cost: the agent optimizes for task completion, not your organization’s risk posture. It has no idea what your security team’s policies are, and it moves faster than any human can review.
Through protocols like MCP, agents also reach beyond the IDE to call APIs, query databases, and modify infrastructure. The attack surface your AppSec team defends just got wider.
This guide lays out a two-pillar control framework that scales with agent-driven development. Pillar 1: author-time controls shape what the agent produces in the IDE. Pillar 2: build-time controls verify and gate that output in the pipeline before it reaches production. The framework is tool-agnostic and cloud-agnostic, though AWS services (Kiro in the IDE, CodePipeline and CodeBuild in the pipeline) are used throughout as a concrete example.
️ The Seven Risks Worth Knowing First
Before the controls, you need to understand what you’re actually defending against. The source article orders these by severity, highest impact first.
- R001 – Prompt and context injection: Agents read untrusted content (issue descriptions, README files, MCP responses). Malicious text from outside parties can redirect the agent to disclose secrets or invoke tools without user consent. This is the OWASP Top 10 for LLM Applications number one risk.
- R002 – Inadvertent data disclosure and overly permissive configs: Agents default to whatever pattern dominated training data. That often means wildcard IAM policies, open security groups, unencrypted storage, and hardcoded credentials.
- R003 – Uncontrolled changes reaching production: Machine-speed generation can propagate a flawed pattern across repositories before anyone notices.
- R004 – Supply chain risks: Agents recommend deprecated packages, reference library versions with known CVEs, and sometimes hallucinate package names that don’t exist, opening dependency confusion exposure.
- R005 – Uncontrolled external access: Without constraints on which MCP tools an agent can reach, a single misconfigured integration provides unintended access to sensitive resources.
- R006 – Hallucinations and incorrect code: Code that compiles, passes linting, and looks reasonable can still misuse APIs, introduce logic errors, or implement security-sensitive operations incorrectly.
- R007 – Scope creep: Given a bug-fix prompt, an agent might also refactor surrounding code, disable an unreliable test, or reorganize imports. Unrequested changes introduce regressions and complicate review.
Deterministic vs. Non-Deterministic Controls
Before diving into the pillars, the framework distinguishes three control types:
- Deterministic [D]: Same result every time. Linters, SAST scanners, secrets detection, policy-as-code. Use these when the condition can be expressed as a rule.
- Non-deterministic [ND]: Model judgment. Steering documents, LLM-as-judge review, specification compliance checks. These evaluate intent rather than patterns and catch novel issues rules miss. They’re probabilistic, not guaranteed.
- Human [H]: Final layer for risk-based decisions neither tool type can make. The critical point here: routing every change to a person invites consent fatigue, where reviewers approve by reflex. Reserve human judgment for decisions that genuinely need it.
Pillar 1: Author-Time Controls (In the IDE)
Author-time controls work inside the IDE, where the developer and agent still hold full context. They shape the prompt and the generated output before it ever reaches a pull request.
Context as a security control [ND]
Write security invariants once as natural-language guidance in a steering document. The agent loads the file at session start and treats the contents as standing requirements. Example rules:
- IAM policies must follow least-privilege principles. No wildcard ARNs.
- No hardcoded credentials in source code. Use a secrets manager.
- Security groups must not allow unrestricted inbound access.
Steering biases generation toward secure defaults. It doesn’t guarantee them. Treat it as a strong default paired with the deterministic gates that follow. In Kiro, steering files live in .kiro/steering/ and support conditional inclusion via fileMatch, so IaC-specific rules load only when the agent is working on Terraform files.
The open source Project CodeGuard (a Coalition for Secure AI project under OASIS Open) publishes reusable steering rules for common risk classes, including hardcoded credentials, IaC misconfiguration, supply chain, and MCP security, ready to adapt to your environment.
Specifications as scope boundaries [ND]
Require a reviewed specification before code generation begins. Spec-driven workflows turn vague prompts into reviewable documents before any code is written. Requirements use testable notation (the EARS format: WHEN [condition] THE SYSTEM SHALL [behavior]). Tasks map back to requirements in ordered implementation steps.
For bug fixes, the specification must explicitly list unchanged behaviors. This gives the agent a written boundary against scope creep. Human review effort concentrates on whether the specification solves the right problem, not on reading implementation diffs line by line.
Controlled tool access via MCP [D + ND]
Scope each MCP server to the minimum set of tools the agent needs. Give it a dedicated, scoped-down credential rather than the developer’s own. Maintain an allowlist of reviewed MCP servers. In Kiro, credentials go in the env block of .kiro/settings/mcp.json. Avoid autoApprove: ["*"], which removes the human approval prompt on every tool call.
IDE code scanning [D]
Run real-time static analysis in the IDE. Security-focused extensions like ESLint security plugins and Checkov catch a malformed IAM policy before the agent builds further on it. The fix is cheap here. It gets more expensive downstream.
Hooks: Automated guardrails at the point of action [D + ND]
Attach two types of hooks:
- Shell command hooks [D]: Triggered on file save. Run a linter, formatter, or security scanner. Same result every time. Hard rules enforced.
- AI-powered hooks [ND]: Triggered on task completion. Prompt the agent to verify the implementation matches the specification, check for untested edge cases, and flag any files modified outside the task’s stated scope.
Pillar 2: Build-Time Controls (In the Pipeline)
Build-time controls run after code is committed and before it reaches production. They catch what Pillar 1 did not.
Layered security scanning [D]
Run four scanning stages in sequence. Fail the build on any critical finding.
- Secrets detection first: Cheapest scan, highest severity class. Catches hardcoded API keys, database connection strings, and credentials the agent may have included.
- SAST: Scans source code for injection issues, insecure deserialization, and resource leaks. Custom rules can target AI-specific anti-patterns: overly broad exception handling, deprecated APIs, placeholder credentials, and dynamic code execution via
eval(). - Software Composition Analysis (SCA): Identifies known CVEs in dependencies. Critical for AI-generated code, which may reference deprecated packages or hallucinate package names that open dependency confusion exposure.
- IaC scanning: Validates CloudFormation, Terraform, and AWS CDK templates against security policies before deployment. Catches overly permissive IAM roles, unencrypted storage, and public-facing resources the agent created.
The open source Automated Security Helper (ASH) bundles all four scanners behind one command you can run locally and in AWS CodeBuild. Results export as SARIF for compliance auditing.
Quality gates [D]
Define pass/fail thresholds for each scan type. Block on critical findings. Require documented justification for highs. Track mediums. Differentiate blocking versus advisory modes: hard failures on main, advisory on feature branches. Avoid gates that teams learn to route around.
AI-assisted review [ND]
Use a separate LLM to pre-screen every pull request before human review. Check three things:
- Does the implementation match the requirements document?
- Were files modified outside the task’s stated scope?
- Are there logic errors, misused APIs, or insecure patterns that pass SAST but violate intent?
A critical principle: the agent that wrote the code should not be the agent that reviews it. A separate session reduces self-confirmation bias, but a separate session of the same model can still share the generator’s systematic blind spots. Where practical, use a different model for review. On AWS, AWS Security Agent (code review was in preview at the time of publication) checks pull requests against AWS-managed and custom security requirements.
Human-in-the-loop review [ND + H]
Scale review depth to the risk of the change. Low-risk or boilerplate changes can take a lighter-touch review. Security-sensitive or novel-logic changes warrant mandatory deep review and a second reviewer. Place two approval gates: after security scans (reviewer focuses on correctness and business logic) and before production deployment (final sign-off after integration testing).
Treat human review as a secondary control, not a guarantee. Reviewers are themselves non-deterministic and miss things. Human review layers on top of the deterministic gates, not instead of them.
The Full Control Matrix
| Stage | Deterministic [D] | Non-deterministic [ND] |
|---|---|---|
| IDE (pre-generation) | Steering files loaded | Steering documents, specification-driven constraints |
| IDE (post-generation) | Shell hooks: linter, formatter, type checker, secrets scan | AI-powered task completion hooks, context constraints |
| Pull request | SAST, SCA, IaC scanning | LLM PR pre-screening, scope verification |
| Pipeline (pre-deploy) | Full security scan suite, integration tests, policy-as-code | AI-assisted review for human approvers |
| Post-deploy | Runtime monitoring, anomaly detection | AI-powered incident triage |
Where to Start This Week
The article’s recommended sequence for teams adopting this now:
- Steering and specs first. Encode security requirements in a steering document and use specifications for new features. Highest impact, lowest effort. Pull from Project CodeGuard for a ready-made starting set.
- Add deterministic pipeline gates. Integrate SAST, SCA, and secrets detection. These are table stakes regardless of AI usage.
- Calibrate and iterate. Review what the controls catch. Adjust steering for recurring issues. Expand agent autonomy as trust builds.
- Keep accountability clear. Developers remain accountable for the security of what they ship. Agents accelerate development. They don’t transfer ownership.
I’m founder of BizStack at Cagri Sarigoz LLC and a passionate advocate for entrepreneurs.
With over 14 years in tech, marketing, and AI, including my role as Head of SEO at CitizenShipper and co-founder of TaleBot at Intale AI, I’m dedicated to sharing genuine, useful product insights and tips.
At BizStack, I aim to cut through the digital noise to provide clear, actionable advice.
And more than all else, I’m a father to a (always) little girl and a husband.
Contact me at [email protected] for assistance.
