Data access

1. 1Identify the caller.
2. 2Resolve the active workspace; fail closed if it cannot be resolved.
3. 3Verify the caller's role permission in that workspace.
4. 4Verify the specific connection and resource permission.
5. 5Retrieve only the records the request needs.
6. 6Filter and rank before anything is placed into model context.

• You are not signed in, so no private request is permitted at all.
• Workspace cannot be resolved for the request.
• Role does not permit the capability.
• The connection is missing, expired or in another workspace.
• The provider denied the operation for this account.

• Ask for one subject at a time rather than broad sweeps.
• Connect only the services you actually use.
• Use separate workspaces for separate trust levels.
• Review and remove unused connections regularly.

Records, documents and web pages are untrusted input. OpenbirdAI treats them as content to analyse and never as instructions, so a document cannot authorise itself, escalate a request, or change system behaviour.

The model never receives a database handle, a raw query, or a credential. It receives the text of records the authorisation checks already approved for this specific request, plus the metadata needed to cite them.

In practice a broad question cannot turn into a broad read. The planner decides how much data is needed, the authorization layer decides what is permitted, and the model works only with the intersection of the two — which is why cost and context stay bounded even for vague questions.

The same boundary applies to exports and to the machine-readable documentation files: they carry public product content only, never a record that passed through an authorized request.