ORBY limits and safeguards

Overview

ORBY writes to your workflow, calls tools, and can start runs. This page is what bounds it: the models it may use, the budgets a turn works inside, what your own role lets it do, and the guards on its instructions and on your data.

For what ORBY does, see Build with ORBY.

ORBY runs only on a reviewed model list

ORBY does not run on any model your organization happens to have configured. It runs on models from a reviewed list, which holds each provider's strong models.

The reason is practical: small models fail the tool loop in ways people blame on ORBY rather than on the model. Restricting the list keeps the assistant's behaviour predictable.

How the model is chosen

The picker's Auto label names the model the turn will actually use, so you can see the choice before you send.

If no suitable model is configured, ORBY offers a setup card. Someone holding the permission to manage model configurations is sent straight to the right form; anyone else gets a request they can copy and send to their organization owner.

Budgets a turn works inside

Two consequences worth knowing:

• One turn at a time per use case, across everyone. If a colleague is mid-turn on the same use case, your turn waits and your save is refused with a 409. This is what stops a save pruning agents their turn just created.
• Long conversations are summarised, not truncated silently. Older turns are compacted so the thread stays within budget while keeping what matters.

A turn that dies, from a timeout, a provider error, a quota breach or a closed tab, is still recorded. Without that, a mutated canvas and an empty transcript made ORBY report its own earlier work as something you had changed by hand.

What you can do depends on your role

Opening ORBY needs only view access, because reading is the floor: anyone who may see the workflow may ask ORBY to explain it. What you may do from there is decided per tool.

Enforcement is in two places, deliberately:

• Tools you cannot use are not offered to the model, so ORBY does not propose work it cannot do.
• Every tool call is re-checked when it is dispatched. A stale browser tab, a replayed call, or a model ignoring its tool list cannot slip a write past a read-only caller.

ORBY is also told your level, so it explains and redirects rather than attempting something that would be refused. A builder gets no such notice, because nothing is restricted for them.

See Access control for the actions named above.

Your runs stay yours

ORBY can read recent runs to diagnose a failure, and it applies the same visibility rule the executions API applies:

• An ordinary member sees only the runs they started.
• An admin sees every run.

ORBY sees the status, the error text and the failing step. It never sees run inputs. When it is showing you only your own runs, it says so.

A test result for a run outside your visibility reads as unknown, exactly as the API would refuse it.

Prompt confidentiality

ORBY's persona and its internal building rules are confidential. The guard is a comparison applied to the model's output, immediately after it returns and before any tool is dispatched, streamed or recorded.

If a turn reproduces enough of the protected text, the whole response is replaced with a fixed reply, no tool runs, and the turn is not added to the conversation. Because the check is on the text rather than inside the model, it holds for every provider.

The check counts distinct copied passages across the whole turn, so a dump spread over prose and several tool calls adds up, while one phrase repeated in ten tool calls counts once. One checkpoint covers the reply, the cards, the build plan, an agent's instructions, and the tool inputs the canvas renders.

What is not confidential

Things ORBY legitimately quotes word for word are deliberately excluded, so asking an ordinary question never trips the guard:

• How each node type works, which is what a how-to answer repeats
• The tool catalog, so "what can web-search do?" works
• What ORBY is for, so "what can you do?" works
• Your own canvas and conversation text

Secrets in what ORBY reads

A key typed into a workflow input, echoed by an agent, or printed in an error would otherwise reach ORBY when it reads a run.

Secret-shaped strings are redacted from run output and run input before ORBY sees them, matching common credential prefixes and key blocks. The reply is redacted again where the model's prose becomes the answer, so a key the model copied out of something it read never reaches the panel or the record.

Text that came from outside

Anything of outside origin, most importantly the output of a run, is fenced and labelled as data rather than instructions. A workflow that processes an email cannot have that email tell ORBY what to build.

Your own messages are sent as written. They are instructions, which is the whole point of the assistant.

Scope

A message that is not about building or running a workflow is refused before it costs a turn. Two deliberate properties:

• It fails open. If the check cannot run, your message goes through rather than being blocked.
• It never judges a reply to a question ORBY itself asked, so answering "yes" or "the finance team" is never mistaken for an off-topic message.

Conversation retention and cleanup

Conversations are kept for 90 days and then swept. Clearing a conversation deletes your conversation only, never workflow data.

Troubleshooting

Next steps