Operators are bounded. You approve. Everything is logged.

How operators are bounded

One job per operator. No open-ended scope.

Each operator on OPRTR is built around a single, defined workflow: specific inputs, steps, and outputs. The operator does not decide its own scope. It cannot add new capabilities at runtime. What it can do is listed on its listing and in the install flow—actions supported, and actions that require your approval. This bounded design is a platform requirement.

• ·Defined workflow only. No ad-hoc expansion of behavior.
• ·Boundaries are public. Every listing states what the operator will not do.
• ·You install with full visibility into capabilities and limits.

Approval model

Sensitive actions stop until a human approves.

Operators do not execute every action on their own. The platform supports approval gates: actions that change data, send messages, or trigger external effects can be configured to queue for a responsible approver. The operator runs up to that point and stops. You (or a designated approver) review and approve or reject. Only then does the action run.

• ·You define the responsible approver per operator (or use a default).
• ·Pending approvals are visible in your dashboard. No silent execution.
• ·Approvals and rejections are recorded in the audit trail.

Audit log model

Runs and decisions are recorded. You can review what happened.

The platform records operator runs, inputs and outputs at a level appropriate for the workflow, approval requests and outcomes, and connection or configuration changes. These logs are available to your company for the operators you have installed. Retention follows platform policy and your settings. We do not use your operational data to train models.

• ·Run history: what ran, when, and high-level outcome.
• ·Approval trail: what was queued, who approved or rejected, when.
• ·Access to logs is scoped to your organization and your installs.

Permissions and access

Scoped access. You connect only what each operator needs.

When you install an operator, you connect the systems it needs—CRM, inbox, calendar, etc. Those connections are scoped to that operator and that job. The operator cannot access systems you did not connect. Credentials and tokens are stored in an encrypted form. You can revoke a connection at any time from your dashboard.

• ·One set of connections per operator. No cross-operator reuse unless you configure it.
• ·Revocation is immediate. Disconnect a system and the operator loses that access.
• ·Connection status is visible so you can see what is active.

Trust levels

Operator listings show a trust level. It reflects platform review, not a guarantee.

Operators on the marketplace are labeled with a trust level (e.g. Standard, Verified, Enterprise). These levels indicate that the operator has met certain platform checks—workflow clarity, boundary documentation, integration behavior. They are product signals to help you choose. They are not certifications or legal guarantees.

• ·Standard: listed after basic review. Boundaries and workflow documented.
• ·Verified: additional checks and usage history. Often used in production by other companies.
• ·Enterprise: reviewed for stricter boundary and integration standards. Suited for sensitive workflows.

Safe deployment philosophy

Start with trial. Gate sensitive actions. Revert when you need to.

We encourage a controlled rollout: run an operator on a 7-day trial with limited scope or approval gates on all sensitive actions. Review the audit log. If the operator behaves as expected and the value is clear, you can broaden scope or reduce gates. Where the platform or operator supports it, actions that can be reversed are designed so you can undo or discard.

• ·Trial first. See proof before you rely on an operator in production.
• ·Reversible actions are called out where possible. Use approval for the rest.
• ·You can pause or uninstall an operator at any time. Connections can be revoked.

FAQ

• Can an operator do something it isn't supposed to?

  Operators are built to a defined workflow and boundaries. The platform does not allow operators to add new capabilities at runtime. If you see unexpected behavior, you can pause the operator, revoke connections, and contact support. Audit logs help determine what ran.

• Who can see my data and logs?

  Operational data and audit logs for your installs are scoped to your organization. Operator creators do not have access to your data or your logs. Access by the platform is limited to what is necessary to run the operator and maintain the service.

• What if I need to undo something an operator did?

  Where actions are reversible (e.g. drafts, unsent items), the operator or platform may support undo or discard. For actions that have already affected external systems, reversal depends on that system. We document reversible vs non-reversible actions per operator where applicable.

• How do I get more detail on retention or legal terms?

  Retention and legal terms are in our terms of service and related documents. This page describes product-level control and architecture. For formal commitments, DPAs, or compliance questions, contact us.