Security

The trust boundary

The boundary is the Roblox server. Everything inside it — planning, validation, resource settlement, execution and commit — is trusted. Everything outside it is not: clients, external model providers, and any system that submits goals.

Input from outside the boundary is accepted as a request and validated. It never arrives carrying authority.

Properties and mechanisms

Each property below is paired with the mechanism that produces it. A guarantee stated without a mechanism is not one.

Server authority

No client can cause a world-state commit by sending a message.Planning, validation, resource settlement and commit all execute server-side. Client input enters as a goal request that passes through the same validation as everything else, and carries no capability of its own.

Capability boundaries

An actor cannot attempt anything its role did not declare.The planner composes plans exclusively from the action surface declared by the adapter and granted by the role manifest. There is no dynamic dispatch into arbitrary code at decision time, so an undeclared action has no reachable call path.

Deterministic commits

The same observation, manifest and goal produce the same plan.The local planner is deterministic and seeded. External evaluation is the only source of non-determinism, it is opt-in, and disabling it restores reproducibility exactly.

Atomic resource movement

A plan that cannot pay for itself never partially executes.Currency, stock, fuel, cargo and charges move inside one transaction that is applied whole or discarded. Intermediate state is never observable to players or to other actors.

Observation is an allowlist

Data the agent was not given cannot leak from the agent.Adapters declare the fields they normalise. Anything undeclared is absent from the planner input, absent from diagnostics, and absent from any external payload — not filtered later, but never collected.

External-provider isolation

An external model can propose. It cannot act.Providers receive a redacted subset of the observation, explicitly enumerated per configuration. Their response re-enters as a proposal at the validation step and is checked identically to a local plan. They hold no capability, no resource authority and no commit path.

Safe failure

Degradation stops the actor; it does not loosen the rules.A provider timeout falls back to the deterministic planner. A manifest that fails to load prevents attachment rather than defaulting to a permissive role. A stalled planner holds the last safe state and stops issuing actions.

Player data is not collected by default

The runtime does not gather account identifiers on your behalf.Nothing about a player enters an observation unless an adapter explicitly declares it. If you choose to declare player-derived fields, you remain the controller of that data and are responsible for the disclosures your experience makes.

What this page is not

This describes the security model of the runtime as designed. It is not a compliance certification, an audit report or a data-processing agreement. No third-party security audit has been published. If you need a specific assurance for your own review, ask and we will tell you what does and does not exist today.

Reporting a problem

If you believe you have found a way to make a client commit world state, to bypass validation, or to widen what leaves the server, email support@actorvia.xyz with the details. Please give us a chance to fix it before disclosing it publicly.

See also the security overview and the privacy notice.