From Vibe-Coded App to SOC 2 Audit in 60 Seconds

From Vibe-Coded App to SOC 2 Audit in 60 Seconds

6 min read
Updated March 28, 2026

Vibe coding is real now. Developers are shipping entire services by describing what they want to Claude Code or Cursor. I've done it. You've probably done it. The output is surprisingly good.


Here's the part nobody talks about: when your AI agent pulls in langchain, openai, and anthropic SDKs, hardcodes a dev API key because "we'll fix it in cleanup," and references GPT-4 by name in three config files — who's tracking that?

Your SOC 2 auditor is about to ask. And right now, most teams don't have an answer.


The gap nobody sees coming

I've spent two decades in security. I've watched organizations fumble through PCI audits, SOC 2 renewals, ISO certifications. The pattern is always the same: the compliance framework moves faster than the tooling, and engineering teams get caught flat-footed.

AI is the current version of that story. Here's how it plays out:

  1. Developer uses an AI agent to build a microservice

  2. Agent pulls in three AI SDKs, references two model families

  3. API key gets hardcoded during dev ("temp, will fix")

  4. Code ships. Sprint closes. Nobody inventories what just landed in production.

Six months later the auditor shows up asking: What AI systems are deployed? How are AI credentials managed? Do you have an AI Bill of Materials?

This isn't hypothetical:

  • SOC 2 CC6.1 (Logical and Physical Access Controls) now explicitly covers AI API credential management.[1]

  • EU AI Act Article 9 requires risk management systems for AI, and Article 15 mandates accuracy and cybersecurity measures.[2]

  • OWASP LLM Top 10 (2025) lists hardcoded API keys as a textbook example of LLM02 — Sensitive Information Disclosure.[3]

The frameworks caught up. The tooling didn't. That's the gap we're closing with AI Agent Lens.


What auditors actually want

After working with security teams across a lot of organizations, it boils down to five things:

  • Inventory — what AI components are in your codebase (SDKs, models, API integrations, data flows)

  • Risk assessment — hardcoded credentials? unsanitized LLM outputs? missing token limits?

  • Compliance mapping — findings linked to specific controls, not "we think we're compliant"

  • Gap analysis — which controls have zero evidence of coverage

  • Remediation plan — what's the fix, who owns it, what's the timeline

Most teams answer these with spreadsheets and Slack threads. That works until you have 85 findings across five compliance frameworks with four gaps you didn't know existed.


One command

$ agentcompliance scan /your/project

Real output from scanning a production AI chatbot codebase:

Scanning /your/project...
Found 85 AI usage points

Overall Risk: MEDIUM (score: 5.3/10.0)
Total Findings: 85
  critical: 2
  medium:   4
  low:      78
  info:     1

Compliance Coverage:
  OWASP LLM Top 10:  100%
  SOC 2 Type II:     100%
  NIST AI RMF:       89%
  ISO 27001:         88%
  EU AI Act:         88%

Compliance Gaps: 4

Under 60 seconds. Zero configuration. Complete inventory, risk scores, coverage percentages across five frameworks, and specific gap identification.


Under the hood

The scanner runs 2,630 static analysis rules built on Semgrep.[4] Every rule has true-positive and true-negative test cases. The rules cover patterns most security tools don't know exist yet:

  • AI SDK imports across Python, TypeScript, Go, Java, Ruby, and C# — langchain, openai, anthropic, huggingface, dozens more

  • Hardcoded API keys — not just OPENAI_API_KEY in .env, but inline keys, dev overrides, keys passed as function arguments

  • Model references — GPT-4, Claude, Gemini, Llama, 50+ model families with version tracking

  • Data flow risks — LLM output piped to eval(), unsanitized responses in SQL queries, prompt injection vectors[5]

  • Governance gaps — missing token limits, absent audit logging, uncontrolled agent invocations

Each finding maps to a threat taxonomy of 424 entries across eight AI/ML security kingdoms — credential exposure, supply chain compromise, agentic attack patterns, and more.


The AI Bill of Materials

The EU AI Act and emerging industry standards increasingly require an AI Bill of Materials (AIBOM) — a complete inventory of AI components, analogous to a Software Bill of Materials (SBOM) for traditional dependencies.[6] The scanner generates this automatically:

{
  "aibom_version": "1.0",
  "ai_components": {
    "sdks": [
      {"name": "langchain", "languages": ["python"], "occurrences": 12},
      {"name": "openai", "languages": ["python"], "occurrences": 8},
      {"name": "anthropic", "languages": ["python"], "occurrences": 3}
    ],
    "models": [
      {"name": "gpt-4", "references": 5},
      {"name": "claude-3-sonnet", "references": 2}
    ]
  },
  "compliance_coverage": {
    "owasp-llm-2025": 1.0,
    "soc2-type2": 1.0,
    "nist-ai-rmf-1.0": 0.89,
    "iso-27001-2022": 0.88,
    "eu-ai-act-2024": 0.88
  }
}

Hand this to your auditor. They've never seen anything like it.


Findings you can actually act on

A compliance report nobody acts on is just expensive documentation. Each finding ships with a remediation prompt you can paste directly into your AI coding agent:

## Issue: Hardcoded OpenAI API key detected
File: app/dev_overrides.py:15 | Risk: critical | Rule: ai-api-key-env-openai

Move the credential to an environment variable or secrets manager.
Replace the hardcoded value with os.environ (Python) or process.env (JS/TS).

Copy. Paste into Claude Code. Finding gone. Compliance posture improves with every commit.


What we shipped

Built and deployed this week:

  • SaaS compliance dashboard at aiagentlens.com — five tabs: Scan & Assess, History, AI BOM, Remediate, Report

  • One-command scanning with automatic upload, no flags needed

  • 100% inline test coverage for all 1,316 runtime security rules in AI Agent Shield

  • 8x performance improvement through pre-compiled regex caching

  • Overnight autonomous agents continuously developing new rules and fixing false positives

We're building in public because AI security shouldn't be a black box.


The clock is moving

EU AI Act enforcement deadlines are here.[2] SOC 2 auditors are adding AI-specific control objectives.[1] If your team is using AI agents to write code — and in 2026, that's most teams — you need to be able to answer the auditor's question.

You can build the answer from scratch with spreadsheets. Or you can run one command and have it in 60 seconds.

Try AI Agent Lens →


References

References

  1. AICPA. (2017). *SOC 2 Trust Service Criteria — CC6.1: Logical and Physical Access Controls*. American Institute of Certified Public Accountants.
  2. European Parliament. (2024). *Regulation (EU) 2024/1689 — Artificial Intelligence Act*, Articles 9 and 15. Official Journal of the European Union.
  3. OWASP Foundation. (2025). *OWASP Top 10 for Large Language Model Applications — LLM02: Sensitive Information Disclosure*.
  4. Semgrep. (2024). *Semgrep OSS: Static Analysis at Scale*. Semgrep, Inc.
  5. OWASP Foundation. (2025). *OWASP Top 10 for LLMs — LLM01: Prompt Injection*.
  6. CISA. (2023). *Software Bill of Materials (SBOM) — Framing Software Component Transparency*. Cybersecurity and Infrastructure Security Agency.
Gary
Written by
Gary

Security architect specializing in application security, threat modeling, and AI agent risk. Builder of runtime security tooling for autonomous AI agents. Co-founder of AI Agent Lens, where he leads development of AgentShield (runtime command evaluation), AI governance scanning, and security taxonomy frameworks. Passionate about making AI agents safe enough to trust with production systems.

Anshuman Biswas
Contributor
Anshuman Biswas

Engineering leader specializing in threat detection, security engineering, and building enterprise B2B systems at scale. Deep hands-on roots in software architecture and AI tooling - currently exploring the frontier of AI agents as co-founder of AI Agent Lens.

Comments

Loading comments...