How a decision is made

Every action an AI agent takes passes through the same five stages, in the same order, every time. There is no LLM in this path. Decisions come from a deterministic policy engine: same input, same decision, always.

That is not a performance choice. Security decisions need guarantees, not probabilities, and a verdict you cannot reproduce is a verdict you cannot defend six months later.

Every action walks the same five stages, on your own machine. The verdict is settled by the first stage with something to say about it, a blocked call never reaches the ones after it.

1. Identity

The agent authenticates with its token, or, where you have opted into mTLS, with a client certificate whose subject CN is the agent name.

An unknown token is blocked and audited as critical. Fail closed.
A suspended agent is blocked.
An agent registered with capabilities (wildcard action patterns) is blocked for anything outside them, before policy runs at all.

Capabilities are the cheapest possible control: an agent that was only ever meant to read cannot argue its way into a write, whatever the policy says.

2. Policy

Every policy that matches the request is collected, and the most restrictive effect wins:

block  >  require_approval  >  redact  >  allow

No matches means the configured default effect. That default is allow, so a first install observes rather than blocks; --default-effect block is the strict posture, and is what a production deployment should reach eventually.

Matching happens on the action, the target, the environment, the branch, the working directory, and, locally only, the call's own arguments. See Writing policies.

3. Advisors

Advisors are deterministic escalators. Each can make a decision stricter; none can loosen one. That asymmetry is the whole safety property, a broken advisor can be noisy, never permissive.

Advisor

Decision memory

The action contradicts a decision your team recorded

Behavioral signals

Novel destructive actions, bursts, boundary probing

Trust

A low-trust agent attempts a risky action

Verification

The agent never reported the outcome of its last allowed action

Provenance (taint)

The session has read untrusted content

Advisors that fail simply raise nothing, with one exception. Provenance is fail-closed: if the taint store cannot be read, the session is treated as tainted rather than assumed clean. See Trust, taint and provenance.

4. Approval

require_approval creates a pending approval bound to the exact action fingerprint: agent + action + target + environment. A grant therefore never leaks sideways onto a different action, target, environment or agent.

A human resolves it from the CLI, the console, the API, or a Slack-compatible webhook. On the next attempt the gateway claims the grant by fingerprint, the agent does not have to carry an approval id back, which is what makes the loop close for an editor hook that has nowhere to put one.

A grant is single-use. Approving "write this file" authorizes that write, not every write of it until a TTL runs out.

What a grant does not override: an agent's declared capabilities, a suspended agent, or a non-overridable taint block.

Full detail in Approvals.

5. Audit

Every request appends exactly one event to an append-only, hash-chained log: who, what, the decision, the risk level, the policies that matched, the advisory signals, and the session.

Every event also records policyVersion, the content hash of the rule set that decided it, so a verdict can always be traced back to the exact rules in force at that moment.

bash

memnox audit verify
# Audit chain intact — 128401 events verified.

See Activity and audit.

Risk levels

low → medium → high → critical, classified by deterministic rules over the action verb and the environment. Never by a model.

Risk does not decide anything on its own. It is what advisors key off, what reports group by, and what a human reads first.

Determinism, and time

Policies can carry time windows, two approvers on weeknights, unrestricted during business hours. That would normally break reproducibility, so the instant is passed into evaluation rather than read from the clock inside the engine.

Replaying an audit event with its recorded timestamp reproduces the same verdict. That is what makes memnox replay and memnox policy simulate meaningful rather than approximate.

Where the LLM actually lives

Exactly one place: extraction, in the hosted cloud, turning conversations into candidate decisions for a human to approve. It writes nothing directly, and its output is a suggestion until somebody's name is attached.

Nothing it produces reaches the decision path without passing through a person first.

Writing policies

The YAML that stage 2 evaluates.

The decision trail

Reading a verdict backwards to the rule behind it.