Critical Risk →

orgx_act

Run a lifecycle, validation, completion, or proof action on one OrgX entity. Per-action required inputs: • update → "fields" patch object. • complete_with_proof, ship_batch → "artifact" (artifact_type + url/preview). • validate (studio) → "spec" payload. • block, flag_risk, decline, cancel, delet...

How to control orgx_act ↓

AI agents call orgx_act to permanently remove resources in OrgX — typically in cleanup and lifecycle workflows. It does its job in a single call, and there is no undo.

ParameterTypeRequiredDescription
id string Target entity UUID or short ID prefix (8+ hex chars).
note string Strongly recommended for destructive or blocking actions (block, flag_risk, decline, supersede, cancel, delete). Free-text rationale shown in audit history and
spec object REQUIRED when action=validate. Spec payload for studio validation (shape varies per studio entity subtype).
type string Target entity type (initiative, milestone, workstream, task, objective, playbook, decision, or studio).
force boolean Force action where server supports override semantics (skips pre-flight checks).
action string Lifecycle action to execute on the target entity. Must be valid for the given type — see tool description for the (type → action) matrix.
fields object REQUIRED when action=update. Map of entity fields to patch (e.g. { name?: string, description?: string, owner_id?: string, status?: string, due_date?: string })
dry_run boolean Preview risky actions without mutating where supported. Returns the diff/plan without applying.
_context object Client context for conversation tracking (strongly recommended for cross-client continuity)
artifact object REQUIRED when action=complete_with_proof or action=ship_batch. Proof artifact payload. Expected shape: { artifact_type: string, artifact_url?: string, external_
session_id string Optional bootstrap/session identifier returned by orgx_bootstrap.
verification array Optional list of verification evidence URLs/IDs for completion flows.

Parameters from the server's own tool schema.

Critical Risk

An AI agent that decides to call orgx_act doesn't hesitate, doesn't double-check, and doesn't stop at one. Whatever it removes from OrgX is gone — there is no undo for destructive operations.

Risk signalsHigh parameter count (30 properties)

Documented attack patterns abuse exactly the kind of access orgx_act gives an agent:

PolicyLayer is an MCP gateway — it sits between your AI agents and OrgX, and nothing reaches the server without passing your rules. This is the rule we recommend for orgx_act:

policy.json
{
  "version": "1",
  "default": "deny",
  "hide": [
    "orgx_act"
  ]
}

orgx_act disappears from the agent's tool list entirely, and any attempt to call it is denied. The rest of the server keeps working.

  1. Create a free account and register OrgX — nothing to install.
  2. Add this policy — paste it, or build it visually.
  3. Point your MCP client (Claude, Cursor, anything) at your gateway URL.
RESTRICT THIS TOOL →

Free to start. No card required.

Go deeper

What does the orgx_act tool do? +

Run a lifecycle, validation, completion, or proof action on one OrgX entity. Per-action required inputs: • update → "fields" patch object. • complete_with_proof, ship_batch → "artifact" (artifact_type + url/preview). • validate (studio) → "spec" payload. • block, flag_risk, decline, cancel, delete → "note" strongly recommended. • dry_run=true previews any lifecycle action without mutating where supported. Allowed (type → action) pairs (others return an error): initiative: launch|pause|resume|complete|archive|update|delete milestone: start|complete|flag_risk|cancel|ship_batch|update|delete workstream: start|pause|resume|block|complete|reassign_streams|update|delete task: start|complete|complete_with_proof|block|unblock|reopen|update|delete objective, playbook, decision, studio: see field descriptions. USE WHEN: changing entity state. NEXT: orgx_submit_receipt for durable proof. DO NOT USE for creating records — use orgx_write. It is categorised as a Destructive tool in the OrgX MCP Server, which means it can permanently delete or destroy data. Block by default and require explicit approval.

What parameters does orgx_act accept? +

orgx_act accepts 12 parameters: id, note, spec, type, force, action, fields, dry_run, _context, artifact, session_id, verification. The full parameter table on this page comes from the server's own tool schema.

How do I enforce a policy on orgx_act? +

Register the OrgX MCP server in PolicyLayer and add a rule for orgx_act: allow, deny, rate-limit, or require approval. Point your MCP client at the PolicyLayer proxy URL and the rule is enforced on every call, before it reaches OrgX. Nothing to install.

What risk level is orgx_act? +

orgx_act is a Destructive tool with critical risk. Critical-risk tools should be blocked by default and only enabled with explicit human approval.

Can I rate-limit orgx_act? +

Yes. Add a rate_limit block to the orgx_act rule in your PolicyLayer policy. For example, setting max: 10 and window: 60 limits the tool to 10 calls per minute. Rate limits are tracked per agent session and reset automatically.

How do I block orgx_act completely? +

Set action: deny in the PolicyLayer policy for orgx_act. The AI agent will receive a policy violation error and cannot call the tool. You can also include a reason field to explain why the tool is blocked.

What MCP server provides orgx_act? +

orgx_act is provided by the OrgX MCP server (useorgx/orgx-mcp). PolicyLayer sits as a proxy in front of this server to enforce policies before tool calls reach the server.

Enforce policy on every OrgX tool call.

Deterministic rules across all 29 OrgX tools. Per-identity grants. Full audit log. Live in minutes. Nothing to install.

Free to start. No card required.

29 OrgX tools catalogued and risk-classified — across an index of 42,500+ MCP servers.

// GET IN TOUCH

Have a question or want to learn more? Send us a message.

Message sent.

We'll get back to you soon.