For AI agents and MCP servers

Prove your agent can't walk the code out.

Hilt governs data movement for AI agents and the MCP servers around them. Your agent has repo access; the reviewer wants proof it cannot move the source somewhere new. Hilt watches the process behind each permitted tool call at the kernel, resolves it to a real identity and job, and stays off the agent's path without ever reading your source.

Govern what your agents move, not what they are scored on

Your agent has legitimate repo access. The reviewer's question is whether you could tell if it walked the code out.

Three sources, one shape, and the permission is correct in all three:

  • A service account used against you. Legitimate repo access on a service account, used to clone source to a personal device and delete the logs behind it. This is the xAI v. Li shape: the permission was right, only the behavior changed.
  • The MCP layer your own product ships. A stolen OAuth token, a popped dependency, or a server quietly BCC'ing data out. You granted that access on purpose, and now it is moving customer code.
  • A prompt-injected or over-permissioned agent. An agent acting on untrusted PR or issue content, behaving like a misaligned insider. Legitimate access, unauthorized act.

Why guardrails and cloud logs do not answer it

Prompt-layer guardrails score what an agent is likely to do before or around the model call. A score is a hope, not a record of what the process behind a permitted tool call actually moved. Cloud audit logs reconstruct the move in the post-mortem, with minutes of lag, buried in volume, and never from inside the VM: they arrive after the code left.

Hilt watches the movement itself at the kernel, resolves it to the identity and the job, and never reads your source. Metadata only, off the agent's path, single-tenant in your own cloud.

Prove it on your own cluster: bring your fleet and we will bring the teardown.