Every supported rule namespace, field by field. Part of the apus policy reference.

Policy rule reference

Every rule below is optional; a check runs only when the rule is present. The observed state is existing Apus config or workspace metadata.

Channels

MCP servers

Model providers

Network

Message routing

Check ids must be unique. A route supports channel, optional accountId, peer, parentPeer, guildId, teamId, and memberRoleIds. Peer kinds are direct, group, and channel. matchedBy may contain one or more runtime match kinds, including binding.peer, binding.account, binding.channel, or default.

Routing checks are conformance checks only. They do not change startup, message delivery, binding precedence, or fallback behavior. Findings require operator review because automatically changing a binding could redirect private messages.

Ingress and channel access

Gateway

gateway.nodes.denyCommands is an exact, case-sensitive policy deny-superset rule. Use it when policy must prove that privileged node commands are explicitly denied by Apus config. A deployment that intentionally allows a privileged node command should update policy.jsonc after review instead of relying on gateway.nodes.commands.allow alone.

Agent workspace

Sandbox posture

Policy treats missing sandbox.mode as its implicit default off, so sandbox.requireMode reports a fresh or unconfigured sandbox as outside an allowlist such as ["all"].

Data Handling

Secrets

Exec approvals

Exec-approvals checks read the runtime exec_approvals_config singleton row in ~/.apus/state/apus.sqlite by default, or the same database under $APUS_STATE_DIR/state when APUS_STATE_DIR is set. Findings use the stable oc://exec-approvals.json/... URI scheme, which addresses paths within the authoritative JSON document stored in that row. Posture rules under execApprovals.defaults.* or execApprovals.agents.* require readable artifact evidence; a missing or invalid artifact reports as unobservable evidence rather than a best-effort pass. Once readable, omitted fields inherit runtime defaults: missing defaults.security is full, and missing agent security inherits that default. Evidence includes defaults, agents.*, agents.*.allowlist[].pattern, optional argPattern, effective autoAllowSkills posture, and entry source — never socket path/token, commandText, lastUsedCommand, resolved paths, or timestamps.

Example: require the approvals artifact, deny permissive defaults, and allow only reviewed exec approval posture for selected agents.

{
  "execApprovals": {
    "requireFile": true,
    "defaults": {
      // Security modes: "deny", "allowlist", or "full".
      // This default permits only the locked-down deny posture.
      "allowSecurity": ["deny"],
    },
  },
  "scopes": {
    "restricted-shell": {
      "agentIds": ["family-agent", "groups-agent"],
      "execApprovals": {
        "agents": {
          // Selected agents may use reviewed allowlist posture, but not "full".
          "allowSecurity": ["allowlist"],
          // false means skill CLIs must appear in the reviewed allowlist instead of
          // being implicitly approved by autoAllowSkills.
          "allowAutoAllowSkills": false,
          "allowlist": {
            "expected": [
              // Simple entry: exact reviewed executable pattern with no argPattern.
              "travel-hub",
              // Constrained entry: pattern plus reviewed argument regex.
              { "pattern": "calendar-cli", "argPattern": "^sync\\b" },
              "/bin/date",
            ],
          },
        },
      },
    },
  },
}

Auth profiles

Tool metadata

Tool posture

Tool requirements use the same group membership, aliases, and * matching as core tool policy. For example, group:fs includes ls, group:runtime includes secrets, cron resolves to automations, and the image-understanding tool is view_image. A required deny list must cover every tool in a required group; an empty list covers nothing, and denying write does not deny apply_patch.