For engineering

What changes

One command, then a restart:

npx memnox setup

After that, your editor works exactly as it did, until it tries something your organization said needs a human. Then it stops and tells you which rule, in that rule's own words.

What does not change

Memnox does not review your code. It does not comment on your pull requests, suggest reviewers, summarize your diffs, or open issues. It is a gate, not a reviewer: it answers "does this violate a rule?", never "is this good?".

Nothing about your workflow, branching model or tooling has to change.

Make the agent ask first

The biggest quality-of-life win is not the gate, it is the briefing.

memnox context file.write 'src/auth/session.ts'

memnox setup already registered the MCP server, so your agent can call this itself before it writes. It gets your organization's constraints, quoted, plus a versioned security baseline for that kind of change.

An agent that carries the rules into its work is faster than one that meets them as a refusal.

Build the code graph

memnox graph build
memnox graph explain src/utils/money.ts

A policy matches the path an action names. That is not enough: editing src/utils/money.ts is editing payment code if payment/checkout.ts imports it.

memnox serve --code-graph .memnox/code-graph.json --protected-path "*payment/*"

--code-graph points at the file graph build just wrote. It is a snapshot, so rebuild it in CI or reachability goes stale. --protected-path takes a glob (* within a path segment, ** across them) and escalates any change that reaches it, including one that only touches a file payments imports. Repeat the flag for more than one path.

For deeper analysis across 36 languages, memnox graphify install adds AST calls and inherits edges. Only AST-extracted edges cross into the decision path, inferred ones are counted and discarded.

Register agents narrowly

memnox agents register --name ci-deployer --kind custom

--name is what this agent is called on every audit line; --kind is descriptive only. The token is printed once, so copy it then.

Capabilities are the wildcard action patterns an agent may never exceed. They are set at registration through the API rather than the CLI:

curl -X POST http://127.0.0.1:7466/v1/agents \
  -H "Authorization: Bearer $MEMNOX_ADMIN_TOKEN" \
  -H "content-type: application/json" \
  -d '{"name":"ci-deployer","capabilities":["deploy.*","file.read"]}'

* stands for any remainder, so deploy.* covers deploy.service and deploy.worker. Leave the field out and the agent may attempt anything.

Capabilities are checked before policy runs, so they are the cheapest control in the product. A CI agent that only deploys should not carry *, and an agent that reads should not be able to write whatever the policy file says.

Governing a custom loop

import { MemnoxClient, governTools } from '@memnox/sdk';
 
const memnox = new MemnoxClient({
  baseUrl: 'http://127.0.0.1:7466',
  token: process.env.MEMNOX_AGENT_TOKEN,
});
 
const tools = governTools(memnox, { readFile, writeFile, runShell }, {
  sessionId: runId,
  environment: 'production',
});

Same signatures, same framework wiring. Pass the same sessionId for the whole run: taint attaches to the session, so a run split across several ids loses the link between reading untrusted content and acting on it.

For a single dangerous operation, use guard; for one where you want proof it worked, use guardVerified.

Put it in CI

memnox ci                 # exits 1 on a blocking finding
memnox ci --staged        # the form a pre-commit hook wants
memnox ci --no-fail       # report without breaking the build

It scans the branch's diff for secrets and personal data and exits 1 on a blocking finding. Start with --no-fail for a week, read what it reports, then drop the flag once you trust it.

This is a content scan, not a full policy evaluation. Policy decides what an agent may do at runtime; memnox ci decides whether what got written is safe to commit, which is much the cheaper place to find out.

Policies live in your repo

# memnox.policies.yaml
project: acme-checkout
version: 1
policies:
  - name: no-recursive-delete-in-payments
    match:
      actions: ["shell.execute"]
      arguments: { command: ["*rm -rf*"] }
      workingDirectories: ["/srv/payments*"]
    decision:
      effect: block
      reason: Recursive delete is not an agent action here.

Reviewed in a diff like anything else. A frontend and backend that belong to one product declare the same project: and share one scope.

memnox validate && memnox reload

When it blocks you and it is wrong

memnox explain <eventId>

Then narrow the rule and open a PR against it. The rule being wrong is a normal outcome, not an escalation, that is why the file is in the repository.

Things worth knowing

• Arguments never leave your machine. They are matched in-process; the SDK strips them before any request goes out.
• Approvals are claimed by fingerprint. Just retry the action, you do not have to pass an approval id back.
• Grants are single-use. Approving one write authorizes that write.