Building Security Telemetry for Intent
A new approach to telemetry collection designed to understand intent, enable real-time intervention, and secure both human and AI-driven work.
Security has spent decades generating telemetry. So much of it, in fact, that entire companies now exist solely to optimize how security data is routed, compressed, stored, and queried. We have become exceptionally good at moving logs around. What I find more interesting is that we rarely stop to ask whether the telemetry itself is still the right abstraction for the problems we are trying to solve.
I want to make the case that it is not, at least not for the problems that matter most now, and to explain how we approached telemetry differently when we built Ent.
Telemetry, reconsidered
Historically, structured logs made perfect sense. They were cheap to store, easy to search, and flexible enough to work across many different systems. A process starts. A user authenticates. A file gets written. A network connection occurs. We capture the event and send it elsewhere for analysis.
That approach worked well for a long time because most security problems were infrastructure-centric. We were largely trying to understand machines, networks, and software. But as security has shifted toward understanding users, intent, and behavior, the limits of traditional telemetry have become much more obvious.
Logs are summaries. They describe fragments of what happened, but rarely the full story.
Security became a correlation problem
This is one of the reasons security has been so difficult operationally. Important information is sparse and spread across dozens of systems. Authentication logs live in one place. Endpoint events somewhere else. Browser activity in another product entirely. SaaS audit logs in a different dashboard. To make sense of any of it, an analyst has to understand not only how each system works, but what the logs actually contain and how they relate to one another.
Even experienced analysts struggle with this. Over time, the industry accepted the complexity as normal and built workflows around it. Correlation engines, SIEM pipelines, and detection logic all emerged to stitch disconnected observations into something useful. Yet even with all of that infrastructure, most security teams still operate reactively, because the telemetry itself arrives after the fact.
If your product depends entirely on telemetry generated by someone else, you inherently limit your ability to intervene. Your visibility is constrained by whatever the operating system, the browser, or a third-party product chooses to expose. And telemetry has to be generated, forwarded, processed, and analyzed before any decision can happen. By the time a system determines that something risky occurred, the action has often already completed. The file is already uploaded. The credentials are already stolen. The data is already outside the organization.
Starting from the operating system
At Ent, we approached this differently, because our focus is preventing risky actions, mistakes, and attacks before they happen. To do that, we concluded we needed to deploy where the work itself occurs and model interactions directly at the operating system layer. And to understand intent, we needed to collect our own telemetry.
Our telemetry is centered on interactions with the operating system: clicks, focus changes, clipboard actions, file access events, and other behavioral signals captured in real time. More importantly, we do not treat those actions as isolated events. We collect the semantic context around each one: who performed it, when, which application was involved, and the content that helps explain what was happening at the time.
Years ago, a traditional log might have represented this as little more than a mouse event tied to a timestamp. Today, we can understand that a user copied sensitive financial information from an internal system, switched focus to a personal email account, and attempted to upload the contents externally. The interaction itself matters far less than the context surrounding it.
Staying at the edge also changes what we have to move and what we can keep. Because we collect and reason about telemetry on the endpoint, the data does not have to leave the device to be useful. That is a practical advantage before it is a privacy one: less data in transit means lower bandwidth, lower storage cost, and no saturation from shipping everything to a central store.
Telemetry collected staying at the endpoint is a privacy advantage. Organizations can preserve sensitive behavioral data without taking on the risk of warehousing all of it outside the boundary. And it is configurable. A customer can choose to send everything back, or only the data involved in a detection, depending on their own risk and compliance posture. When something does happen, none of that visibility is lost. Security teams can still reach back to the endpoint to collect the full context an investigation needs, on demand, rather than paying to stream it continuously just in case.
Detection alone is not enough
Collecting our own telemetry also puts us in the best position to analyze and act on behavior directly at the edge. Ent continuously evaluates this real-time stream of activity to determine whether an intervention is necessary. When risky behavior is detected or a policy is violated, the platform can respond directly on the endpoint.
We call these actions interventions.
Some are silent. Capturing a screenshot, collecting additional forensic detail, or terminating a suspicious process can happen without interrupting the user. Others are intentionally visible. We can flash the screen, play a sound, suspend an action, or overlay directly on top of an application to collect more information from the user before letting them proceed.
If Ent had been built entirely on traditional logs and delayed event pipelines, much of this would not be possible. We would not be able to evaluate behavior while it is actively occurring, and we would lose the ability to prevent an action before it completes.
AI agents extend the same model
The same concept extends naturally to AI agents. Traditional telemetry models were never designed for agentic systems, because those systems largely did not exist. For us, agents fit naturally into the telemetry model we already built, because their goals, instructions, and actions are inherently semantic.
Instead of trying to infer intent from sparse machine events, we can directly observe the relationship between the user and the agent: what the user asked the agent to do, which systems the agent touched, and the sequence of actions it took along the way.
This matters more as agents gain broader access to enterprise systems and begin operating with greater autonomy. Our behavioral modeling applies across both humans and agents, so we can understand how work is actually happening across the enterprise and identify unusual or risky behavior as it unfolds.
Rethinking telemetry for AI-native security
As AI continues to reshape how people work, I expect the security industry will need to revisit many of its historical assumptions about telemetry and detection architecture. The older model, collecting sparse machine-generated logs and reconstructing behavior afterward, worked reasonably well for infrastructure monitoring. It is far less effective for understanding intent-driven interactions between users, applications, and autonomous agents operating in real time.
For us, building telemetry from first principles was never about collecting more data. It was about collecting the right data, in the right place, with enough surrounding context to understand intent and take action before risk becomes impact.
To learn more about Ent and our vision for securing human and AI-driven work, visit ent.ai.
Follow us on X and LinkedIn. To talk to us and see our product in action, schedule a demo.