Built for teams with rules to follow.

How policy is applied

DMZ Agent holds the rulebooks the people who own them write, and reads what your agents do against those rules. Enforcement sits between your fleet and everything it can reach, in the agent's own runtime, so an action a policy forbids is refused before it happens rather than reported after it.

• Before a task starts. The agent's brief, its budget and the part of the codebase it may touch are all checked against policy.
• While it runs. Actions that need a human decision stop and route to the right approver rather than proceeding.
• After it lands. Incidents and remediations are recorded together — which rules tripped, which policies were in force, and whether the remediation worked — alongside the full record of what was read, written and decided.

What reads your memory, and on whose instruction

Two things read what your agents write. The nightly review that keeps your memory true, and the compliance checks you asked for. Both work against rules you wrote, using model credentials you supplied, so every read is one you asked for and paid for at your own provider's rates. Nothing is read to train anything, and nothing is read on our account.

Isolation you can point at

Each project runs in its own space with its own keys. One project's agents cannot read another project's memory, and the systems that handle accounts and billing have no path to read the contents of any space at all.

Where your data lives

On the managed service, your memory is stored in the region you choose. On a self-hosted deployment it never leaves your infrastructure. In both cases you bring your own model credentials, so inference goes to the provider you have already approved.

For specifics on our controls and reporting, see Security, or talk to us about your review process.