Rebuilding the Judgment Layer Your AI Agents Never Inherited

TL: DR

When an enterprise points an AI agent at its repositories, the agent inherits the access a human had but not the judgment, whose data this is, what relationship it represents, and whether using it here makes business sense. That judgment was never about what the data is; it was about who it belongs to and what the relationship allows, a dimension we call The Who, because relevance is not permission. Bonfy rebuilds that judgment layer at the data boundary, on one engine, in three places: inbound, where Contextual Data Enforcement decides what an agent may use and not just reach; in-use, where a Bonfy MCP server gives a real-time, entity-aware verdict inside the reasoning loop before the agent acts; and outbound, where output is inspected before it leaves. Rather than govern agent configuration or just log traffic, Bonfy governs the data itself and the relationships that make a given use appropriate. The access transferred; the judgment didn't. Giving it back is what Bonfy is for.

************

There is a sentence in Gidi Cohen’s latest Substack article (AI Agents Inherited Your Data. Not Your Judgment.) that we keep coming back to: the access transferred, the judgment did not.

When an enterprise points Claude, Copilot, Agentforce, or a custom MCP-based workflow at its repositories, the agent inherits everything the human could reach. What it does not inherit is what the human never had to write down, the understanding of whose data this is, what relationship it represents, and whether using it in this context, for this purpose, makes business sense.

That understanding was the judgment layer or think of it as the Enterprise Contextual Intelligence layer. Nobody built a replacement when the human stepped back. Bonfy exists to build it. The previous article named the gap; this one is about how we close it.

Judgment is not a label. It is context about the "who."

Traditional data security is organized around one question: what type of data is this? Is it PII, PHI, PCI, confidential? Pattern matching and classification engines answer that, and for structured systems they answered it well enough.

But the judgment a human carried was never primarily about the what. It was about the who: who the data is about, who is sending it, who is receiving it, and what the relationship between those parties allows. The same customer record is routine business when it goes to the policyholder, appropriate when it reaches the underwriter, and a reportable incident when it lands in the wrong customer's inbox. Nothing about the data changed. The who changed.

This is the dimension we call The Who, and it is the substance of judgment. An agent can correctly identify every entity and fact in a piece of content and still make the wrong call about whether it should be shared, because relevance is not permission. AI systems optimize for relevance. They are not built to understand appropriateness.

So giving the reasoning loop judgment means something specific: giving it entity- and attribution-aware context, who owns this data, what obligations attach to it, whether this counterparty relationship makes the use appropriate, and giving it that context as a decision input, not as an after-the-fact alert. Bonfy's platform is built around a knowledge graph of those entities and relationships, which is what lets it reason about a transaction the way the absent human used to.

Enforcement belongs at the data boundary — and so does Bonfy

The judgment gap lives at the data boundary: where the human used to stand, where the agent now arrives with access and instructions and nothing else. Enforcement has to operate there, uniformly, regardless of who built the workflow. That is exactly where Bonfy operates, and because data crosses that boundary in both directions, we cover both, plus the reasoning in between.

• Inbound — governing what the agent is allowed to use, not just what it can reach. When an AI client connects to SharePoint or Google Drive, it authenticates as the user and inherits whatever that user could see. Access becomes the only gate, and access was never the whole policy. Bonfy's Contextual Data Enforcement capability sits as an enforcement layer between the AI client and the repository. Retrieval requests pass through it, content is inspected against the entity context and obligations surrounding it, and data that should not be used in this interaction simply comes back as unavailable, the same engine and policies we already run, now deciding use, not just access. It deploys as a connector, with no new gateways or proxies in front of your data, and never exposes anything the user could not already see.
• In-use — judgment inside the reasoning loop, before the decision. This is what the thought leadership piece kept pointing at: context has to arrive inside the loop, before the decision is made. Bonfy provides its own MCP server that the agent calls mid-reasoning. The instruction lives in the agent's prompt, do the task, but verify with Bonfy that the content carries no high-risk customer data before sharing it. The model calls Bonfy during execution, receives a risk rating and entity-aware assessment in line, and uses it to proceed or adjust. The agent makes a business decision instead of merely a retrieval decision, because for the first time it has what it needs to make one.
• Outbound — checking the outcome against intent. Whatever the agent produces, an email, a file, a response, is inspected before it leaves, so that context drawn too broadly, or two customer relationships that should never have been combined, is caught at the edge rather than discovered later.

Three points on one boundary, governed by one engine. These are not three products bolted together but different facades (MCP server, REST API, connector) onto the same platform and the same policies, so the judgment stays consistent across all three.

Why this is a data problem, not a configuration problem

Most of the AI-agent security market is converging on configuration: what agents exist, how they are set up, which tools they can call. That work is necessary, but it is blind to the failures the previous article described, because those failures do not come from misconfiguration. They come from authorized agents, on trusted platforms, combining legitimately accessed data in ways policy would have constrained had anyone evaluated the relationships involved. Nothing breaks. Nothing alerts. The configuration was perfect.

Channel visibility has the same limit. Logging that an agent retrieved a record tells you traffic occurred, not whether that retrieval was appropriate for the relationship it served. That judgment was always the human's contribution, and it is precisely what a monitoring layer is not designed to make.

Bonfy looks instead at the data flowing through the system, and at the entities and relationships that determine whether each use of it is appropriate, regardless of how any agent is built. That is what lets enforcement stay uniform across the vibe coder's quick automation, the citizen developer's no-code agent, and the platform team's production framework. They all converge on the same data boundary. We govern the boundary.

The shift, in one line

The harder question is no longer is this data sensitive? or even can this user access it? It is is this use of this customer's data, in this context, for this purpose, appropriate?

That is a judgment. The human used to make it without being asked. The agent cannot, until something gives it the context to do so.

The access transferred. The judgment did not. Giving it back, at the data boundary, inside the loop, grounded in who the data actually belongs to, is what Bonfy is for.