DEV Community: Martijn Mik

Your SOC2 Auditor Just Asked for an API Inventory. Does Your Code Have the Receipts?

Martijn Mik — Wed, 29 Apr 2026 07:25:11 +0000

It’s the email every Lead Dev dreads.

The compliance team just pinged you: "SOC2 Type II audit starts Monday. We need a full, verified inventory of all production endpoints and their associated authorization rules."

In the pre-AI era, this was a boring afternoon of exporting a Swagger file. But in 2026, it’s a nightmare. Over the last quarter, your team has been using AI to scaffold services at 10x speed. You’ve pushed hundreds of PRs.

You look at your swagger.json and then you look at your actual controllers. You realize there are "Zombie APIs" everywhere debug routes, perhaps even AI-hallucinated endpoints, and "temporary" data migrations that were never deleted.

So here you go, before just a simple list, but now you’re frantically tying together loose strings of code to build a coherent overview for the auditor. All while knowing it won't end there because, every 'Zombie API' you find represents a security flaw that needs an immediate fix

The "Audit-Velocity Gap"

AI in development can help a lot and speed up the shipping but it can also deliver a governance gap. Just because AI allows us to create infrastructure faster than we can document it.

See also this article on dev.to about AI is infrastructure

When you tell an auditor, "We have an API Gateway," they’ll ask, "How do you know the Gateway covers every endpoint actually living in your source code?"

If you can’t answer that, you don't have a security model. You have a "hope-based" compliance strategy.

Why "Zombie APIs" are Compliance Killers

In a SOC2 or ISO 27001 audit, you are tested on Access Control and Change Management.

The "Zombie" Route: Copilot suggests a /test-sync route to help you debug a PII issue. It gets merged. It’s not in the Gateway config, but it’s live in the container.
The "Auth-less" Peer: You have a microservice that is supposed to be internal-only, so the AI skips the auth decorator.

If an auditor finds even one of these, it’s a Non-Conformity. You aren't just "unorganized"—you're "non-compliant."

Shifting from "Manual Lists" to "Verified Evidence"

To survive an audit in the AI age, you have to stop treating your API inventory as a manual document. You need Static Analysis (SAST) to act as your "Automated Auditor."

We’ve all used the heavy hitters for this:

Snyk is fantastic for finding that one vulnerable npm package in your deep dependencies.
Checkmarx is a beast at scanning for SQL injection and cross-site scripting in enterprise-scale codebases.

These tools are essential for vulnerability management. But when the auditor asks, "Show me the authorization posture of every endpoint committed to the repo last month," general-purpose SAST can feel like using a sledgehammer to perform eye surgery. They find the "holes," but they don't always map the "house."

The Rise of Architectural SAST

This is where the workflow has to evolve. To bridge the gap, we needed something that didn't just look for "bugs," but looked for intent.

This is why we started leaning into ApiPosture.com.

Instead of waiting for a security researcher to find a shadow API, we use it as a "Governance Linter." It’s a CLI tool that scans the AST (Abstract Syntax Tree) of our code and generates a live map of every endpoint and its auth status in seconds.

It does the one thing Snyk and Checkmarx aren't specifically tuned for: It verifies that your code matches your claims.

The "Always-Audit-Ready" Workflow

We stopped "preparing" for audits. Instead, we made the audit part of the CI/CD pipeline. Here is the 2026 blueprint:

The PR Scan: Every time a dev hits "Merge," a SAST scan (like ApiPosture) runs. If a new endpoint is detected that isn't in the "Allowed" inventory, the build flags it.
Auth Verification: We don't just check if the code runs; we check if the [Authorize] or is_authenticated decorators are missing on new AI-generated routes.
The Evidence Export: When the auditor asks for a list, we don't manually edit a spreadsheet. We run a CLI command and export a JSON/CSV of every endpoint found in the source code.

That is "Verifiable Evidence."

Final Thought: Don't Let AI Make You a Liability

AI is the fasted developer we've ever hired, but to be frank it’s the worst documentation lead we’ve ever had.

If you’re still relying on manual Swagger updates to pass your SOC2, you’re playing a dangerous game. The complexity of modern stacks means you will miss something. A "Zombie API" isn't just a technical debt—it's a compliance landmine.

How is your team handling API inventory for audits? Are you still manually updating docs, or have you moved the "Inventory Gate" into your PRs? Let us now in the comments.

Why AI Is Breaking Your API Security Model (And Nobody on Your Team Notices)

Martijn Mik — Tue, 28 Apr 2026 12:10:32 +0000

Your API gateway is lying to you.

While you’ve been perfecting your OAuth flow and rate-limiting on the front door, AI has been busy building back doors. Over the last year, our "official" API documentation has become a work of fiction. For every documented endpoint, there are now three more living in the shadows, scaffolded by AI, pushed in a hurry, and completely invisible to our security stack.

At first, it felt like a superpower. Need a CRUD wrapper? Copilot it. Need a specialized data transformation endpoint? AI scaffold. We were moving at a velocity that made our previous sprints look like they were stuck in molasses.

But it also showed that velocity has a price. A few weeks ago, during a routine infrastructure audit, we asked one simple question:

“Can we list every unique endpoint currently routing traffic in production?”

The silence from the DevOps team was deafening. We realized that AI hadn’t just helped us write code; it had created a "Dark Matter" API layer that no one was tracking.

The 4 Horsemen of AI-Driven API Sprawl

We realized our actual attack surface had bloated far beyond our Swagger docs. We started seeing the same four patterns over and over:

The "Just for Now" Endpoint: AI generates a "temporary" health check or migration route. It gets merged, deployed, and forgotten.
Protocol Drift: One service uses strictly enforced mTLS, while a newer AI-scaffolded peer defaults to standard HTTP because the prompt was too vague.
Shadow Logic: Endpoints that bypass centralized auth middleware because the AI suggested a "quick" local validation logic that was subtly flawed.
Over-Sharing (PII Leakage): AI-generated schemas that default to SELECT * patterns, exposing internal metadata that should never leave the VPC.

The scariest part? The metrics looked perfect. No 5xx errors. No latency spikes. Just a growing cloud of endpoints we no longer controlled.

Why the "Fortress" Mentality is Failing

Most of us were taught the "Fortress" model: you define the walls (OpenAPI/Swagger), you gate the entrance (API Gateway), and you monitor the traffic.

But AI has turned every developer into a high-speed architect who can build new doors in seconds. When your creation rate exceeds your documentation rate, the "Fortress" becomes a sieve.

The Problem: Gateways Can’t See Intent. A Gateway only sees traffic once it’s already live. It doesn't know that /debug/user-sync was a hallucination that bypasses your PII masking. It just sees an authorized request and lets it through.

To fix this, we tried to do it manually. I spent hours clicking into every single endpoint in Swagger, one by one, trying to remember: "Did I protect this route? Is this one supposed to be public?" It was a nightmare. The documentation said one thing, but the code said another. I realized that if you want to secure an AI-driven environment, you have to stop looking at the traffic and start looking at the DNA—the source code.

What We Changed: From Gatekeepers to Automated Guardrails

This is why I built ApiPosture.

I needed a way to visualize every endpoint and its security posture instantly, directly from the source code, before it ever hit the Gateway. I didn't want to click through 50 Swagger tabs; I wanted a single source of truth that couldn't lie because it was derived directly from the logic.

By moving from manual spot-checks to Automated API Security Testing (SAST), we stopped playing "Whack-a-Mole" with shadow APIs. We now scan the code for:

Hidden Routes: Detecting endpoints in the source that aren't in the official specs.
Auth Deviations: Identifying when AI logic bypasses our global middleware.
Data Exposure: Flagging unreviewed endpoints that dump sensitive metadata.

We stopped treating API security as a network problem and started treating it as a code-level requirement. We now ensure that AI-generated endpoints are audited against our security standards before the first byte of traffic ever hits it."

The "Sobering" Standup Challenge

Try this at your next sync. Don't ask for the "approved" list. Ask your Lead Dev:

"If I look at our raw ingress logs right now, how many endpoints will I find that aren't in our Postman collection?"

If the answer involves a shrug, you don't have a security problem. You have a visibility crisis.

I made ApiPosture open-source because this isn't just my problem. It’s the inevitable result of building at the speed of AI. If we’re going to let AI write our code, we need a "Security Architect" that can read it just as fast.

Are you guys seeing this "Shadow API" creep? How are you tracking auth rules across hundreds of endpoints without losing your mind? Let's chat in the comments.

https://apiposture.com > free community edition available