Software development is changing fast. Engineering teams and “citizen developers” (business users who build apps with little traditional coding experience) are adopting agentic AI, large language models (LLMs), and “vibe coding.”

In vibe coding, users prompt autonomous agents to write, refactor, and deploy code directly. A CodeSignal developer survey found that 81% of developers now use AI tools for code completion, unit test generation, documentation, and refactoring.

But code now ships at machine speed, and governance hasn’t kept up. Source control records who committed a file. It doesn’t record how or why the AI generated it. Prompt histories, context windows, and safety instructions disappear when a session closes. That hides serious architectural flaws and piles up security debt. Repositories become un-auditable “black boxes” that can fail SOC 2, ISO 27001, and NIST SSDF audits.

The fix is to move from manual review to an operational control plane. It has three parts: author-time guardrails, build-time pipeline gates, and verifiable AI governance.

Know the Two Ways AI Code Puts You at Risk

Shadow AI in software engineering, is the use of AI models, browser extensions, and coding agents without security oversight. It exposes you in two directions.

Direction 1 (data egress). Developers paste proprietary code, architecture diagrams, or connection strings into public chatbots. Your intellectual property leaves the company. These leaks slip past perimeter firewalls. The traffic looks like ordinary encrypted HTTPS/TLS to an external endpoint, so traditional network DLP tools often can’t see it without TLS inspection.

Direction 2 (code ingress). Unreviewed AI output writes flaws straight into production. Models optimize for plausible completions based on patterns in training data. That often produces insecure defaults like wildcard Identity and Access Management (IAM) policies, open security groups, unencrypted S3 storage, and dynamic code execution calls (eval()).

AI tools also add supply chain risk. They suggest deprecated packages or invent library names that don’t exist. Attackers can register those invented names, a tactic known as slopsquatting.

AppSec leaders should assess both directions together:

Risk Category	Engineering Impact
Secrets leakage	Hardcoded API keys, database connection strings, and tokens exposed to third-party model logs through IDE prompts.
Insecure defaults	Generated wildcard IAM ARNs, unrestricted security groups, and unencrypted cloud storage configurations.
Hallucinated packages	Supply chain exposure when AI suggests non-existent or abandoned open-source packages.
Broken Git provenance	Lost attribution when AI-generated changes merge under human committer identities with no prompt record.
License infringement	Copyleft violations (e.g., GPL/AGPL) when models reproduce copyrighted code verbatim.
Prompt injection against dev tools	Malicious text in issues, package READMEs, or pull requests overrides agent instructions and triggers arbitrary shell actions.
Unvetted rule and skill files	Poisoned or unreviewed configuration files (e.g., .kiro/steering/) tell AI agents to weaken security defaults.

Closing these gaps takes visibility across the whole software development lifecycle. The Cycode Shadow AI research shows what that looks like in practice.

Set Guardrails Before Code Reaches a Pull Request

Author-time controls are Pillar 1 of secure AI development. They work inside the developer’s IDE and shape AI output while it is being generated, before anything reaches a pull request.

Key author-time mechanisms:

1. Steering documents: Security teams write security rules in plain Markdown files stored in the repository (e.g., .kiro/steering/). The agent loads them at session start. They can require AWS Secrets Manager instead of hardcoded credentials, enforce least-privilege IAM, and ban wildcard resource declarations. Keep each rule short, testable, and tied to a specific risk. See the Kiro IDE documentation for implementation details.

2. Specification-driven workflows: Require a reviewed specification before generation to stop AI drift. Structured notation like the Easy Approach to Requirements Syntax (EARS) sets precise behavior limits: WHEN [condition] THE SYSTEM SHALL [behavior]. For bug fixes, document “unchanged behaviors” so the agent doesn’t refactor what you didn’t ask it to touch. Specifications can also drive property-based testing, which runs hundreds of randomized inputs to exercise edge cases.

3. IDE hooks and scanning: Deterministic shell hooks on file-save events run formatters, linters, and static analysis automatically. Non-deterministic AI hooks prompt the agent to check its work against the specification before it generates diffs.

Add Pipeline Gates and Layered Scanning at Build Time

Build-time controls are Pillar 2. They sit inside your CI/CD pipelines and verify code after commit and before deployment.

Run security scanners in this order:

1. Secrets detection: Runs first to catch hardcoded API keys, certificates, and database tokens before any heavier compute runs.

2. Static Application Security Testing (SAST): Scans source code for injection flaws, dynamic execution risks (eval()), deprecated APIs, and logic flaws.

3. Software Composition Analysis (SCA): Checks lockfiles for known Common Vulnerabilities and Exposures (CVEs), deprecated packages, and hallucinated dependencies.

4. Infrastructure-as-Code (IaC) scanning: Validates Terraform, CloudFormation, and AWS CDK templates against policy-as-code rules to block misconfigured security groups and public storage.

The AWS Security Blog puts the core rule simply: “Generation does not equal acceptance.” An AI agent can propose code. Your pipeline decides whether it meets your standards.

Know Which Checks Are Deterministic, Which Aren’t, and Where Humans Step In

Build your DevSecOps pipeline around three kinds of evaluation:

1. Deterministic controls [D]: Rule-based tools (linters, SAST, secrets detection, policy-as-code) that give the same pass/fail result every run.

2. Non-deterministic controls [ND]: Model-driven checks (LLM-as-judge, AI pull request pre-screening) that assess architectural intent, specification compliance, and scope creep across multiple files.

3. Human review [H]: High-judgment approvals for security-critical, high-impact changes.

The model that wrote the code should not be the model that reviews it. A fresh session of the same model isn’t enough. Models with the same architecture share training blind spots and a bias toward confirming their own work. Use a different model architecture or a specialized fine-tuned model for review.

Control Type	Operational Scope
Automated deterministic gates [D]	Apply to every branch. Block hardcoded secrets and syntax errors with no human involved.
Model-driven reviewers [ND]	Check intent, specification compliance, and scope creep across files before a human looks.
Reserved human oversight [H]	Focus only on high-risk changes (e.g., auth logic, payment gateways) so reviewers avoid consent fatigue.

For more on developer accountability in automated workflows, read RhodeCode’s analysis of AI accountability.

Lock Down MCP Integrations With Least Privilege

AI coding agents now reach past local files into databases, API endpoints, and cloud infrastructure through the Model Context Protocol (MCP). An overprivileged agent turns a single compromised integration into a serious incident.

Agents also face prompt and context injection through MCP responses (OWASP LLM01). When an agent queries an untrusted MCP server or external API, malicious text in the response can hijack its context. It can then run unauthorized local commands or leak private data.

Set strict boundaries:

1. Enforce least-privilege MCP tooling: Scope each MCP server to the minimum resources it needs. For example, use an MCP server in front of a private package registry (such as AWS CodeArtifact) to block dependency confusion attacks.

2. Issue dedicated credentials: Give agents restricted API credentials, not full developer OAuth tokens or local .env access.

3. Control server registrations: Keep approved MCP configurations in repository-controlled files (e.g., .kiro/settings/mcp.json). Forbid wildcard approvals like autoApprove: [“*”], which remove human checkpoints on tool calls.

Write an AI Acceptable Use Policy and Keep Provenance

Technical controls need an enforceable policy behind them. Your AI coding policy should define approved tools, sandbox rules for vibe coding, copyleft licensing filters, and mapping to frameworks like NIST SSDF. Tenable’s guide to enforcing an AI AUP covers the details.

Policy still fails without AI code provenance. A Git commit shows who pushed a change. AI provenance shows per-line attribution, prompt history, model identity, and human edits.

Full session context lets DevSecOps teams investigate regressions months after deployment. Provenance platforms like Origin’s AI provenance platform, paired with self-hosted source code management (SCM), keep prompt records, diffs, and attribution data behind your corporate firewall.

Move Fast Without Losing the Audit Trail

AI code governance isn’t about slowing development down. It’s about keeping AI-generated contributions governable, traceable, and secure.

The teams that win with agentic development will combine author-time guardrails with build-time pipeline gates. That gives them continuous visibility into every repository.

So ask yourself: when an AI agent deploys code to production at 3:00 AM, can your repository explain not just who approved it, but the exact intent and prompt history behind every line?

Bring the Same Audit Discipline to Your Business Agreements

Good AI governance rests on one idea: every important action needs a record, a rule, and an accountable approver. Your contracts and approvals need the same discipline.

Flowmono is an AI-powered Workflow Operating System that brings structure and trust to business processes:

1. Flowmono E-Sign: Adds tamper-evident, time-stamped audit trails to digital agreements, so you can show who signed what and when.

2. Flowmono Automate: Enforces multi-stage routing, threshold-based sign-offs, and alternate approver rules, so every process runs the same way every time.

3. Flowmono Drive: Centralizes document management with structured access controls, so procurement and legal teams stop working in silos.

Flowmono AI adds intelligent OCR data extraction, automated contract summarization, and context-aware Q&A (Flow Q&A). See how it makes your workflows auditable and secure.

Make Every Approval Auditable

AI is speeding up your engineering teams. Your agreements and approvals should keep pace without losing the paper trail.

Flowmono gives you the audit trails, approval rules, and document control to do exactly that.

Sign up at flowmono and build your first workflow today.