Your security questions about OpsGrid and Business Central, answered.
How it connects to BC. What it reads. What it never writes without explicit approval. The engine, the permission model, the audit trail: everything your IT and security teams need before sign-off.
Three components. One data flow. No black boxes.
OpsGrid is built on open standards. Every layer is inspectable during onboarding.
Three admin steps. Three weeks. No middleware to maintain.
What IT and security teams ask before sign-off
Does our Business Central data leave our environment?
Two separate questions. Storage: OpsGrid reads from Business Central at query time using a service account your admin configures. Nothing is copied to an external data store. LLM processing: when OpsGrid generates a recommendation or answer, it sends the relevant BC data chunks to an LLM. If you use an external LLM API (OpenAI, Azure OpenAI, Anthropic, via API keys you provide), the provider processes those chunks on their servers. Standard API terms bar providers from retaining or training on your data. If on-premises inference is a hard requirement, OpsGrid supports self-hosted LLMs: data stays entirely within your environment.
Does OpsGrid write to Business Central autonomously?
No. OpsGrid does not execute autonomously. The service account is configured by your BC admin with write permissions scoped to the specific actions OpsGrid can perform: draft POs, transfer orders, production reschedules. Every write is triggered explicitly by a named decision owner approving in Teams. The governance constraint is: zero writes without a human approval event. This is not a policy setting that can be toggled; it is baked into how OpsGrid is deployed.
What permissions does OpsGrid require in Business Central?
During setup, your BC admin creates a service account with permissions scoped to what OpsGrid needs: read access to the entities it monitors (production orders, purchase orders, inventory ledger entries, sales orders, general ledger budget entries) and write access for the specific operations it performs when a human approves: draft purchase orders, transfer orders, production reschedules. All scoped following standard BC permission set procedures. OpsGrid does not request admin or global access.
Can we audit every decision OpsGrid routes?
Yes. Every signal detected, every card routed, every approval or rejection, every BC write: all logged with timestamp, actor, BC data snapshot at decision time, and outcome. The audit trail is accessible via the OpsGrid dashboard and exportable. For regulated environments: the trail satisfies standard operational control documentation requirements. OpsGrid does not delete or modify audit records.
Is the OpsGrid engine auditable? LangGraph is open source. How do we verify what it does?
LangGraph is open source (Apache 2.0). The graph structure that defines OpsGrid's decision flows is inspectable: every node, edge, and state transition is logged. During onboarding, we walk your IT team through the engine configuration: which BC entities it reads, which thresholds trigger signals, which LLM calls it makes, and what the approval gate enforces before any write. Nothing runs as a black box.
How does OpsGrid handle the Business Central permission model?
OpsGrid operates within the BC permission model, not around it. The service account respects whatever data visibility rules your BC admin configures: if a company or dimension is excluded from the service account's scope, OpsGrid cannot see it. Write access is scoped to specific actions (draft PO, transfer order) and cannot post to entities outside that scope. OpsGrid cannot elevate its own permissions.
Walk through the OpsGrid architecture with your IT team before you commit
We run a technical review session: engine configuration, BC permission scope, data flow, audit trail. Your team sees exactly what OpsGrid does and doesn't do before any BC admin work begins.