Skip to main content
A protected action check is the billable name for a real boundary preflight. In runtime terms, that usually means one of two protected boundary kinds:
  • action_execute
  • memory_write
VerifiedX runs that preflight before the side effect executes, returns a decision receipt, and then helps the system either execute safely, recover locally, or replan upstream without losing the goal state. Taint marking, event ingest, execution reports, and decision reads are all included in that check.

​
What counts as a protected action

In product terms, protected actions include both durable memory writes and other high-impact side effects. Common examples:
  • Durable memory writes such as saving agent memory, long-lived state, or knowledge-store entries
  • Record mutations such as CRM updates, ticket changes, ledger writes, or workflow-state changes
  • Outbound messaging such as email, Slack, SMS, notifications, and similar message sends
  • Webhook and upload effects such as external callbacks, browser submits, queue publishes, and uploads
  • System changes such as file writes, config changes, shell-driven state changes, and other internal mutations
Depending on the integration, VerifiedX may classify a protected action as:
  • memory_write
  • record_mutation
  • system_change
  • external_message_send
  • webhook_call
  • upload

​
What does not count as a protected action

These do not usually create a billable protected action check on their own:
  • LLM calls
  • Retrievals and read-like lookups
  • Memory reads
  • Other support inputs that help build decision context but do not themselves create a protected side effect
They still matter. They feed run history, taint signals, and decision context for the next protected boundary.

​
How protected actions are discovered

VerifiedX can discover protected boundaries through more than one surface:
  • Raw runtimes
    • You explicitly bind actions and memories
  • Native adapters
    • VerifiedX infers the protected boundary from your existing tool names, descriptions, schemas, approval hints, and framework-native execution surfaces
  • Lower-seam fallbacks
    • When supported by the runtime, VerifiedX can also catch real side effects such as file writes, fetch-driven mutations, database mutations, queue publishes, and similar lower-level effects
A write is not only protectable when you explicitly declare it under actions. Native adapters and lower-seam fallbacks can also surface real protected boundaries.

​
Declaring protected actions in the raw runtimes

If you are using the raw Python or TypeScript runtime, declare durable memory writes under memories and other high-impact effects under actions. 
from verifiedx import init_verifiedx

vx = init_verifiedx()

vx.install_runtime(
    node,
    memories={
        "write_memory": {"tool_name": "write_memory"},
    },
    actions={
        "send_email": {"tool_name": "send_email"},
        "set_workflow_status": {"tool_name": "set_workflow_status"},
    },
)
The method name is the method on your harness or node. The tool_name or toolName is the stable boundary name that appears in decision context and receipts.

​
Native adapters

On native adapter surfaces, you usually do not declare separate actions and memories dictionaries. Instead, your existing native tool definitions are the source of truth. VerifiedX uses the tool name, schema, description, approval hints, and adapter-specific runtime signals to infer whether a tool should be treated as:
  • a protected action
  • a durable memory write
  • or only a support input
That is why native integrations can stay few-LOC while still protecting high-impact tools.

​
What happens during and after a protected action check

1

A protected boundary is about to run

VerifiedX sees a pending action_execute or memory_write boundary through the runtime, adapter, or lower-seam surface.
2

Decision context is assembled

VerifiedX includes the pending effect, tool history, retrieval history, taint signals, conversation anchors, prior denies for the same effect, and any upstream context that matters.
3

Boundary preflight runs

VerifiedX sends the protected boundary and decision context to the API for evaluation.
4

A decision receipt comes back

The result can be allow, allow_with_warning, replan_required, or goal_fail_terminal, along with reasons, safe next steps, routing guidance, and resume semantics.
5

The system either executes, replans locally, or routes upstream

If allowed, the side effect may execute and VerifiedX reports the observed execution. If the boundary is blocked or needs replanning, the side effect does not execute and VerifiedX returns a structured loopback result so the workflow can keep moving safely.

​
Replan is the default recovery shape

VerifiedX is optimized to stop the wrong action, not stop the agent. If the current side effect is wrong but the goal is still valid, the usual outcome is replan_required. That means:
  • the requested side effect does not execute
  • the system gets a structured decision receipt
  • the loopback result includes safe next steps and reasons
  • the workflow should continue toward the same goal state through a safer or better-grounded path

​
Local and upstream replan

VerifiedX supports both local and upstream recovery.

​
Local replan

In a direct or single-node flow, a denied protected action usually becomes a local replan first. That means:
  • the current node keeps the decision locally
  • the side effect stays unapplied
  • the runtime returns a blocked result with ok: false, blocked: true, boundary_outcome, safe_next_steps, and decision_receipt
  • the same node or agent can continue with a safer step

​
Upstream replan

In a composed workflow, the same replan_required outcome can route upstream when the missing support, approvals, or corroboration has to come from a parent stage. That means:
  • the local node stops trying to complete this stage on its own
  • it returns the decision receipt upstream
  • the orchestrator or parent node gathers what is missing
  • the blocked node is retried later with better upstream context
This is how VerifiedX helps complex systems keep working toward the same goal state without pretending the blocked step succeeded.

​
A successful preflight is not the end of the story

A protected action check covers the preflight. After an allowed boundary runs, VerifiedX can also observe and report whether the side effect actually happened. If the action throws, fails, or returns a result that does not confirm execution, VerifiedX keeps the workflow honest instead of silently counting that step as complete. That is why execution reports and runtime loopbacks are included in the same protected action check.

​
Pricing

Each protected action check counts as one billable unit. The following are included at no additional cost per check:
  • Taint marking of user turns and retrieval-like ingress
  • Event ingest
  • Execution reports
  • Decision reads from your decision log
Start by protecting the boundary most likely to cause irreversible damage if the agent is hijacked, misgrounded, or hallucinating.