Access and Scope Planning

Use this guide before connecting a client or expanding an existing workflow. Access planning should define which endpoint the client uses, which scopes the key holds, who can approve compute or write actions, and how access is reviewed over time.

Planning inputs

Input	Why it matters
Workflow boundary	Defines the tenant, site, asset group, equipment set, scene, or data domain the client can work with.
Endpoint selection	Keeps each client connected to the right governed MCP slice for the task.
Scope set	Controls which tools are visible and which actions are refused.
Review owner	Identifies who accepts outputs, approves actions, and reviews exceptions.
Key owner	Identifies who requests, stores, rotates, and revokes the API key.
Evidence expectation	Defines what source references, timestamps, and review notes must appear in the output.

Endpoint selection

Start with the workflow, then choose the smallest endpoint set that supports it.

Workflow	Primary endpoint	Add only when needed
Facility operations	/mcp/base/	Module endpoints for customer-specific operating signals.
Predictive maintenance	/mcp/pdm/	/mcp/base/ for asset records, documents, and reviewed work-order drafts.
Physical AI	/mcp/base/	Module endpoints for operational signals that should constrain a scene or simulation task.

Use runtime tool discovery to confirm the final visible tool set for the key. Do not rely only on a static list when building the client workflow.

Scope planning

Apply least privilege first. Add scopes only when a reviewed workflow needs them.

Scope type	Typical use	Planning note
Read scopes	Asset context, documents, operating records, health summaries, scene metadata, and source references.	First pilots should usually start here.
Compute scopes	Simulation preparation, forecasting, optimization, comparison, or summarization jobs.	Require an engineering owner for assumptions and output review.
Write scopes	Drafting work orders, inspection tasks, review notes, or scenario records.	Use only after the approval path and audit record are defined.

When a workflow uses multiple endpoints, document why each endpoint is needed. If one endpoint can satisfy the task, keep the configuration simple.

API key lifecycle

Each key should have an owner, purpose, scope list, and review date.

Stage	Required decision
Request	Workflow name, endpoint, scopes, owner, and expected client.
Issue	Key shown once to the owner and configured in the approved client.
Use	Client sends X-API-Key on each request and lists tools at runtime.
Review	Owner checks whether scopes still match the workflow boundary.
Rotate	Replace the key when ownership, client runtime, or access policy changes.
Revoke	Remove the key when the workflow is retired or the client is no longer approved.

Approval boundaries

Separate analysis from action.

Action type	Default behavior
Read-only summary	Allowed when the key has the matching read scope and the output cites source records.
Compute job	Allowed only when the key has compute scope and the workflow records assumptions, input boundary, and review owner.
Work-order or inspection draft	Allowed only when write scope exists and the workflow keeps the record in draft until a person approves it.
Operational change	Keep outside automated execution unless the customer has defined a separate controlled change process.

Access review checklist

• Endpoint and scopes match the workflow boundary.
• Runtime tool discovery shows only the expected tools.
• The client does not pass tenant identifiers as a substitute for key-based authorization.
• Compute and write actions have named reviewers.
• Source references and timestamps are visible in accepted outputs.
• Key owner and review date are documented.
• Rotation and revocation steps are known to the operating team.