What DMZAgent is for, and what it deliberately is not.

The problem this product addresses.

AI agents now take actions that carry financial, clinical, legal, and reputational consequences. They move money, change records, call tools, and email customers — with real credentials and little supervision. The teams who run these agents are asked to answer questions they did not have to answer when their software only suggested, retrieved, or summarized.

The questions are not new. The setting is.

The questions are:

1. Why did the agent do that?Reproduce the decision with the evidence that produced it.
2. Where is the record?Produce a signed, time-stamped record that satisfies an audit.
3. Did the behavior change?Show that the agent is still making the same kinds of decisions it made yesterday.
4. Who decides if the agent may keep running?Make the policy that governs the agent visible and revisable.

The field has invested heavily in access control — identity, tokens, gateways, containment. Those decide whether an agent may act. They do not judge the behavior once it acts, and they do not produce a record you can defend to an auditor. Application logs are not built to answer these questions. Prompt-trace dashboards do not produce evidence packets. Most teams answer by hand, once per audit cycle, and start again the next quarter. DMZAgent exists so they do not have to.

One loop: observe, reason, act, review.

A DMZ is the inspected buffer zone between an untrusted network and the systems an organization trusts. DMZAgent is that zone for AI agents. Every action passes through it and is handled in four moves, all written to one hash-chained ledger:

1. Record.The action and the evidence behind it are captured and signed into the ledger. This is the observe step.
2. Recognize.The action is scored against the agent's own track record and your active policy. This is the reason step.
3. Enforce.If the score crosses your threshold, the action is held, rolled back, or allowed. This is the act step.
4. Review.Anything uncertain is routed to a person, whose decision is recorded and feeds back into the policy. This is the human-in-the-loop step.

Three modules do this work — Record, Recognize, and Enforce — and all three read and write the same signed record. Policy is expressed as Canons: the expected behavior for a domain, authored by people who know that domain, run as code against every action. DMZAgent compares an agent's trace — its behavior over time — against the Canon and flags where it deviates.

Behavior arrives through OpenTelemetry and connectors, so the definition of what can be watched stays broad: agents today, and the services, pipelines, and devices around them as needed. New subjects arrive as connectors, not rebuilds.

The unit of record.

DMZAgent records events. An event is a single action taken by, on, or about an agent. Each event carries:

1. The agent.Which agent took, requested, or was the subject of the action. Identified by a workspace-scoped subject identifier.
2. The action.What was done — speech, a tool call, a tool result, an observation, a policy check.
3. The evidence.What was retrieved, considered, or relied on to produce the action.
4. The risk tags.The risk dimensions the action touches — financial action, personal information, clinical decision, and so on. Tag schemas are defined per workspace.
5. The policy result.Whether the action was allowed, warned on, or blocked, and which policy fired.
6. The signature.A cryptographic signature so the record cannot be silently edited.

Events are written to an isolated workspace owned by the customer. The record persists for as long as the customer's retention policy requires.

What the record produces.

From the same signed record, DMZAgent maintains a live profile of every agent — what it does, how it does it, and where it is currently failing — produces forecasts of the agent's near-term behavior, and applies versioned policy across many agents at once. Record, Recognize, and Enforce all read one record. Nothing scores, forecasts, or enforces on data the ledger does not also hold.

The intended users.

DMZAgent is for the people who own AI agents in production and carry the consequences when those agents misbehave. In most organizations these are four distinct roles, all of whom read the same record:

1. AI platform engineers.Responsible for the agent fleet across teams and runtimes. They need one place to see every agent in production and to set what production-ready means.
2. AI risk and compliance officers.Responsible for satisfying internal and external audit. They need a defensible record that maps to the controls the auditor will ask about.
3. Site reliability and on-call engineers.Paged when an agent breaks or a customer escalates. They need to replay the agent's actions, not reconstruct them.
4. Security and procurement reviewers.Responsible for what the agent may do and where its data may live. They need the policy layer to be readable without translation.

DMZAgent is not aimed at end users. End users see the agent and the outcome. DMZAgent is the system the operators consult when the outcome is questioned.

What DMZAgent commits to.

Five commitments are built into the product. They are stated here because they are how the product should be judged.

1. Record before opinion.The system catalogs what happened before it asserts what should be done. Every claim points to the events that produced it.
2. Explainable, not opaque.The output is a reasoned, recorded judgment a supervisor or auditor can read back — not a score from a black box.
3. Open to inspection.Every record shows its provenance. Customers can challenge an entry by producing counter-evidence. The record revises; it does not entrench.
4. The system narrows; the operator decides.DMZAgent surfaces, scores, and proposes. People retain authorship of the decisions that affect a subject.
5. It compounds with use.A record of ten thousand events, with policies tuned against them, is worth more than a record of ten — and the value carries the switching cost.

What DMZAgent deliberately is not.

A record system is partly defined by what it refuses to claim. DMZAgent states the limits explicitly so that buyers, auditors, and end users can rely on them.

The frameworks DMZAgent maps to.

DMZAgent ships pre-mapped to common control frameworks. The same event record supports additional frameworks on request.

1. OWASP LLM Top 10.Risk-tag schemas import the OWASP LLM categories so findings line up with a list reviewers already use.
2. SOC 2 Type II.Common Criteria 7 (system operations), 8 (change management), and 9 (risk mitigation). Type II in progress; evidence available under NDA.
3. EU AI Act.Articles 12 (record-keeping) and 14 (human oversight). Pre-mapped crosswalk provided to auditors on request.
4. NIST AI RMF.Measure 2.1, Measure 2.3, Manage 4.1. Pre-mapped with self-attestation.
5. Section 508 / WCAG 2.1 AA.Adopted as a standing standard for all product surfaces and the customer-facing site.

What DMZAgent says, and what it does not.

DMZAgent does not state that the right answer is X. It states what the record contains on the question, what the policy required, and what is still missing. The operator retains the decision. The record retains the evidence.

We are deliberate about claims. Where a capability is live, we say so; where it is forthcoming, we say that too. The product earns trust the same way it asks customers to — on the record.

Begin a workspace at /trial, or contact [email protected] with questions.