Ownership and approvals

Two questions, and every organization answers both badly by default:

1. Who is accountable for this?
2. How does the request reach them without three reminders?

Ownership

Ownership in Memnox is a tie in the graph, person owns decision, not a field somebody typed into a spreadsheet. It comes from the same evidence everything else does: who made the call in the thread the decision was extracted from, who was named as the approver, who has been resolving incidents on that system.

Ownership is what makes routing possible. A policy that says approvers: ["security-team"] is only as good as the system's ability to turn that into people who will actually see it.

Approvals

require_approval is the middle outcome, and in practice it is the one that gets used most. Blocking is for things that are never acceptable; approval is for things that are usually fine and occasionally catastrophic.

Bound to a fingerprint

An approval is bound to the exact action fingerprint:

agent + action + target + environment

A grant for code.modify payment/checkout.ts in production by local-editor authorizes precisely that. It does not authorize the same edit by a different agent, the same agent in staging, or a different file.

Single-use

The grant is marked spent the moment it authorizes an action. Approving "write this file" authorizes that write, not every write of that file until a TTL expires.

This is the difference between an approval and a permission, and it is why an approval trail is worth reading.

Claimed by fingerprint, not by id

When the agent retries, the runtime matches the grant by fingerprint. The agent does not have to carry an approval id back.

That sounds like a detail. It is the reason the loop closes for an editor hook, which has nowhere to put an id, and it is why approvals work identically whether the caller is a hook, an MCP client, the SDK, or a script.

Quorum

  - name: production-deploy-two-person
    match:
      actions: ["deploy.service"]
      environments: ["production"]
    decision:
      effect: require_approval
      approvers: ["eng-lead", "security"]
      minApprovals: 2

Grants accumulate until the quorum is met. One person counts once, and a single denial ends it immediately. There is no "two out of three eventually".

Time windows

The same rule can apply only outside business hours:

      windows:
        - { days: [1,2,3,4,5], startHour: 17, endHour: 9 }
        - { days: [0,6], startHour: 0, endHour: 24 }

Two approvers at 11pm on a Saturday; unrestricted at 2pm on a Tuesday when the people who would catch a mistake are awake.

What an approval cannot do

A grant never overrides:

• an agent's declared capabilities, an agent that may not deploy still may not deploy;
• a suspended agent;
• a non-overridable taint block, project.delete and database.drop from a tainted session are refused outright.

In each of those cases the action is refused and the grant is left unspent.

Break-glass

An admin can override a pending approval:

memnox approvals override <id> --reason "incident 4471, on-call escalation"

The reason is required, and the override is audited as critical. Irreversible actions, project.delete, database.drop, refuse break-glass with a 403 and audit the attempt.

Where approvals show up

An agent handed require_approval receives an approvalId and may poll GET /v1/approvals/:id, the only route an agent token may read, and it returns 403 on anyone else's approval.