400 integrations answered a question that no longer exists

Why integrations were the right design

Let me steelman the compliance platforms, because they earned it.

Before they existed, a founder who needed a SOC 2 had two bad options. Hire a traditional CPA firm priced for enterprises. Or hand-collect evidence in a spreadsheet for months with no idea if any of it was right.

The platforms gave you a third option. Their software integrated with your stack and organized the evidence continuously. That was genuinely useful, and for about a decade it was the best thing going.

The integration count was the value prop for a real reason. Software cannot log into your AWS account or your HR system. So a platform had to ship a connector for each tool, query its API, and normalize the result into something an auditor could read. More integrations meant more coverage. The connector backlog was a sensible moat. None of that was a scam. It was good engineering against a real constraint.

What actually changed

The constraint moved.

Your terminal is now connected to an AI agent. Claude Code, Codex, Cursor, whatever you run. That agent already has shell access to your machine. Anything your own CLI can reach, the agent can reach. The aws CLI, gcloud, az, gh, okta, kubectl, psql, an internal script, a niche vertical tool your platform never built a connector for.

Model Context Protocol is the open standard that lets an agent invoke tools, including shell commands, against whatever is on the machine. It is published and adopted across the major AI platforms. So the auditor's question changes. It used to be "is there a connector for that?" Now it is "can you run the command?" For the real source of truth, the answer is almost always yes.

That is why the integration number stops mattering. It does not matter how many a platform claims. The count was scaffolding to get software close to systems it could not enter. Once your own agent is inside the terminal, the scaffolding is dead weight.

A fair note for balance. The platforms have shipped their own MCP servers. From their published docs, those are read-only query layers bolted onto the existing dashboard. They use MCP to let you ask the dashboard questions. An MCP-native audit uses MCP to reach the source system directly. Different layer entirely.

Why raw source output is better evidence

Here is the part that matters to me as the auditor, not just the part that is convenient.

Both an MCP-native audit and a platform pull from the same real systems. The difference is what I actually inspect.

Platform evidence reaches me as a normalized tile. The connector queried the API, mapped the result to a control, and rendered a pass or fail. I am inspecting the platform's rendering of your system. MCP-native evidence is the literal output of a command run against the source, returned verbatim, with me directing which procedure to run and observing the result. I am inspecting the real thing.

That is a textbook reliability upgrade. Auditing standards rank evidence by source and directness. Evidence the auditor obtains directly is more reliable than evidence obtained indirectly. Direct inspection and observation sit at the top of that ladder. Oral inquiry sits at the bottom. Raw source output I directed and watched produce sits high. A tile I was handed sits lower, because it is a processed representation, not my direct inspection of the underlying record.

And inquiry alone is never enough. That is the standard, not my opinion. AT-C 205 requires inquiry plus a corroborating procedure, and the listed procedures are inspection, observation, analysis, reperformance, recalculation, and confirmation. A CPA reading the raw return of a live command against your source system is performing inspection and observation, the way the standard actually defines them.

It is also harder to fabricate. The most-faked SOC 2 evidence is the screenshot and the hand-maintained tracker. Those can be backdated, staged, or edited. Raw terminal output, run under my direction with the procedure documented, is much closer to the immutable-source ideal. I saw it produced instead of receiving it pre-packaged.

Zero-credential access, and the CPA still signs

There is a privacy upside too, and I want to state it as a design fact, not an accusation.

A platform integration is read-only, which is a responsible design. But it still asks you to grant a third party standing API access into your cloud, identity, and code systems, and that access persists. The MCP-native model grants no standing third-party access at all. Your agent runs the command locally, only the output leaves your machine, and nothing stays connected. The firm holds evidence, never your keys. You are the gatekeeper.

None of this removes the auditor. It cannot. Under AICPA standards, only a licensed CPA firm can perform the examination and sign the opinion. The platform was always the evidence-organizing layer, not the audit. I still independently direct which procedures run, evaluate the evidence, exercise professional skepticism, and put my license behind the conclusion. The AI makes collection efficient. The signature still has to mean a person stood behind it.

So this is not "integrations are useless." They were the correct answer to a question that no longer exists. Software could not reach into your systems, so a connector did it for you. Now your own agent reaches the source directly, the evidence is stronger for it, and the auditor is still the one who decides what it means.