D3 Security · Security Operations Glossary
What Is Command-Risk Tagging?
A standalone glossary definition, part of the D3 Security Operations Glossary.
Definition
Command-risk tagging is a governance mechanism in which the approval requirement for a response action ships with each integration action in the catalogue as risk metadata, so the approval gate sets itself per action instead of depending on hand-maintained configuration.
In a governed agentic SOC, command-risk tagging is how response stays bounded at stage 5 of the alert lifecycle. When the platform acts, the approval gate is set by risk metadata that ships with the integration catalogue, not by a per-action configuration your team maintains by hand. Hand-maintained gates drift; the thousandth action gets the default nobody reviewed.
Why gates should be architecture, not configuration debt
This is the difference between governance you can trust and governance you hope holds. Command-risk tagging means the approval requirement ships with each integration action in the 800+ catalogue; nobody maintains a thousand per-action settings by hand. Governance that depends on perfect manual configuration eventually fails an audit. When gates are architecture, the approval requirement is consistent across every action, whether it is used once or ten thousand times.
Also see:
Autonomy Modes
Governed Agentic SOC
Command-risk tagging and the four autonomy modes
Command-risk tagging works underneath the four autonomy modes. The mode (Deterministic, AI-Assisted, AI-Led, or Autonomous) decides how, and whether, the platform executes a response for a given alert class. Command-risk tagging sets the per-action approval gate below that choice. This is why a governed agentic SOC is not a single human-in-the-loop switch: the mode sets the ceiling, and command-risk tagging scopes the gates per action.
How is command-risk tagging built in Morpheus?
In Morpheus, the four autonomy modes govern execution from fully deterministic to fully autonomous, per alert class, with command-risk tagging setting approval gates at stage 5. The risk metadata ships with each action in the 800+ integration catalogue, so the gate is defined once and applied everywhere the action runs. Bounded execution runs through the deterministic automation core, which is the R in SOAR made real.
Frequently asked questions
What is command-risk tagging?
A governance mechanism in which the approval requirement for a response action ships with each integration action in the catalogue as risk metadata. The approval gate sets itself per action, instead of depending on a per-action configuration your team maintains by hand.
How is command-risk tagging different from manual approval rules?
Manual approval rules are hand-maintained per-action settings, and they drift: the thousandth action gets the default nobody reviewed. Command-risk tagging ships the approval requirement with the integration action itself, so the gate is defined once, in the catalogue, rather than reconfigured everywhere it is used.
Where in the alert lifecycle does command-risk tagging apply?
At stage 5, Respond, where bounded execution runs through the deterministic automation core. Command-risk tagging sets the approval gate from risk metadata in the integration catalogue, per action, at the point the platform acts.
Does command-risk tagging slow down response?
No. Approval gates bind only the consequential stages, response and codification, and command-risk tagging scopes them per action. Investigation, scoring, and narrative run at machine speed with no gate to wait on. The judgment call waits for a human exactly where you decided it should.
Why do hand-maintained approval gates fail audits?
Because governance that depends on perfect manual configuration eventually misses one. Hand-maintained gates drift, and the thousandth action gets the default nobody reviewed. When gates are architecture rather than configuration debt, the approval requirement is consistent across every action in the catalogue.
How does command-risk tagging relate to the four autonomy modes?
The four autonomy modes (Deterministic, AI-Assisted, AI-Led, Autonomous) decide how, and whether, the platform executes a response. Command-risk tagging sets the per-action approval gate underneath the chosen mode, so autonomy and governance work together rather than as one on-off switch.
Does Morpheus use command-risk tagging?
Yes. In Morpheus, the four autonomy modes govern execution from fully deterministic to fully autonomous, per alert class, with command-risk tagging setting approval gates at stage 5 from risk metadata that ships with the 800+ integration catalogue.
Related terms
Governed Agentic SOC — The operating model that bounds every action with a governance gate.
Autonomy Modes — The four graduated levels of independence that sit above command-risk tagging.
Self-Healing Integrations — The 800+ integration catalogue that carries the risk metadata.
Bounded Agentic Reasoning — Autonomous reasoning held inside explicit limits, including approval gates.
Further reading
Morpheus Autonomy Modes
The integration catalogue
Book a demo
Last updated: July 2026