What an AI Agent May Do When Nobody Is Watching

We ran an audit on our own MCP connector last week and the number that stopped me was this one: of 459 actions the platform can perform on a customer's go-to-market work, the connector could reach zero. It could read six of twenty-three module types. It could write no feedback at all. We had shipped a connector that let an AI agent look at some of your marketing foundation and touch none of it.

That is a boring bug. What was not boring was what we found when we tried to fix it, because the fix forced us to write down a line we had been carrying around unexamined for a year: which things may an AI agent do on your behalf, and which stay with you.

A connector is not a chatbot with a longer arm

Most people meet AI in a chat window. You type, it answers, you read the answer. Whatever it got wrong, you see, because you are sitting there.

The Model Context Protocol changes the shape of that. MCP is an open standard for handing an AI client a set of tools and data sources it can call directly. Connect T2D3 OS to Claude and Claude can pull your ICP, your personas, your value propositions, your brand voice, and work with them in a conversation that never touches our interface. That is genuinely useful. A fractional CMO running six clients should not have to re-explain client four's positioning every morning.

But when we lined the connector up against our own in-app chat, which does most of the same work, three differences made it obvious that these are not the same surface wearing different clothes.

In in-app chat, a person sees each result, in session, as it happens. Over the connector, results are JSON going to a client we do not control. Nobody is guaranteed to read them.

In in-app chat, the untrusted input reaching an authenticated tool is limited. Over the connector, the tools read the whole ingested signal corpus: every transcript, PDF, and scraped page a customer ever uploaded. That is a large surface of text written by other people, flowing into a tool that is already authenticated as you.

In in-app chat, the session boundary is a person sitting there. Over the connector, the boundary is a long-lived OAuth token, unattended.

So we decided the connector gets parity with chat in what it can do, and stricter controls around doing it. Not equal. Stricter. Same capability, plus a feature gate, plus a pre-flight credit check, plus an explicit dispatch allowlist. The instinct to say "make the connector as powerful as the chat" is right about capability and dangerous about controls, because the controls in our chat do not live in the tools at all. They live in the route that calls them. Port the tools alone and you have copied the power and left the seatbelts behind. A grep at the tools layer would have told us chat was ungated. It is not. We nearly learned that the expensive way.

The line we had been drawing was in the wrong place

Our previous design note said: Claude gathers and drafts; the app keeps the judgment moments. It reads well. It is the line most teams draw, in some wording or other.

It is also too coarse, and the audit showed why. That line was shielding triage. It was shielding doc-type fixes, verification, usage instructions. Ordinary reviewer corrections that are not judgment moments in any meaningful sense, held back on the theory that a human should be in the loop. Meanwhile it said nothing precise about the moments that actually cannot be undone.

The sharpened version we now build against:

The connector may gather, draft, correct, and record a verdict. The app keeps the irreversible moments: lock, vote, send, spend, delete-without-checkpoint.

Look at what moved. Correcting a mis-tagged document moved to the agent, because it is reversible and a human doing it by hand is just slower. Recording a verdict moved to the agent, because a verdict is a written opinion, not an act. What stayed is a short list with one thing in common: each item either commits the organization to something, spends the customer's money, sends something to a third party, or destroys work without a way back.

"Human in the loop" is not a principle. It is a placeholder people put where a principle should go. If you cannot say which specific operations require the human and why each one is on the list, you do not have a safety model, you have a feeling. And the cost of the feeling is real: every reversible task you withhold from the agent is a task your customer now does by hand, for no safety gained.

Every withhold needs its reason written next to it

The corollary turned out to matter as much as the rule. If the app declines to let the agent do something, the reason has to live in the code, next to the thing withheld.

We had three withholds with no rationale anywhere: publishing from Website Builder, approving a manuscript, and casting live disposition votes in a workshop. When we went looking for why, there was no why. Nobody had decided to hold them back. They had simply never been wired, and the absence had calcified into something that looked deliberate.

That is the failure mode I want to name for anyone building this kind of surface. An unexplained restriction is indistinguishable from an unfinished feature. The next engineer to read it, or the next AI agent to work in that file, cannot tell whether they are looking at a safety decision or a to-do, so they either break something that was load-bearing or preserve a limitation nobody intended. We classified all three as bugs and exposed them under the same allowlist as everything else.

A related thing surfaced in the same pass. We have a ladder of autonomy levels in the codebase, from proposal-only up to acting directly. It looked like it was holding. It was not consulted anywhere. It looked safe because the dangerous actions did not exist yet, which is not the same as being protected. Controls that have never been exercised are not controls. They are documentation with an inflated sense of itself.

Capability travels faster than control

The last finding is the one I would generalize furthest beyond us.

Six module types were reachable over the connector. All six are gated by subscription plan inside the app. The connector route consulted neither the feature gate nor the credit system. So the connector could reach plan-gated data with no plan check.

To be precise about the blast radius, because this matters: it was not a tenancy leak. Row-level security and membership checks held throughout, so nobody could reach another organization's data. It was a plan bypass. The wrong tier of the right customer.

But look at how it happened, because nobody was careless. We built a new front door. The old door had a lock. The new door was built by people thinking hard about protocol correctness, authentication, and data shape, and the lock was not part of any of those conversations. Controls do not travel with capability by default. They have to be carried, deliberately, every time you open a new surface onto the same data.

That is the pattern I would look for in any company shipping an AI integration this year. Not "is it authenticated", which everyone remembers. But: which of the checks the main application performs does this new path skip? Plan limits, usage metering, rate limits, audit logging, approval steps. Every one of those lives somewhere specific, and a new surface reaches the data without passing through any of them unless someone goes and gets them.

What we shipped

The connector now carries the feature gate and a pre-flight credit check, because connector access already is app access: same identity, same subscription. It reads the module types it should, with the columns that actually hold the content, rather than succeeding while returning nothing, which is the quietest way software can lie to you. It can write feedback, so human judgment captured through an agent flows back into the same loop as judgment captured in our interface. And action dispatch, the largest and riskiest piece, landed last and behind an explicit allowlist with the autonomy check finally wired to something.

The audit that started it was done by twelve agents working over our own codebase, which is its own small argument for the thesis: the tools are good enough now to find the gap between what your architecture says and what your code does, and that gap is where this class of problem lives.

None of this is a finished answer. The line between what an agent may do and what a person keeps is going to move as these systems get better, and it should. What I am confident about is the shape of the work: name the irreversible operations explicitly, hand the agent everything else, and write the reason next to every exception. A safety model you cannot enumerate is not protecting your customer. It is protecting you from having to decide.