DocsGovern AI agentsAsk before you act

Ask before you act

A gate refuses an action after an agent has already committed to it. Answering the question first is cheaper for everyone: the agent carries the rules into its work, and the refusal never happens.

context.askrecords nothing
Agent is about to writefile.write src/auth/…
what governs this?
It asks firstone call, before any work
answers with
It gets the briefyour rules, plus the baseline
so the gate
It writes accordinglyand the gate agrees
asking is not attempting: no audit event, no approval, no rate limit worth worrying about

What you get back

$memnox context <action> <target>

What governs this, before you do it.

<action>
What you are about to do: file.write, deploy.service, database.drop.
<target>
What it acts on: a path, a service, an environment. Optional, but the answer is sharper with it.
Memnox constraints for "file.write src/app/(auth)/login/page.tsx"
This action would need human approval before it proceeds (risk: medium).
Next: ask security-team to approve before this proceeds.
 
Rules that apply — these decide whether this proceeds:
  - auth-code-review — your policy, requires approval
      Auth and session code changes need a second pair of eyes.
      approvers: security-team
 
Not enforced, but worth checking for this kind of change (baseline 2026.08.2):
  - authz-check-per-object
      Check that this caller is allowed to touch this particular record — not
      only that they are signed in.
      why: Otherwise someone signed in can change the id in the request and
      read another customer's data.
  - session-cookie-flags
      Set session cookies HttpOnly, Secure, and SameSite, and issue a brand
      new session id whenever someone signs in or changes role.
      why: A session id that survives sign-in still works for whoever planted
      it — and they are now signed in as that person.
  - no-hardcoded-secrets
      Never write a password, key, or token into source. Read it from the
      environment or the secret store.
      why: Deleting the line afterwards does not help — it stays in the git
      history, so the secret has to be replaced.
 
None of this is a review of your code — Memnox has not read it. The rules
above are your organization's; the checklist ships with Memnox.

Four more requirements apply to this path and are omitted here for length. Each one leads with its id, which is what you cite to suppress it or to diff two briefings.

Two kinds of knowledge, kept apart

Half of the brief

Constraints

What your organization declared, quoted from your policy files and approved decisions. "Auth changes need a second pair of eyes."

Worth checking

The baseline Memnox ships for that kind of change, looked up by action and target. Nothing here blocks you. "Check that this caller is allowed to touch this particular record."

Neither is generated. The baseline is a fixed table, so the same request always returns the same requirements in the same order, and it carries a version, so a briefing produced in March can be reproduced in March's terms later.

Silence is not approval

When no rule matches, the answer says so in those words: not endorsed, only ungoverned.

That phrasing is deliberate. An agent reading "no constraints" as "approved" would turn every gap in your policy coverage into a licence.

Let the agent ask on its own

memnox setup registers the MCP server for you. Restart your editor and the agent has two tools it can call without being told:

Tool

memnox_check_rules

Before writing a file, running a command, deploying, or adding a dependency.

memnox_status

When a call was refused, or when you ask what Memnox is doing.

$memnox mcp

The server itself. Your editor launches it; you do not.

$memnox mcp install <client>

Add it to another editor later. It never overwrites an existing memnox entry in an MCP config.

<client>
claude-code, cursor, windsurf. Omit it and Memnox installs for whichever it finds.

Everything stays on your machine: no account, no API key, no network call.

From your own code

ts
const brief = await memnox.context({
  action: 'file.write',
  target: 'src/auth/session.ts',
});

--json gives the same answer from the CLI, for anything that needs to parse it.