Do you still need integrations?

Why integrations were the right design

Let me give the compliance platforms their due, because they earned it.

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

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

The number of integrations was the headline feature for a real reason. Software can't simply log into your AWS account or your HR system. So a platform had to build a connector for each tool, ask that tool's API for the data, and translate the answer into something an auditor could read. More integrations meant more of your stack was covered. The backlog of connectors a platform had built was a sensible advantage. None of that was a trick. It was good engineering against a real limitation: software sitting on the outside, trying to see in.

What actually changed

The limitation 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 command line can reach, the agent can reach: the aws CLI, gcloud, az, gh, okta, kubectl, psql, an internal script, a niche industry-specific tool that no platform ever bothered to build a connector for.

The piece that makes this work is the Model Context Protocol (MCP), an open standard that lets an AI agent run tools, including shell commands, against whatever is on the machine. It is published and supported across the major AI platforms. So the auditor's question changes. It used to be "is there a connector for that tool?" 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 being the thing that matters. It no longer matters whether a platform advertises 50 connectors or 400. The connector count was always a way to get software close to systems it couldn't actually enter. Once your own agent is working inside the terminal, that workaround isn't doing much.

A fair note, for balance. The platforms have shipped their own MCP servers too. From their published documentation, those are a read-only way to ask questions of the existing dashboard. They use MCP so you can query the dashboard in plain language. An MCP-native audit uses MCP to reach the source system itself. That is a different layer of the same idea.

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 look at.

With a platform, the evidence reaches me as a tidy result on a screen. The connector asked the API a question, matched the answer to a control, and showed a pass or a fail, usually as a green checkmark on a dashboard. What I'm looking at is the platform's version of your system. With MCP-native collection, the evidence is the literal output of a command run against the source system, returned word for word, with me choosing which check to run and watching the result come back. What I'm looking at is the real thing.

That is a textbook step up in how trustworthy the evidence is. Auditing standards rank evidence by where it came from and how directly the auditor got it. Evidence the auditor obtains directly is more reliable than evidence obtained second-hand. Looking at the real record yourself, and watching a control operate, sit at the top of that ladder. Just asking someone and taking their word for it, which auditors call inquiry, sits at the bottom. Raw source output that I asked for and watched produce sits high. A green checkmark I was simply handed sits lower, because it is a processed summary, not my own direct look at the underlying record. And the standard does not let an auditor just accept that summary. AT-C 205, the attestation standard that governs this kind of audit (the audit work itself plus the CPA's formal opinion), requires the auditor to judge whether information a tool produces is reliable, accurate, and complete. That is hard to do for a checkmark you didn't generate and can't reproduce. An auditor who never pulls any evidence and trusts whatever the dashboard shows has no way to catch a number that was staged or out of date. Inspecting the raw evidence yourself is how you actually clear that bar.

And just asking is never enough on its own. That is the standard, not my preference. AT-C 205 requires inquiry (asking) plus at least one corroborating procedure, and the procedures it lists are inspection, observation, analysis, reperformance, recalculation, and confirmation. A CPA reading the raw return of a live command against your source system is doing inspection and observation, exactly the way the standard defines them: looking at the actual record, and watching it happen.

It is also harder to fake. The SOC 2 evidence that gets faked most often is the screenshot and the hand-kept tracker. Those can be backdated, staged, or quietly edited. Raw terminal output, run while I'm directing it and with the procedure written down, is much closer to the ideal of a record that can't be tampered with. I saw it produced, rather than receiving it pre-packaged.

Zero-credential access, and the CPA still signs

There is a privacy upside too, and I want to put it plainly as a design fact, not a knock on anyone.

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

None of this removes the auditor. It can't. Under AICPA standards, only a licensed CPA firm can perform the examination (the actual audit) and sign the opinion. The report is issued in the firm's name, and the individual CPA is the engagement lead who does the work and stands behind it. The platform was always the layer that organized the evidence, not the audit itself. I still independently decide which checks to run, weigh the evidence, stay skeptical the way the standards require, and put my license behind the conclusion. The AI makes collection efficient. The signature still has to mean a real person stood behind it.

So this isn't "integrations are useless." They were the right answer to a question that no longer exists. Software couldn't reach into your systems, so a connector did it on its behalf. 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 all means.