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:
Developer uses an AI agent to build a microservice
Agent pulls in three AI SDKs, references two model families
API key gets hardcoded during dev ("temp, will fix")
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 moreHardcoded API keys — not just
OPENAI_API_KEYin.env, but inline keys, dev overrides, keys passed as function argumentsModel 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.
References
References
- ↩AICPA. (2017). *SOC 2 Trust Service Criteria — CC6.1: Logical and Physical Access Controls*. American Institute of Certified Public Accountants.
- ↩European Parliament. (2024). *Regulation (EU) 2024/1689 — Artificial Intelligence Act*, Articles 9 and 15. Official Journal of the European Union.
- ↩OWASP Foundation. (2025). *OWASP Top 10 for Large Language Model Applications — LLM02: Sensitive Information Disclosure*.
- ↩Semgrep. (2024). *Semgrep OSS: Static Analysis at Scale*. Semgrep, Inc.
- ↩OWASP Foundation. (2025). *OWASP Top 10 for LLMs — LLM01: Prompt Injection*.
- ↩CISA. (2023). *Software Bill of Materials (SBOM) — Framing Software Component Transparency*. Cybersecurity and Infrastructure Security Agency.
Loading comments...