Reflections on a year of building at the edge of AI and data security
Exactly one year ago, we launched Bonfy with a thesis: that the arrival of AI in the enterprise was not just expanding the data security problem, it was exposing how incomplete the existing approaches had always been.
We were not the first to say that AI creates new risk. That observation was everywhere. What we believed, and what this past year confirmed, is that the deeper issue is structural. The tools, the frameworks, and the assumptions that data security programs were built on were designed for a different world. AI did not break them. It revealed the cracks that were already there.
Here is what we observed, learned, and were surprised by over the last twelve months.
When we launched, the conversation in the market was almost entirely about Shadow AI, employees using unauthorized tools, sensitive data passing through unmanaged channels, governance gaps created by ungoverned AI adoption.
That risk is real. We are not dismissing it.
But in nearly every conversation we had with security teams over the past year, a different pattern kept surfacing. The more urgent problem was not the AI that security teams couldn't see. It was the AI they had already approved. Sanctioned copilots. Production deployments. Workflows that had passed review, and were still producing outcomes that violated policy, mixed up customers, or created compliance exposure.
We started calling this "Shady AI" to distinguish it from Shadow AI. The distinction matters because it demands a different response. You cannot solve Shady AI by improving visibility or tightening governance over which tools are allowed. You have to solve it at the level of what the system is actually doing, in real business context, in real time.
The industry was focused on the wrong problem. Not because the right people weren't paying attention, but because the category hadn't been named yet.
One theme appeared in almost every customer and prospect conversation we had this year, regardless of industry or company size: organizations already had too much to look at.
Alerts. Findings. Signals. The problem was not that they couldn't find things. The problem was that they couldn't act on what they found with any confidence. False positives created friction. Broad policies disrupted legitimate work. Teams tuned things down to avoid the noise, and in doing so quietly reduced their actual enforcement coverage.
This is a problem the industry had learned to live with. For years, it was treated as an inherent limitation of the domain, something to manage around, not solve.
AI removed that option. In automated workflows, there is no human in the loop to catch what the system gets wrong. If you cannot enforce accurately, you cannot enforce at all. The tolerance for inaccuracy that the industry had quietly accepted for a decade became impossible to maintain.
What this year taught us is that accuracy is not a feature organizations want. It is a prerequisite for anything that follows. No enforcement. No control. No real risk reduction. Not without it.
We spent a lot of this year in conversations about classification. Most organizations have invested heavily in labeling, tagging, and categorizing their data. And most of them have found that even good classification doesn't reliably produce the outcomes they need.
The reason is something we came to call the "who" problem.
Regulations are not written about data types. They are written about people, consumers, patients, customers, account holders. Customer trust is not violated when a pattern is exposed. It is violated when someone's data ends up somewhere it should not.
The same piece of content can be completely appropriate in one context and a serious breach in another. The difference is almost never in what the data is. It is in who it is about, who is sending it, and who is receiving it. Sender. Receiver. Referenced entity. All three matter. Traditional controls rarely reason across all three simultaneously.
This is not a new insight, but AI made it urgent in a way it had not been before. Copilots and agents aggregate data across silos, generate new derived content, and act at machine speed. In that environment, "what is the data?" is not fast enough, not precise enough, and not the right question. The question is: whose data is this, in whose hands, and does that use align with what the relationship between those parties actually allows?
That shift, from what to who, is one of the more important conceptual transitions the field is working through right now. We are glad we built around it from the start.
Early in the year, we expected the conversation about AI agents to be mostly theoretical. It was not.
By the second half of the year, organizations were running agentic workflows in production. And they were discovering something uncomfortable: their security architectures were not designed for environments where a user initiates a request and the actual execution happens somewhere else entirely.
A single prompt triggers multi-step workflows across retrieval systems, orchestration layers, external tools, and downstream services. The user sits in one place. The risk materializes somewhere else. Controls designed around the endpoint, the email gateway, or the SaaS boundary often observe fragments of this activity without seeing the whole.
We started describing this as the out-of-body execution problem. Attribution becomes less reliable. Inspection paths miss meaningful activity. Controls are simply in the wrong place.
The response we heard from security teams was consistent: they were not doing the wrong things. Their architectures were just built for a different operating model, and they were only beginning to understand how much had shifted beneath them.
This is where a significant amount of the next chapter of data security gets written.
As AI agent frameworks matured over the past year, most of the security attention went to configuration: what agents exist, what tools they can access, how they are permissioned. This is important work. It is also insufficient.
Configuration tells you what an agent is allowed to do in theory. It does not tell you what is actually flowing through it, what data it is retrieving, what it is sending out, what it is exposing to external services it communicates with in the process of executing a task.
An agent that is correctly configured can still mishandle sensitive data. A well-scoped retrieval pipeline can still return content that should not reach a particular output. A properly permissioned MCP server call can still carry information it should not.
The distinction we kept returning to: there is a difference between controlling what agents can access and securing the data that flows through them. The field has mostly been building the first. The second is where the actual exposure lives.
A few things surprised us.
That pattern shaped how we think about where Bonfy fits. We are not waiting at the security perimeter. We are increasingly part of how organizations move fast with AI without creating the kind of exposure they cannot walk back.
We launched Bonfy to prove that entity-aware, contextually grounded data security could work at the accuracy levels that enforcement actually requires. This year confirmed the thesis more thoroughly than we expected, and exposed corners of the problem we had not fully anticipated.
The work ahead is not a pivot. It is a deepening. Agents and autonomous workflows are not a separate problem from the one we set out to solve. They are the same problem, operating at greater speed and scale, with less margin for error.
The shift from human-dominated data flows to hybrid human-and-machine environments is not coming. It is here. The security architectures built for the last era need to be rebuilt for this one, not by discarding what worked, but by extending it to a world that looks fundamentally different from the one it was designed for.
A year in, we are exactly where we hoped to be: closer to the problem, clearer on the solution, and more convinced than ever that getting this right matters.