FAQ
This FAQ covers the technical questions buyers ask most often during evaluation, including deployment speed, performance overhead, how Hilt detects anomalous data movement and isolates the host at the network, supported environments, shadow AI detection, and how Hilt handles telemetry privacy.
This page answers the recurring technical questions buyers ask during evaluation: what Hilt captures and what stays in your own cloud, performance and footprint, the response model (host quarantine on cloud workloads, blocking or isolation on endpoints), detection quality, identity resolution, search and SIEM export, supported environments, EDR coverage, and compliance posture.
If you need a broader category framing, move to Compare Hilt. If you are evaluating a direct competitor, start with the Cyberhaven alternative guide. If you are ready to pressure-test the workflow in your own environment, book the walkthrough.
FAQ
No. By default the collectors capture how data moves, the process, the identity, the destination, and the shape of the transfer, not the contents of the file. It works the same way your bank flags the charge that does not fit without ever seeing what you bought. Your most sensitive data stays where it is. Hilt watches the pattern around it, not the payload inside it.
Metadata about movement. The collectors record the process, the identity behind the move, the destination, byte counts, and the shape of the transfer, not file contents. That is the resting state across cloud workloads and endpoints alike, single-tenant in your own cloud, so the pattern is legible without the payload ever being captured.
Yes. Content-aware inspection is a toggle you control. It runs single-tenant in your own cloud when a team turns it on. It is a choice you make, never the resting state. With it off, the collectors stay metadata-only, which keeps your most sensitive data where it already lives.
Your raw events and identifiers stay metadata-only and single-tenant in your own cloud account. To improve the detection model, Hilt continuously receives an anonymized aggregate signal, and nothing more. That signal is only aggregate statistical summaries and abstracted activity tokens, never filenames, IPs, hostnames, usernames, identities, resource IDs, rule names, or any content. Host and user IDs are remapped, timestamps are jittered, and any export covering fewer than five hosts is rejected. Everything is encrypted in transit and at rest, and a Hilt engineer can reach your environment only through your own approval workflow.
By default, your telemetry stays in your own cloud. Hilt runs single-tenant inside your account (AWS, GCP, Azure, Alibaba Cloud), the collectors are metadata-only and off the path, and in normal operation events do not leave the infrastructure you control. The collectors capture the shape of a move, the identity, process, destination, and byte counts, not file contents, so the resting state carries no payload anywhere.
Your raw events and identifiers never leave your account. The only data that reaches Hilt is a continuous anonymized aggregate signal that improves detection: aggregate statistical summaries and abstracted activity tokens, never filenames, IPs, hostnames, usernames, identities, cloud resource IDs, rule names, or any content. Host and user IDs are remapped, timestamps are jittered, and any export covering fewer than five hosts is rejected. Everything is TLS 1.2 or higher in transit and KMS-encrypted at rest, and a Hilt engineer can reach your environment only through your own approval workflow. So the honest procurement answer is that the only data reaching Hilt is a de-identified, aggregated signal carrying no content and no identifiers, which is what your subprocessor review should document.
No, and the difference is the question being asked. DLP asks "does this content match a rule," works in user space hooked into the apps and files it already knows, and goes blind to the script, the renamed binary, or the path nobody modeled. DDR named the prior category that reconstructs how tracked data moved, but it leans on the same user-space telemetry and stops at explanation. Hilt watches at the kernel, off the path, so the move is seen where it actually happens regardless of which process made it, and asks "does this movement match how this identity normally behaves." It is Agentic Data Movement Governance, the agentic successor to DDR: metadata-only by default, single-tenant in your own cloud, and the investigation writes a case instead of handing you a raw alert.
It does not slow the path, because the collectors run off the path, not in it. They watch movement and copy out metadata; they never sit between your workload and the wire, so there is nothing inline to add to the latency that matters, even under load. We built this for environments where microseconds are the product, so on the call we walk you through the overhead numbers and hand you the collector to run yourself against your own trading or inference path.
Small and checkable: roughly 0.1% of one core on average, well under 1% at peak, and 4 to 8 MB of memory per host. There is no kernel module, no reboot, and no listening ports. Quant and HFT teams can go deeper on the cloud feed, where we walk the exact overhead numbers and give you the collector to measure yourself.
Small and observable. The collector loads no kernel module, needs no reboot, and opens no listening ports, just one outbound HTTPS rule. It runs off the path, so it never sits between your workload and the wire. Footprint is roughly 0.1% of one core and 4 to 8 MB of memory per host. We will walk the exact overhead numbers and the collector you can run yourself on the call.
No. The collector is an anti-tamper control: it runs below the user and cannot be killed or paused from user space, so a kill -9 does not stop it, and neither does a root user or a process that escapes a container. Disabling it means breaking out to the host kernel, which is far harder than killing a user-space agent, and that escape is itself the kind of movement Hilt is watching for.
Generic rules fire on netflow or a content match and hand you a raw score to interpret. Hilt runs a Temporal GNN with proprietary ML on per-identity and per-workload baselines, so exfiltration patterns like read-then-send, sensitive-read-then-send, novelty bytes, and cross-cluster transfers are first-class in the models, not a rule someone has to remember to write. You can also write plain-language rules and backtest them against your own history before they ever page anyone.
Lower, because the agentic investigation does the triage itself and writes a case rather than dropping a raw alert on your analyst. The case carries a headline, what happened, why it is unusual, and the lineage tying the move to a real identity. That is the tax cut: your team confirms or dismisses a written narrative, and each verdict feeds back into the models so similar findings are suppressed next time.
Both. On user endpoints Hilt does everything an EDR does, threat and malware detection included, plus the data movement an EDR misses, resolved to a real person across the whole flow with lineage. Detection runs on per-identity and per-workload baselines with a Temporal GNN and proprietary ML, and the agentic investigation writes a case, not a raw alert.
Either way works. On macOS-compatible endpoints Hilt can stand in for your EDR; on cloud workloads it runs as its own layer. You can also keep an existing tool and run Hilt alongside it.
Hilt resolves identity from your own sources, Okta, Teleport, SSH, and the OS, then enriches each event into a unified actor with the identity source and a confidence level attached. Because the collector watches at the kernel, it ties the move to the process and workload that made it, then maps that to the real person across the whole flow where the source allows. So a finding reads as "this service account moved this much, to here, at this hour," not "something talked to a bucket." The same resolution carries workload context, the namespace, the pod, the container, and the job, so the actor and the path are both legible in one case. This is probabilistic and source-dependent, never an absolute claim on every byte: where a source cannot attribute an action, we show that honestly rather than guess.
Yes, and how depends on the surface, because the collectors never sit inline and never drop, filter, or alter your traffic. On cloud workloads, the response is host-level network isolation: the control plane quarantines that one host so the movement has nowhere left to go, never per-packet filtering. On endpoints, Hilt can go further and block the exfil action itself, the upload, the copy, the transfer off the device, or isolate the host, configurable observe versus isolate per node and per hour. Either way the response runs from the control plane, never a box in the middle of your production path that can fail closed on you.
It runs single-tenant inside your own cloud account (AWS, GCP, Azure, Alibaba Cloud, and more), and it understands cloud workloads as first-class: VMs, containers, and Kubernetes, plus macOS-compatible user endpoints. A finding carries its context where the source allows, the namespace, the pod, the container, and the identity behind the move, so it reads as "this workload, this account, this destination," not "something in the cluster sent data out." Your raw events and identifiers stay in your account, metadata only, with the collector off the path. To improve detection, Hilt receives a continuous anonymized aggregate signal, only aggregate statistical summaries and abstracted activity tokens, never filenames, identities, IPs, hostnames, or any content.
The deployment model is the collector running wherever you can place it and reach it from that account, rather than a separate on-prem appliance. If you have a fully disconnected or airgapped enclave, tell us its boundary on the call and we will tell you exactly what a collector can and cannot see there, rather than overpromise.
Yes. User endpoints are covered today on macOS, through a system collector plus a managed browser extension, metadata-only, so the researcher's Mac and the associate's laptop sit on the same plane as your cloud workloads. The move is resolved to a real person across the whole flow, from cloud to laptop to a personal cloud account and back, with lineage, and you get a live inventory of what is installed and running. The collector is tamper-resistant. On an endpoint, response is configurable per node and per hour: observe, isolate the machine at the network, or block the exfil action itself, the upload, the copy, or the transfer off the device. We do not sit inline and do not filter per packet.
Not yet. Coverage today is cloud workloads and macOS-compatible user endpoints, where the gap your EDR and DLP leave is widest. Windows is the next endpoint surface, and we are taking design partners for it now. If your fleet runs on Windows, say so on the call and we will put you on the list.
Yes, and from a vantage the app cannot dodge, because Hilt watches the move, not the app. Data pushed into a chatbot, an API call to a model endpoint nobody approved, a workload shipping records to an outside service: each one is a data movement before it is an "AI" event, and the collectors see it at the kernel regardless of which browser, extension, or binary made the move. By default this is metadata: the fact and shape of the movement, who, what, where, and how much, not the contents. You do not have to enumerate every AI tool your people might find tomorrow. The next one your team adopts is covered the day it moves data, not the day you write a rule for it.
Most of what looks SaaS-to-SaaS still starts as a movement on a host you instrument: the outbound connection, the paste into a browser, the API call from a workload. Hilt sees that at the kernel before the data leaves the endpoint or container, which is the one place you can still act on it. Here is the honest limit: when a transfer runs entirely inside other vendors' clouds and never touches a system you run, Hilt needs a collector on at least one side, the cloud workload or the macOS-compatible endpoint. We will not claim to sit inside every downstream vendor, because we do not. We govern movement at its source, not chase it through someone else's cloud.
Yes. Inside Hilt you search every move in plain natural language or any structured filter, and the agentic investigation does the first pass for you. It writes a case with the headline, what happened, why it is unusual, and the lineage, not a raw alert you have to reconstruct.
Yes. You can export findings and movement data to your own SIEM or observability platform, Prometheus included, so it lands wherever your team already works. Your raw events and identifiers stay single-tenant in your own cloud and metadata only; the only data that reaches Hilt is an anonymized aggregate signal that improves detection, never filenames, identities, IPs, or content.
Short, and scoped honestly. The collector installs with a single command per surface, no kernel module to compile, no reboot, no listening ports, nothing inline to thread through your production path, so most hosts are reporting in minutes. From that point raw telemetry, natural-language search, and your plain-language rules backtested against your own history work immediately; the per-identity and per-workload baselines that drive behavioral findings warm up over the first day rather than firing on minute one. This is not a quarter-long rollout to find out whether the architecture is real. Walk the cloud side on the cloud feed and the device side on the endpoint feed.
No, not yet. SOC 2 Type I is in progress, and we will not imply otherwise. What your review actually depends on is the architecture, not a vendor attestation.
On the architecture. Hilt runs single-tenant inside your own cloud (AWS, GCP, Azure, Alibaba Cloud). Your raw events and identifiers stay in your account, metadata-only, so the trust boundary your review cares about stays inside your environment. The one thing that reaches Hilt is an anonymized aggregate signal that improves detection: only aggregate statistics and abstracted activity tokens, never filenames, IPs, hostnames, usernames, identities, resource IDs, rule names, or any content; host and user IDs are remapped, timestamps are jittered, and exports below five hosts are rejected. Data is TLS 1.2 or higher in transit and encrypted at rest, and Hilt engineer access only happens through your approval workflow. Content-aware inspection is a choice you make in your own cloud, never the resting state, which keeps your most sensitive data where it already lives. For proof under NDA we can put you in front of design partners running Hilt in production, a quant fund and a fintech, and walk your security and compliance team through the controls on a technical call.
Those tools each answer a different question well, and none of them answers ours: is sensitive data moving somewhere it should not, right now. Wiz scores cloud posture and misconfiguration, Falco watches runtime behavior against rules you write, a DSPM tells you what data exists and where, and an EDR like CrowdStrike chases malware and threats on the device. Hilt is Agentic Data Movement Governance, the agentic successor to DDR, and its value lives in two layers you need together: collectors that watch the move at the kernel, below any app, SDK, or user-space agent, feeding detection that learns per-identity and per-workload baselines and writes a case across cloud and endpoint instead of one more alert. Kernel-level capture without that detection is just a faster firehose, and detection without it is only as honest as the telemetry it was handed; we own both ends. Hilt runs alongside posture and runtime tools like Wiz and Falco and a DSPM, and on macOS-compatible endpoints it can stand in for an EDR like CrowdStrike rather than just sit beside it; many teams retire their EDR once Hilt is in place, and keep one only if they also want the malware and intrusion layer Hilt does not cover.
Direct, and fast. You get a dedicated Slack channel with our team, not a ticket queue, and support is 24/7 with a response within the hour, any time, even at 10pm on a Sunday. The people answering know your deployment, so you are talking to an engineer who can act, not a tier-one script.
One model: per collector, per year, where one collector is one host or workload. The same unit covers cloud and endpoint, so you are not buying two products or reconciling two SKUs, and it scales with what you instrument. We size the rate on a call rather than a self-serve list page so it maps to your real footprint. The next step is a short technical call, engineer to engineer, no deck: we walk the actual overhead numbers, the deployment, and how response works on each surface. First deployment is a hands-on stand-up with our team in a cloud account you control, single-tenant, so you watch your own data move on your own infrastructure before you commit.