Read-only AI access to ERP and CRM data: questions to ask before launch

Read-only is a useful starting policy for AI access to ERP and CRM data, but it is not a complete security description. Before launch, make the identity path, source permissions, assistant and provider boundaries, logs, operating responsibilities and separately approved write path explicit.

Define what read-only means in the implementation

A read-only service should expose only operations that retrieve approved data. It should not create, update, delete, approve or submit records. Check this at the connected-tool layer and at the source-system account, so a prompt or configuration mistake cannot turn a read into a write.

List the allowed operations and the data each one can return. Broad database or API access is not a substitute for a clear service boundary.

Give every user an explicit identity path

Decide whether the source sees the individual user, a service identity or both. Record how the assistant session maps to that identity, how access is granted and revoked, and who reviews it. Shared credentials make individual approval and investigation harder and should not be the default.

  • Which people and roles may use the connection?
  • How are they authenticated at the assistant, connection and source?
  • Which source roles, companies, territories, fields and periods may each user see?
  • How quickly does a role change or departure remove access?
  • Who owns periodic access review?

Enforce permissions close to the source

Use the minimum source permissions needed for the approved questions. Preserve source-system controls where practical, and apply any additional filtering in a layer with a named owner and test coverage. Do not rely on prompt instructions to hide restricted records or fields.

Test users who should receive different answers as well as users who should be denied. Include fields that are sensitive even when the surrounding record is allowed.

Trace the complete data path

Document where a request starts, which connection and tools handle it, which systems receive it and where prompts, results, logs or caches may be retained. Include the selected AI assistant plan, provider settings, hosting location and any subprocessors or gateways that are part of the agreed route.

Assistant and connector features vary by provider, plan, workspace settings and deployment method. Verify the current combination for the customer rather than treating general product availability as proof of compatibility. The AI Assistant Compatibility reference explains the checks to make.

Decide what is logged and who responds

Useful operating evidence can include authentication events, tool calls, source outcomes, rejected requests and service failures. Record who can read those logs, how long they are retained and who investigates an incident. Avoid logging more business data than the operating purpose requires.

Define the response path for suspected exposure, compromised credentials, an unavailable source and an answer that does not match a trusted result. Include customer and service-provider responsibilities.

Check answers as well as controls

Security controls do not establish that an answer uses the right business definition. Test representative questions against reports, calculations or known results the business already trusts. Also test denied access, missing data and unsupported questions. These checks form part of the acceptance decision before launch.

Treat every write as a separate approval

If a later use case needs to create or change a business record, do not expand the read-only connection silently. Review the action, preconditions, permissions, approval, failure handling and evidence separately. The Operational Decision System is the service path for controlled system actions when analysis is not enough.

Use a launch checklist with named owners

  • The approved business question, users, sources and data are documented.
  • The connected tools and source account cannot write.
  • Allowed and rejected access paths have been tested.
  • The assistant plan, provider processing and retention choices are recorded.
  • Representative answers have been checked against trusted results.
  • Monitoring, incident contacts, change handling and exit steps have owners.

See the full Security and Data Handling approach, or start with an AI Analytics Assessment to review one question, its data path and the simplest suitable route before any build.