By Dr. Adi Hod, Founder & CEO, Velotix
Building a strong platform is as much about deciding what not to build as it is about adding capabilities.
That sounds obvious written down. It is considerably harder in practice, because the adjacent problems are always tempting. Data security touches discovery, classification, cataloging, lineage, posture management, identity, encryption, and a dozen other domains, and every one of them contains real customer pain. The pull toward solving all of it is constant.
Over the past year we narrowed instead. Not because the adjacent problems stopped mattering, but because real enterprise deployments kept pointing at the same few places where the friction is worst: the points where data access, security, governance, and actual data use collide. This is what we learned there, and what it cost us to act on it.
Problem One: Connected Is Not the Same as Complete
The first theme was reliable data discovery, and it surfaced in a way we did not anticipate.
Discovery, on paper, is a connectivity problem. Point the platform at a data source, authenticate, scan, classify. The status indicator turns green and the work is done.
What deployments taught us is that successful connectivity does not guarantee that the underlying work has completed. A connector can report a healthy state while the scan behind it is partial, stalled, or quietly behind. And from the outside, those two conditions look identical.
That gap matters more than it first appears. Every downstream decision in a governance platform inherits the discovery layer’s assumptions. If classification is incomplete, policy is written against a partial map. If policy is written against a partial map, enforcement is confidently wrong. The failure does not announce itself as a failure. It announces itself as a system that appears to be working.
Underneath the specific bug was a design assumption worth naming: we had treated connection state as a proxy for completion state. Those are different things, and conflating them meant the platform was reporting on its own availability rather than on the truth of the data landscape it was supposed to describe.
So we replaced the original discovery implementation rather than patching it.
That decision was not free. It meant writing off engineering investment that worked, in the narrow sense that it ran and did what it was built to do. The problem was not that the implementation was broken. The problem was that it was built around the wrong question.
The replacement reports on the state of the work rather than the state of the connection. That distinction sounds small and changes what the rest of the platform can rely on: policy written against a discovery layer that knows what it has actually finished is policy written against something real.
Problem Two: Access Control Is Not Just Granting
The second theme was getting access permissions right. The plain-language version customers kept returning to was controlling who could access what.
Access control, in most organizations, is heavily weighted toward the moment of granting. Request, review, approve, provision. That is where the tooling lives, where the audit attention goes, and where the workflow is most mature.
Deployments made clear that the grant is the easy half. Access control also needs to cover changing permissions and withdrawing access, and those are where real environments break down. People move between roles and accumulate entitlements nobody revisits. Projects end without anyone closing the permissions they opened. Contractors finish. Teams reorganize. The org chart moves continuously and the permission set does not move with it.
The result is that an access model can be correct on the day it is provisioned and wrong within a quarter, without a single incorrect decision having been made. Nothing went wrong. Things simply changed, and the permissions stayed where they were.
This reframed how we think about what an access control system is for. It is not primarily a mechanism for saying yes. It is a mechanism for keeping a continuously accurate picture of who should have access right now, which means change and revocation deserve the same rigor that granting has always received.
We expanded access controls accordingly, extending coverage beyond the point of approval to the full lifecycle of an entitlement: detecting when a permission no longer matches the role behind it, and supporting withdrawal as a first-class operation rather than an administrative afterthought.
Problem Three: Change Without Disruption
The third theme was making deployment and upgrades more predictable, and the customer framing was consistent: avoiding disruption when making changes.
This one arrived with less drama than the others and turned out to be just as consequential. A governance platform occupies an unusual position in an enterprise stack. It sits between users and their data, which means that when it behaves unpredictably during an upgrade, the blast radius is not a feature. It is access itself.
We updated underlying components to support more reliable operation, including changes to part of the messaging architecture. As with discovery, this meant letting go of existing engineering investment where a different approach was needed.
What made this worth the cost was a realization that connects all three themes: trust in a governance platform depends on consistent, visible behavior far more than it depends on capability breadth.
A platform that does ten things reliably is more valuable than one that does thirty things with occasional silent gaps, because governance is a domain where confidence is the product. An organization that cannot trust what the system reports will fall back on manual verification, and manual verification eliminates every advantage the platform was bought to provide.
That principle is what made the deprioritization decisions possible. Once trust is the measure, adding surface area stops looking like progress.
Where This Leads
The same lessons are now shaping the next evolution of the platform, and the timing is not incidental.
Access to enterprise data is increasingly initiated not only by people and applications, but by AI systems and autonomous agents. That shift changes the question governance has to answer. It is no longer sufficient to decide who can access data. The problem becomes continuously understanding and controlling who or what is using the data, for what purpose, under which context, and what they are permitted to do with it.
Every lesson above applies directly. If connection state was a poor proxy for completion state, an agent’s authentication is a far poorer proxy for what that agent is actually doing. If human permissions drift out of alignment within a quarter, agents that are created, cloned, and retired within minutes will drift far faster. And if trust depends on consistent, visible behavior, then an autonomous requester operating without visible behavior is the hardest trust problem in the stack.
The direction we are working toward follows from that: agent registration, so that an autonomous requester has a known identity and a known authorizing party; activity monitoring, so that what an agent does is observable rather than inferred; and controls to restrict or revoke access, so that the revocation lesson from human access control carries forward into agentic access. This work is at the concept and prototype stage today, and we would rather describe it accurately than prematurely.
None of it would be worth building on a foundation we did not trust. We spent the past year rebuilding the foundations of trusted, continuous data access governance – and those foundations are now becoming the basis for governing AI agents.
See how Velotix handles data access governance in your environment – book a demo.
