Before OpenAI Agents Touch Your CRM, Map the Boring Boundaries
By Greg Nowak. Updated 20 August 2026.
An AI assistant that drafts a reply creates work for someone to review. An agent connected to your CRM, helpdesk, mailbox, or file store can change the business before anyone notices. It may send a message, alter a deal stage, expose customer data, or trigger another system.
That does not make agentic automation a bad idea. It means the useful planning starts with boundaries, not prompts. Before choosing a model or polishing a demo, decide what the agent may see, which actions it may take, when a person must intervene, and how you will investigate a mistake.
Start with the business action
“Let the agent update Salesforce” is not a workable requirement. Updating a misspelled job title is materially different from merging accounts, changing an opportunity stage, deleting a note, or emailing a customer.
Write each proposed action as a small operational rule. For example: “The agent may create an internal follow-up task on the current opportunity, using one of five approved task types. It may not change the opportunity owner, value, stage, or close date.” That rule is specific enough for an operations lead to approve and a developer to implement.
Then identify the system of record. If the CRM owns account and opportunity data, another database should not quietly become a competing source of truth. If the helpdesk owns ticket state, the agent should not maintain an unofficial status in a spreadsheet or model memory.
| Boundary | Question to answer | Good first-release control |
|---|---|---|
| Data | Which records and fields are genuinely needed? | Allow named objects and fields; deny everything else. |
| Identity | Whose authority is the agent using? | Use a dedicated integration identity with an accountable owner. |
| Actions | What may it create, change, send, or delete? | Start with read-only or draft-and-queue access. |
| Approval | Which actions require human judgement? | Pause before customer-visible, financial, destructive, or permission-changing actions. |
| Evidence | Can the team reconstruct what happened? | Record inputs, retrieved sources, tool calls, approvals, results, and failures. |
| Recovery | How is a bad action contained? | Add rate limits, a kill switch, rollback instructions, and a named incident owner. |
Treat permissions as product design
The agent should receive the smallest combination of data and tools that can complete the approved task. Microsoft distinguishes delegated access, where an application acts for a signed-in user, from application access, where it operates under its own identity. The distinction matters: a personal login can inherit surprising access, while an overpowered application identity can reach far beyond one employee’s records.
Read-only is a sensible starting point, but it is not risk-free. An agent that cannot edit the CRM may still retrieve confidential notes and place them in an inappropriate response. Limit read scope by record type, field, team, region, or purpose where the platform permits it. Avoid shared administrator credentials and long-lived tokens without ownership, rotation, and revocation procedures.
A practical authority ladder is:
- Read and recommend: retrieve approved context, then propose a next step.
- Draft and queue: prepare a note, reply, task, or field change for review.
- Bounded execution: perform explicitly listed, low-impact actions with validation and logging.
Move upward one action at a time. A successful summarisation pilot is not evidence that the same agent should be allowed to send refunds or merge customer records.
Put approval around the tool call
A vague instruction such as “ask before doing anything important” is too dependent on model judgement. Approval should be enforced by the workflow around the actual tool. OpenAI’s Agents SDK supports pausing a run before a sensitive tool call, letting a person approve or reject it, and then resuming from saved state.
The reviewer needs to see the concrete action: the target record, fields being changed, recipients, message content, and material data being shared. Approval of a friendly summary is not approval of a different API payload assembled later.
Do not require confirmation for every harmless lookup. Excessive prompts encourage rubber-stamping and destroy the time saving. Reserve mandatory review for actions that are customer-visible, costly, hard to reverse, legally significant, destructive, or capable of changing permissions.
Test prompt injection where the agent works
Prompt injection is not confined to the chat box. Instructions can arrive through customer emails, ticket descriptions, CRM notes, uploaded documents, websites, and third-party enrichment data. Current OWASP guidance for agentic applications frames the broader problem through risks including goal hijacking, tool misuse, and identity or privilege abuse.
Test hostile content in every untrusted source the workflow reads. Try instructions that ask the agent to ignore policy, reveal another customer’s data, change the wrong record, call an unapproved tool, or bypass review. A passing test means the surrounding controls prevent the action—not merely that the model usually declines it.
Use several layers together: narrowly described tools, strict input and output schemas, server-side validation, least-privilege API scopes, approval gates, rate limits, and monitoring. Prompt wording is useful, but it is not an access-control system.
Keep a business-readable audit trail
OpenAI’s Agents SDK can trace model turns, tool calls, handoffs, and guardrail events. Those technical traces are valuable, but operations teams also need a record they can understand: which business object changed, why it changed, what source supported the decision, who approved it, and whether the downstream system accepted it.
Decide what sensitive information may appear in traces, who can inspect it, and how long it is retained. Logging everything indefinitely can create a second security problem. Redaction and retention should be part of the design, not cleanup after launch.
Roll out one narrow workflow
- Choose a high-volume task with a clear owner and a tolerable failure mode.
- Document the system of record, data scope, permitted actions, and prohibited actions.
- Run in read-and-recommend mode using representative and adversarial test cases.
- Measure corrections, approval decisions, failures, and unexpected tool attempts.
- Grant bounded execution only to actions that have earned it.
Good early candidates include internal ticket summaries, CRM research briefs, routing recommendations, renewal-preparation notes, and draft follow-up tasks. These can save real time without immediately handing the agent control of sensitive customer communication.
Turn the boundary map into a buildable plan
This work crosses sales operations, support, security, integration architecture, and day-to-day ownership. Greg can help turn those perspectives into a scoped workflow: mapping systems of record, translating business rules into permissions, defining approvals and injection tests, and planning a rollout the team can operate after the demo.
If you are considering an OpenAI agent for CRM or support work, talk to Greg about mapping the boundaries before production access.
Related on GrN.dk
- OpenAI's Guardrails and Run State Make Internal Agent Rollouts a Paid Approval-and-Audit Job
- A Voice Agent Is Only Ready When the Human Handoff Works
- Agentic AI: What It Is, How It Works, and When to Use It
Need help with this kind of work?
Plan a controlled agent rollout Get in touch with Greg.