vortx-ai/emem/emem-guard

Self-host emem-guard

You are the operator. An agent with a shell can follow this procedure unattended, in one session. Each step gives a command to run and a check to make. If you cannot run a step exactly as written, this file has a defect. Report the defect. Do not improvise around it.

What you are building

Four diagrams show the shape before the commands do:

• nine checkpoints, one decision
• one verdict, in order
• the chassis your DLP runs on
• three deployments

The server answers one question: can this prompt continue, given the claims it makes about the physical world? It returns allow or deny and signs the verdict. It appends the verdict to a log before it answers. Someone who does not trust you can then verify the decision later.

It is not a DLP scanner. It does not classify content. It checks whether the emem: citations in a transcript still verify. As an option, it also checks whether measurable claims about places carry a citation at all.

Before you start

You need:

• Rust 1.91 or newer (rustc --version).
• Nothing else to run it locally.

The Anthropic Enterprise checkpoint needs more. It needs a public HTTPS URL on port 443, with a certificate that the public CA trust store accepts. That platform refuses private, loopback and carrier-grade NAT addresses when it connects, and it does not follow redirects. The open routes have no such requirement: localhost is fine.

You do NOT need an emem account, an API key, or network access to emem.dev.

Step 1: build

git clone https://github.com/Vortx-AI/emem
cd emem
cargo build --release -p emem-guard

Check: the build exits 0. If it fails on ort-sys or a GPU crate, you built the wrong package. -p emem-guard pulls no inference dependencies.

Step 2: run the tests before you trust it

cargo test --release -p emem-guard

Check: every test passes. The crate source holds 143 tests (counted on 7 November 2026: 123 #[test] and 20 #[tokio::test], none ignored). These are not smoke tests. The platform documentation names two common signature-verification mistakes: a hash over a re-encoded body, and a secret decoded with a URL-safe alphabet. Tests cover both and fail if either comes back.

Do not skip this step because the build succeeded. A guard that compiles and verifies signatures incorrectly accepts requests from anyone.

Step 3: start it

./target/release/emem-guard --data ./var/guard

On the first run it makes a node key with mode 0600, opens a log, and starts to serve. The default listen address is 127.0.0.1:8080. The startup banner tells you the most important fact:

  resolve  null
           no responder configured: citations are not verified, only logged.

A bare node holds no corpus. It signs and logs every verdict, but it verifies no citation. This is correct behaviour, not a broken install. The node still keeps a signed, append-only record of every decision.

To make it verify citations, point it at a responder that holds facts:

./target/release/emem-guard --responder https://emem.dev

Check: http://localhost:8080/health reports "verifies_citations": true.

Step 4: learn the whole contract in one request

curl -s http://localhost:8080/.well-known/emem-guard.json

This document lists every route, deny code and remedy, the reason grammar, and the rules that are on. To integrate, read that document; you do not need the rest of this file. The node itself serves the document, so it always matches the binary.

Step 5: pick your checkpoint

A checkpoint is any place where your system stops and asks whether to continue. The node serves nine verdict routes, and all of them use the same engine. POST /verdict/native is a second name for POST /verdict. Two are specific to one vendor and seven belong to nobody. That is deliberate: a gate that only one company's product can reach is a gate for that company's customers only.

The simplest integration works from anything that can send an HTTP request:

POST /verdict HTTP/1.1
Host: localhost:8080
Content-Type: application/json
 
{"texts":["Elevation there is 918 m per emem:fact:defi.zb493.xuqA.zcb5f:abc123"]}

Check: HTTP 200 and a JSON body with action, checked and leaf.

Gate MCP tool calls

MCP is an open protocol with many independent hosts, so this option works in the most places. Put a proxy between your host and its servers. Before the proxy dispatches tools/call, it sends this:

POST /verdict/mcp HTTP/1.1
Host: localhost:8080
Content-Type: application/json
 
{"jsonrpc":"2.0","id":7,"method":"tools/call",
 "params":{"name":"read_file","arguments":{"path":"notes.md"}}}

On allow: false the response carries result, already in the shape of a CallToolResult with isError set. Return it instead of running the tool. The model then sees the denial and the remedy where it already reads errors. Your proxy does not need to know the reason grammar.

You can also gate the other direction, which most systems miss. Send params.result instead of params.arguments. The guard then catches a fabricated citation when it enters the context. Without this, you catch it one turn later, after the model has already reasoned on it.

Step 6: verify the failure behaviour yourself

Most integrations get this step wrong. Check it. Do not assume it.

A webhook failure is not a deny. Your server can return a non-200, time out, or send a body that does not parse. In each case the platform applies your organisation's failure-handling setting instead of your verdict. If that setting is "allow the request", the prompt goes to the model without a check.

So your server must answer 200 with a well-formed verdict in every case. This includes requests that it does not understand. Confirm that your deployment does this:

POST /verdict/anthropic-hook HTTP/1.1
Host: localhost:8080
Content-Type: application/json
 
{"type":"some_event_type_that_does_not_exist_yet","request_id":"probe"}

Check: HTTP 200 and {"action":"allow"}. A 4xx or 5xx means that real traffic will trip the circuit breaker, and then the deployment stops enforcing.

Step 7: know what it blocks and what it does not

Read this before you turn on enforcement. The defaults are deliberate.

On by default:

• provenance: a cited token whose signature fails, or that resolves to

different bytes than the transcript claims. Deny codes PROV_SIG and PROV_BYTES.

• freshness: a cited reading that has drifted past its band threshold.

Deny code PROV_DRIFT.

Off by default:

• geo_restriction: needs your own list of cell64 zones, given with

--restrict-cell. It uses exact match only, never a geocode. A fuzzy resolution that lands on the wrong place would block innocent work with confidence.

• claim_gating: see the next step. It denies when a citation is ABSENT.

Never a denial, whatever you configure:

• A token that this node has not cached. The node cannot tell it apart from a

token that another responder minted. A block on it would deny honest agents because they cite something you have not seen.

Step 8: measure claim gating before you enforce it

claim_gating is the only rule that fires on something missing, not on something that failed. It denies a sentence that states a measurable quantity about a place or a time when the transcript cites nothing at all.

Do not turn it on directly. First run it in shadow mode. In shadow mode the node evaluates, signs and logs every rule, but it blocks nothing:

./target/release/emem-guard --claim-gating --shadow --data ./var/guard

Send it a week of your own traffic. Then read the result from disk:

./target/release/emem-guard --report --data ./var/guard

The report looks like this (example values, not a measurement):

verdicts           4210
blocked            0
would have blocked 37
fired rate         0.0088
by code            enforced / observed
  CLAIM_UNGROUNDED        0 / 37

would have blocked is the number you decide on. It comes from the same append-only file that an auditor reads, not from a counter in memory. So the figure you quote internally is the figure an outsider can verify. The node also serves the same numbers live at GET /log/report.

When you accept the rate, remove --shadow.

For reference, on 6 August 2026 the detector fired on 3 of 8739 sentences in this repository's own documentation (source: src/claim.rs). Two of the three are the crate's own positive test fixtures. That is one input, not a licence. Your traffic is different from this documentation, so measure the rate where the gate will run.

Step 9: plug in your own detection

emem-guard checks grounding. It does not detect content. The one built-in module, secret-patterns, finds only fixed-prefix credential shapes (AWS, GitHub, Google) and PEM private-key headers. It is a reference module, not a DLP product. What the node adds is a signed, hash-chained record of each verdict that anyone can check offline.

So bring your own detector. The node signs and logs a module's verdicts in the same way as a native verdict.

./target/release/emem-guard \
  --module secret-patterns \
  --module webhook:https://your-classifier.internal/scan

curl -s http://localhost:8080/modules

Each entry in modules carries id, latency_class, can_block and observed.

Two declarations decide where a module can run. The node does not take either declaration on trust.

Latency: a module that declares slow never runs on the enforcing path. The node evaluates, signs and logs it, but it cannot block. A module that declares fast gets a 50 ms budget. After three overruns the registry demotes it to shadow, and it stays there. /modules then shows "demoted": true. The node measures this; it does not believe the declaration. A module that misses the deadline causes a transport failure. A transport failure gives the decision to your failure policy. It also trips the breaker that stops all enforcement.

Data: a module that declares digests_only gets an empty transcript. The node does not ask it to ignore the text. It gives the module a different slice, so the module cannot read text. Add --modules-no-text to give every module an empty transcript, whatever it declared. Use this for a relay where text must not cross a boundary.

Write a module

use emem_guard::{
    DataClass, LatencyClass, ModuleContext, ModuleManifest, ModuleVerdict,
    PolicyModule, DenyCode, Fix,
};
 
pub struct MyModule { manifest: ModuleManifest }