Gidi recently published a Substack article about how vibe coders, citizen developers, and agentic engineers all converge on the same enterprise data exposure problem — regardless of how technically sophisticated they are, or whether they know they're creating a risk at all. He's right. But the natural follow-on question is: what does a security control actually need to do to cover all three? That's what we want to address here.

**********

TL;DR

In 2026, three types of builders are creating enterprise data exposure simultaneously, the vibe coder who doesn't know what they're exposing, the citizen developer who isn't thinking about boundaries, and the agentic engineer who is thinking about it and still creating it. The origin doesn't change the obligation. The data doesn't know who built the workflow, and the regulatory risk is identical either way. Enforcement has to live at the data layer, applied uniformly, regardless of who's building. That's the problem Bonfy is built to solve.

**********

The framing of three distinct builder personas is useful for understanding the origin of an exposure. It is not useful, by itself, for designing a control.

From an enforcement standpoint, a workflow built by a marketer who has never written code in their life and a workflow built by a senior engineer who has spent a week thinking carefully about permission scopes can produce the same outcome: enterprise data (customer records, regulated content, proprietary context) flowing through an AI system in ways that weren't intended, reviewed, or governed.

What differs is the mechanism. And the mechanism matters for how you build the control.

The Vibe Coder Problem Is a Context Problem

When a business user builds an automation using a no-code AI tool and instructs it to "pull the latest client notes and summarize them," three things happen in sequence that most security controls are not designed to see:

First, data is retrieved. Documents, records, and communication history are assembled into a prompt context. The retrieval scope is determined by whatever permissions the tool has, which in many cases reflects the user's own access — not a considered judgment about what the AI should see.

Second, that context is reasoned over by the model. The prompt context becomes part of the model's working state. At this point, sensitive information has already left its original location. It is now somewhere else: inside a model context, being actively processed.

Third, an output is generated. That output may contain derived information (synthesized, extracted, or reformulated) that is harder to trace to its source than the original records.

Traditional DLP was designed to catch step three. It can intercept an email before it leaves, scan a file share for sensitive patterns, flag a download. It was never designed to operate at steps one and two, because those steps didn't exist in the pre-AI workflow model.

Bonfy Adaptive Content Security™ (Bonfy ACS ™) is built to operate at all three. Input control governs what enters the agent context during grounding. Data-in-use inspection runs during the agent's reasoning process via our MCP server capability. Output control catches what gets generated before it reaches a downstream channel. For a vibe coder who has no mental model for any of this, enforcement has to work without their awareness or cooperation, which means it has to live in the infrastructure, not in the user's judgment.

The Citizen Developer Problem Is an Entity Problem

Citizen developers are not building blindly. They understand what they're configuring. What they typically lack is a way to reason about the relational risk of what they're building, not just whether a document is sensitive in isolation, but whether the combination of data the agent can access creates a privacy or compliance exposure when that data is assembled and acted upon.

Here's a concrete example of what this means. An operations manager builds an agent in Copilot Studio to help their team respond to customer inquiries. They configure it with access to the CRM, the ticketing system, and a shared document library. Each of those connections looks reasonable in isolation. But the agent now has the ability to assemble a profile of a customer, combining contact information, account history, support interactions, and internal notes, and present it in response to a question.

Whether that constitutes a CCPA exposure, a cross-customer data mix-up, or a regulatory violation depends on who the data is about and who is receiving it. That's not a question a pattern-matching tool can answer. It requires understanding the entities in the data: which customer, which account, which relationship, which policy governs how that customer's information can be used.

Bonfy's entity-aware engine was built specifically to answer this question. It maintains awareness of the people, customers, organizations, and relationships behind unstructured data, not just the data itself. This is why it can detect, for example, that information about one customer has been included in a response intended for a different customer, even when neither piece of data would trigger a keyword or pattern alert in isolation. For citizen developers operating at the intersection of multiple enterprise data sources, this is the control that matters.

The Agentic Engineer Problem Is a Scope Problem

For professional developers, the exposure is real but it works differently. They think about data boundaries. The problem is that their architectural decisions propagate.

When an engineering team builds an internal agent framework, they are not just building a tool for their own use. They are setting the data access ceiling for every workflow that will ever run on top of that infrastructure. The retrieval scopes they normalize, the permission models they establish, the MCP server connections they wire up, all of this becomes the de facto governance model for every downstream agent, including the ones built by the marketer and the operations manager we described above.

There is also a second exposure path unique to this persona: the development process itself. Engineers prompt AI coding assistants with production schemas, internal system architecture, real data structures, and sometimes live records, because that context is what makes the suggestions accurate and useful. That information enters external model contexts during the act of building. The data leaves the enterprise before a single line of production code is deployed.

For the second exposure path, Bonfy's coverage extends to the development environment, inspecting what enters AI coding tool contexts and flagging when production-sensitive information is being included. For the first, the architectural propagation problem, the answer is that enforcement has to sit at the data boundary, not at the builder. The framework that the agentic engineer builds may be careful. The workflows others build on top of it may not be. The control layer has to work regardless.

What This Means for the Platform Design

Gidi's article ends with the observation that security programs designed around a single identifiable developer population can't scale to this environment. That's exactly right. But there's a specific implication for platform design that's worth naming.

A control that works for vibe coders but not agentic engineers, or that handles output but not context assembly, or that sees email but not MCP server communication, creates the illusion of coverage while leaving real gaps. The three builder personas converge on the same data layer. The platform has to match that.

Bonfy ACS operates across the full data lifecycle in an AI workflow, input, in-use, and output — with the same entity-aware engine applied consistently across every channel. Microsoft 365, Google Workspace, Salesforce, Slack, ServiceNow, internal AI systems, agent frameworks, and MCP-connected services all run through the same policy and classification logic. The person who built the workflow and the tool they used to build it are not variables the control depends on.

One additional design principle that follows from this: enforcement has to work at enterprise scale without creating operational friction that causes teams to route around it. Bonfy's automation engine is built to let organizations define risk-based policies, blocking high-confidence, high-severity events automatically, logging medium-risk signals for monitoring without generating alerts, applying sensitivity labels back to source systems without requiring human review for every record. The goal is a system that security teams can actually operate, not one that generates alert volumes that make the coverage theoretical.