How I used Orion to repair our GitHub data pipeline
Insights
·
AI
Who Can Read, Edit, and Approve AI Agent Context?
Give people access to AI agent context according to the specific resource and action they need: reading a definition, proposing a correction, approving a change, changing its audience, or running an analysis. Check the effective permissions across the context system, consuming agent, and data source before granting access. A business expert who can improve a definition should not automatically gain broader data access or authority to make that definition a company-wide default.
Last reviewed: October 11, 2026. Linked product documentation was checked on this date. The worksheet and checks below are recommended operating practices, not a built-in Orion policy engine.
What are AI context permissions?
AI context permissions are the rules that determine which people and applications can read, change, approve, and distribute the business information supplied to an AI agent. That information can include metric explanations, customer exceptions, operating policies, and references to governed calculations.
An access decision has at least three subjects: the person asking, the system carrying the request, and the resource being used. A person may be allowed to read a metric description but not its underlying records. An agent may be able to retrieve a page without having authority to approve an edit. A reviewer may understand a rule while lacking permission to change the warehouse calculation.
Treat these as explicit decisions. A role name such as “analyst” is a starting point; the resource, grant path, and requested action establish what it means in practice. The broader context-layer control tower guide covers organizational ownership. This guide turns that ownership into an access review.
Which actions should the data team separate?
Start with five context actions: read, propose, approve, change audience, and administer. Then check query execution and output distribution separately.
- Read: discover a page and use its content to interpret a question.
- Propose: suggest a correction without making it effective for other consumers.
- Approve: accept a proposed change at its authoritative source.
- Change audience: enable a page for another project, group, customer, or default context.
- Administer: change memberships, roles, and the controls that determine access.
The distinctions matter even when one person legitimately performs several actions. Record that combination deliberately. If an administrator can edit without a second reviewer, the organization needs to decide whether a separate review process is appropriate for consequential changes.
Keep metric ownership explicit. The dbt Semantic Layer centralizes governed metric definitions and uses MetricFlow. When it owns the calculation, a context editor can explain or reference the metric; formula changes belong in the metric team's review process. Semantic Layer vs. Business Context explains that boundary.
What should an access-boundary worksheet record?
Use one row per resource and intended audience, rather than one row per job title. The worksheet is an original planning asset. Fill it with actual identities and resource references from your deployment.
| Field | Decision to record | Example to resolve |
|---|---|---|
| Resource and authority | Exact page, metric, project, or report; system that owns it | Finance's approved metric explanation, not every page in a shared folder |
| Readers and grant paths | Intended audience and each path that grants access | Group membership, direct invite, and any privileged role |
| Proposers and direct editors | Who may suggest a change; who can save one immediately | A business expert proposes; a designated owner can edit |
| Review authority and exceptions | Who can approve, and which paths bypass review | Creator edits, administrator edits, or automatic approval |
| Audience changes | Who may enable a page elsewhere or make it a default | A department-specific note must stay department-specific |
| Execution identity | Account and policy used for each data query | Interactive user versus a shared service account |
| Output recipients | Who may view or receive the answer, notebook, or report | An authorized analyst sends a report to a narrower audience |
| Removal and evidence | What must be revoked; who checks the result; evidence retained | Remove every relevant grant and test the formerly allowed action |
Record the desired behavior before configuring roles. “Marketing can propose campaign terminology” is a useful requirement. “Give Marketing analyst access” leaves open whether that role can share projects, change defaults, or reach additional sources.
Include an owner for each unresolved field. Leave a boundary marked unresolved until the team can demonstrate it. A blank execution-identity field is especially important when an embedded user has no warehouse account.
Why is project or group membership only part of the answer?
Orion by Gravity's Groups documentation separates tenant and group roles. Access can come through a group or a direct project invitation; removing one route leaves the other intact. Adding a project to a group also exposes its attached data sources to that group. Linking a whole knowledge folder makes later pages in that folder available too.
Use those documented behaviors to guide the review:
- Check every grant path for the intended person and resource.
- Review attached resources when sharing a project.
- Decide whether a folder grant is appropriate for future pages.
- Test removal after accounting for direct and group access.
The group guide also recommends a tenant Viewer baseline with appropriate group roles for scoped users. Confirm the effective configuration in the intended deployment instead of applying a role label as a universal guarantee.
For example, if a support specialist leaves a customer group but retains a direct project invite, a group-only removal checklist is incomplete. The question is whether continued access is intended. Record the surviving grant and its owner; remove it through the normal access process if it is no longer authorized.
Does approving a page also approve its audience?
It should be a separate decision. A rule can be accurate for one department and inappropriate for every other department. An approved customer exception can still be confidential.
Orion's page-management guide documents project-selected context and optional tenant or group defaults. Projects cannot opt out of defaults. Locked pages support proposed changes, while admins and page creators have direct-edit exceptions. Revision history records page updates.
Before promoting a page, ask the business owner to approve its meaning and the access owner to approve its audience. These can be the same person where the organization permits it, but the record should show both decisions.
Use a hypothetical customer example. Customer A's contract allows a different interpretation of “active account.” The explanation may point to an approved customer-specific measure without redefining the shared calculation. Approving that explanation for Customer A does not make it suitable for Customer B or a tenant-wide default.
Choose a narrow audience first. If a proposed default contains both common definitions and a private exception, split the material according to its intended readers before considering broader use. Verify what each consuming project actually receives. A page title containing a customer name is not an access policy.
For the correction itself, use the business-user correction guide. The access worksheet answers the additional question: who can read, apply, and redistribute the result?
What changes when queries use a shared service account?
The application must establish how the requesting person's authorized scope reaches query execution. A shared database credential identifies the connection; it does not, by itself, explain which customer or department the application user is allowed to see.
Orion's connection guide describes dedicated service accounts, a Snowflake service user with key-pair authentication, and optional per-user BigQuery OAuth. The BigQuery documentation also distinguishes user-owned scheduled work from unattended work. These are connection-specific behaviors; do not assume that one identity pattern applies to every source.
For each route, record the application identity, selected project, effective database identity, and enforced restriction. Confirm how customer scope is derived and which component rejects a request outside it. A text instruction to “only show this customer's records” should not substitute for an enforced authorization boundary.
Snowflake row access policies determine which rows a query returns and can use mapping tables. A policy must receive the information needed to make the intended decision. If every request arrives under the same service identity, inspect how that identity and any supported request context connect to the application's authorization model.
Ask for a demonstration using two ordinary users with different allowed populations. Compare the query identity and returned rows as well as the answer. Keep the legitimate query working while checking the forbidden one. This is a deployment validation requirement, not a claim that Orion automatically translates every application's access-object table.
How should the team verify effective access?
Run these checks against a small pilot with synthetic or otherwise approved test material. The expected outcomes below are a proposed acceptance policy. They do not report a benchmark or assert that any product already passes.
| Check | Action to attempt | Expected outcome and evidence |
|---|---|---|
| Reader versus editor | A reader opens a permitted page, then attempts an edit | Reading works; the edit follows the configured role and review path. Save both outcomes. |
| Independent review | The page creator and an ordinary contributor make the same consequential change | Identify every bypass or automatic approval; decide whether an additional review is required. |
| Audience expansion | An editor attempts to enable a private page for a broader project or default | Only the designated scope owner can authorize expansion under the team's policy. Record the effective audience. |
| Future folder content | Add an approved test page under a folder already granted to a group | Determine who gains access; confirm that future-page exposure is intended. |
| Multiple grant paths | Remove a group grant from a user who also has a direct invitation | Identify surviving access before declaring revocation complete. |
| Delegated client | Repeat an allowed read and forbidden write through the consuming assistant | Inspect the authenticated principal, tool result, and resulting answer. |
| Delivered output | Send or share a test answer containing restricted supporting material | Verify the intended recipient can receive only authorized content; inspect the delivered artifact. |
For every check, retain the actor, resource, action, configuration, observed result, and decision. Record the time of the check and who accepted it. If the system does not expose enough evidence to verify a boundary, document that limitation and constrain the pilot until the owner resolves it.
Use the context-layer evaluation guide for answer regressions after changes. Access review checks who can act and who receives information; answer evaluation checks whether the authorized answer is correct. Both are needed for a meaningful rollout.
What should we ask Orion by Gravity to demonstrate?
Bring the worksheet and one real resource boundary. Ask Orion by Gravity to show an ordinary reader, a business contributor, a reviewer, and a privileged editor performing the relevant actions.
Orion's MCP documentation describes authenticated access to projects and knowledge resources from compatible assistants, with writes governed by the user's Orion permissions. Validate the specific tool and client path you plan to use. That connection does not establish control over every action an independent third-party agent can perform through other tools.
Inspect the affected page, audience configuration, execution identity, and delivered artifact. Ask which controls are enforced by Orion, which belong to the warehouse or consuming application, and which remain an organizational procedure.
Other architectures can also support parts of this work. Cube's security-context documentation describes using authenticated context for query and model access rules. That addresses a different implementation layer from page-edit approval. Compare tools against the actions you need, rather than treating every “governance” claim as the same capability.
Orion is worth evaluating when the team needs business-context editing alongside warehouse analysis and compatible consuming assistants. If the only requirement is a warehouse row policy, implement and validate that policy in the existing data system. If mandatory independent approval is required for every context edit, have the product team demonstrate that requirement explicitly, including privileged paths.
The AI analytics evaluation guide and AI business intelligence tools comparison provide broader buying criteria. To evaluate the access workflow, bring the completed worksheet to the Orion by Gravity team.
Frequently asked questions
Can a business expert correct context without receiving warehouse access?
Design the workflow that way where possible. Give the expert access to the interpretation and review evidence they need; keep query credentials and data grants separate. Confirm the actual permissions of the context platform and the evidence-sharing route.
Is a locked knowledge page enough to require two-person approval?
Not by itself. Review the product's privileged-editor and creator behavior, automatic approvals, and unlocking authority. In Orion, documented direct-edit exceptions mean a locked page should not be described as a universal independent-approval gate.
Does a company-wide default make a definition authoritative?
No. Authority comes from its owner and approved source. A default changes where guidance is supplied. Review its audience and applicability before distribution; a broadly supplied rule can still be the wrong rule for a particular customer.
Does removing a user from a group revoke every resource?
Check other grant paths. Orion documents direct project invitations alongside group access. Review saved artifacts and delivery routes against your organization's removal policy too; do not infer their behavior from group membership alone.
Should every agent use exactly the same context?
Agents should use consistent authoritative meaning for the same task while respecting different permissions and legitimate scopes. A finance analyst and a customer may reference the same metric without receiving the same supporting records or private operating notes.
What is the best first access-review pilot?
Choose one shared definition, one private exception, one consuming client, and ordinary users with different responsibilities. Complete the worksheet, test allowed and disallowed actions, and resolve the exceptions before expanding the audience. No universal pass percentage substitutes for demonstrating the specific boundaries your deployment needs.
