Governance You Didn't Design: Why Your Claude Project Can't Answer Its Own Access Questions

Somewhere in your organisation, a team gave a Claude or ChatGPT project access to a batch of customer transcripts, support tickets, maybe a CRM export, because someone needed an answer fast and the demo looked clean. Nobody held a meeting about who else could see that data. Nobody wrote down a retention period. It worked, so it stayed.

Then, months later, someone asks the question, who can actually see this, why can they see it, and when did we decide that was acceptable? If your honest answer is "I'd have to go and check," you're not really in control of the thing you built.

We've got a content theme called "the prototype trap" for a reason, a working demo and a working system are different claims, and the gap between them is where most AI initiatives quietly stall rather than fail. Governance is where that gap is widest, because it's the part of the build that produces nothing demoable. Nobody shows a stakeholder a access control list in a stand-up. So it gets built last, if it gets built at all, which means, in practice, it gets built after something has already gone wrong.

Only today in the UK Brad Smith of Microsoft made comments that

'AI is less regulated than milk'.

The industry number, and then the harder one

Across the market, roughly 53% of organisations that deployed AI agents without governance infrastructure built in from day one have already experienced a permission breach*. That's not a rounding error, and it isn't a warning about some hypothetical future state, it's a description of what's already happened to more than half the field.

Gartner's own forward-looking figure is much starker. They predict that by 2029, at least 70% of organisations running production agentic AI in infrastructure and operations will experience a material service, security, or cost incident linked in part to insufficient runtime controls. Read that figure the way a board would, not as a prediction about AI in general, but as a prediction about the specific system your team stood up in a weekend and never revisited. Gartner's separate analysis of agent oversight adds, 75% of organisations report unauthorised use of AI coding assistants, and 50% report employee access to public SaaS GenAI platforms that nobody provisioned through a formal process. The pattern across both pieces of research is the same, the access question isn't being asked up front, so it gets answered later, under worse conditions, by someone other than the person who should have decided it.

Access control that nobody drew a box around

This isn't abstract for us. One Four/Four customer told us directly about "a recent acute challenge related to the access and management of sensitive data, specifically around PII and GDPR requirements, which led to disruption in team workflows until access was restored".

This is a story about a perfectly reasonable default, "everyone in the workspace can see everything in the workspace", that nobody chose, because choosing it would have meant stopping to design something before shipping the thing that was exciting. We hear the same instinct from customers who are still ahead of the problem rather than behind it. One account was explicit that it needed "role-based access permissions for meeting recordings so that only designated team members can view specific conversations... to control who in the company can view sensitive customer interactions and protect information confidentiality", asked for before go-live, not after an incident. That's the difference between governance as infrastructure and governance as apology.

The provenance problem: can you show your work?

There's a second, quieter failure mode sitting underneath access control, and it surfaces the moment anyone senior asks where a specific claim actually came from. We've heard this from our own customers, one told us that they "require Four/Four to provide traceable, evidence-led feedback that can justify product decisions to the board and demonstrate impact on revenue". Another was specific about the mechanism, asking for "traceable and timestamped citations that support its insights, allowing users to verify recommendations based on historical customer interactions", and a third wanted the system itself to "perform a fact check against the original source of truth after generating outputs," so a summary could be trusted rather than merely plausible.

A hand-rolled Claude project can produce a confident-sounding answer in seconds. What it generally can't do, without deliberate engineering nobody budgeted for, is show its working six months later when a board member, an auditor, or a regulator asks where a specific number or quote actually came from. "The model said so" is not a citation. If your team can't reconstruct, on demand, the exact call, ticket, or transcript line behind an insight that's already shaped a roadmap decision or a board deck, you have a governance gap even if you've never had a breach, it just hasn't been tested yet.

A sixth question

In another of our articles, we set out a five-question test for telling dabbling from doing: taxonomy, governance, ownership, resilience, and trend. Everything above points to a sixth, specific enough to ask in a single meeting, Provenance. If a board member, auditor, or regulator asked where a specific insight came from, could you show them in minutes, or would someone need days to reconstruct it from memory and old Slack threads?

If the honest answer is the second one, you don't have a governance incident yet. You have an unpriced liability, sitting quietly on the same system that's already shaping decisions you're prepared to defend in a board meeting you haven't had yet.

Doing looks different, access designed around roles before the first sensitive transcript is uploaded, not after someone notices who's been listening; a system that can produce the source behind a claim as easily as it produced the claim; and governance treated as a precondition for adoption, the way the most sophisticated teams in our own customer base already treat it, rather than as the thing you bolt on once a workflow has already been disrupted. That's not a compliance nicety. It's the difference between a system your board can rely on and one you're hoping nobody asks about.

*The SaaS Library 2026