The first time I asked security to approve an agent on the CRM, I sent a Slack message that said, roughly, 'we want to connect Claude to HubSpot to save the reps time, any concerns?' That message started a review that lasted eleven weeks, produced a 40-question vendor questionnaire, and ended with a no that was really a shrug. Nobody on the security side was being difficult. I had handed them a fog and asked them to approve it.
The second time, six months later, I sent a single page. Which fields the agent could read, which two things it could write and who had to click approve first, which login it ran under, what got logged, and who could switch it off. Approved in nine days, with two sensible edits. Same agent, same CRM, same security team. The difference was that I had done their job for them first, which turns out to be the whole trick. This is that page, and the review behind it.
Security says no to fog
Here is what a security reviewer actually hears when a RevOps lead says 'we want to connect an AI to the CRM': an unknown system, reading an unknown amount of customer data, taking unknown actions, under an unknown identity, with unknown logging. Five unknowns. Their job is to make unknowns known, and if you do not do it for them, they do it the slow way, with a questionnaire built for vendors, not for a workflow. Eleven weeks is what that costs.
I call the alternative the one-page review, and it is exactly what it sounds like. One page that converts the five unknowns into five stated facts, each with the vendor document it came from. The reviewer's job shrinks from discovery to verification, and verification is fast. The nine-day approval I got was mostly the security lead checking my citations and asking for two changes, both of which made the agent better.
The rest of this guide is how to fill the page. It is written from the RevOps seat, because that is where I sit: I own the CRM stages, the fields, the integrations, and the process reps run on. Security owns the risk posture. The review is the handshake between those two jobs, and the RevOps side has to extend the hand first, because we are the ones who know what the fields mean.
TipSend the one-pager before the meeting, not in it. A reviewer who has read it arrives with edits; one who has not arrives with a questionnaire.
Review what the agent can do
The instinct is to review the model: is Claude safe, does it train on our data, where is it hosted. Those questions matter and they have documented answers (the data and privacy and compliance guides cover them, and business plans do not train on your data by default). But they are the same for every workflow, so answering them again for each agent is wasted motion. The thing that differs per agent, and the thing that can actually hurt you, is what the agent is allowed to do.
Split every capability into read and write, and treat them as different animals. A read that goes wrong produces a wrong sentence in a chat, which a human ignores. A write that goes wrong changes a deal stage, reassigns an owner, logs a note to the wrong account, or emails a customer, and then the forecast is wrong, the rep is confused, and someone spends Friday afternoon undoing it. I have watched a well-meaning automation advance forty deals to 'Verbal' because a field it keyed on was mislabeled. The agent read correctly. It wrote confidently. That is the failure shape.
So the review says, per agent: here is everything it reads, here are the two or three things it writes, and here is the gate in front of each write. A gate is a human approving the specific action before it happens: a checkbox in a Slack message, an approval step in Claude Code, a draft the rep sends themselves. The safe autonomy guide goes deep on the mechanics; for the review, you only need to name the gate and who holds it.
- Read, allow broadly: contacts, companies, deals, activity history, pipeline reports. Wrong reads are cheap.
- Write, gate every one: stage changes, owner changes, new records, notes, tasks, any outbound message. Wrong writes are expensive and reach other people.
- Delete, forbid: no agent in a GTM workflow needs to delete a CRM record. If a workflow seems to need it, the workflow is wrong.
Classify the fields before you connect anything
Security teams think in data classification and RevOps teams think in fields, and the review is where those meet. Open the CRM's property list, all of it, and sort every field into three buckets. Fine to read: company names, deal stages, amounts, close dates, activity timestamps, owners. Read with care: contact names, emails, phone numbers, job titles, notes bodies, call transcripts. Never leaves the building: anything regulated in your industry, payment details, health or financial data a customer shared, fields your DPA restricts.
This sounds tedious and takes about ninety minutes with a coffee. It is also the single most persuasive thing on the page, because it proves you know what is in the system. I did it on a spreadsheet with three columns, and the security lead's first reaction was to ask why nobody had done it before, which I chose to take as a compliment. The notes and transcript fields are where the surprises live: reps paste all kinds of things into a free-text field, and a call transcript can contain anything a customer said out loud.
The classification then drives the wiring. Most connectors and MCP servers let you scope what the agent can see, either by the permissions of the account you connect with or by naming the objects and fields in the server configuration. Bucket one goes in. Bucket two goes in for the plays that need it, with PII handling written down (the agent drafts to the rep, the rep sends; the agent never posts a contact's email to a shared channel). Bucket three never gets a connector. If a play seems to need bucket three, it needs a conversation, not a config.
TipPut the field classification in a shared sheet and keep it alive. When someone adds a new CRM property next quarter, it goes in a bucket before it goes near an agent.
Whose login is this? The inherited-permissions question
The fact that settles half the review is this, and it is documented in the connector help: when you connect Claude to a tool, it inherits your permissions in that tool, and can only see and do what you can already see and do. That means 'what can the agent access' collapses into 'whose account did we connect'. A rep's connector sees what that rep sees. An admin's connector sees everything. There is no third thing.
This is both the good news and the trap. The good news is that you do not have to invent a permissions model for the agent; the CRM's own roles already are one, and security has already approved those. The trap is that the easiest account to test with is yours, and you are probably a CRM admin. I built the first pre-call brief play on my own login, which could see every field on every record in the instance, and did not think about it until the review asked. The play needed to see a rep's own accounts. It could see the CEO's private deal notes.
So the review names the identity per agent and per surface. For plays a rep runs in the Claude app, the connector runs as the rep, and the review says so: each user connects their own account, scoped by their own CRM role. For automations that run unattended in Claude Code or on a routine, create a dedicated integration user in the CRM with exactly the role the play needs, and connect that. Enterprise plans now also let admins provision connectors through the identity provider so access follows roles on login, which makes 'who is connected to what' a report instead of a hunt.
- Interactive plays (a rep asks Claude in the app): the rep's own connector, the rep's own CRM role. Nothing to invent.
- Unattended plays (a routine or a Claude Code job): a named integration user with a purpose-built CRM role, read on the buckets it needs, write only on the fields the gate covers.
- Never: a shared admin login, a personal admin's token in a script, or a connector 'someone set up' that nobody can trace to a person.
PII in prompts: the part people forget to write down
The data does not only move through the connector. It moves through the prompt. A rep pastes a call transcript into a chat and asks for a follow-up; a routine pulls a contact's email and title to draft a first line; a scoring job sends a thousand records through a model overnight. Each of those is personal data in a request, and the review has to say what happens to it, because that is the question the privacy side of security will ask first.
The facts here are stable and citable. On Team, Enterprise, and the API, Anthropic does not train on your data by default; retention has documented windows, and zero-data-retention arrangements exist for eligible accounts. Put the citation on the page and move on. Then write your own rule, which matters more than the vendor's: what may go in a prompt. My rule is bucket one freely, bucket two only for the specific play that needs it and never into a shared or public surface, bucket three never, and no pasting of anything a customer sent under an NDA into a chat that is not inside a Project with the right access.
The place this goes wrong is the shared Project. Projects are where a team keeps its ICP, positioning, and play instructions, and someone will eventually upload a customer list 'so the agent has context'. Now a spreadsheet of contacts sits in a Project visible to the whole marketing org. Business plans give admins a control to disable public projects, and the review should say the setting is on and that Project membership is reviewed quarterly. It is boring. It is exactly the kind of boring that gets a yes.
TipWrite the 'what may go in a prompt' rule as three lines reps can remember, then put it in the play card for every play. A policy nobody can recite is a policy nobody follows.
Logging and audit: say exactly what you have
The question 'can we see what the agent did' has a different answer per plan, and the review has to give the honest one. On Team and Enterprise, the usage analytics dashboard shows owners who is active, which skills and connectors are used, and spend by model, with a CSV export. On Enterprise, audit logs record organization events (logins, membership changes, project and conversation lifecycle events) for export, and the Compliance API exposes them to your SIEM and to the governance tools built on it. Team does not get audit logs. If you are on Team, write that down; a reviewer who finds it out later trusts the rest of the page less.
The gap most people miss is that the vendor's logs tell you what happened in Claude, and your CRM's logs tell you what happened to the CRM. The join is yours to build. Every write the agent makes should carry a fingerprint the CRM records: a note prefixed with the play name, an activity typed as 'agent', an owner field set to the integration user. Then 'show me everything the agent changed last week' is a CRM report, not a forensic exercise. I learned this the week a stage change nobody could explain turned out to be mine, made by a routine, under my login, with nothing to mark it as automated.
For unattended jobs in Claude Code, add a plain log of your own: what the job read, what it proposed, what a human approved, what was written, with timestamps. The hooks guide shows how to fire that on every tool call. Security does not need it to be fancy. They need it to exist, and they need to know where it lives.
- Team and Enterprise: usage analytics (active members, skills, connectors, spend by model), CSV export. Cite the help center article.
- Enterprise only: audit log export and the Compliance API. If you do not have Enterprise, say so.
- Yours to build: an agent fingerprint on every CRM write, and a job log for unattended runs. This is the line reviewers care about most and vendors cannot give you.
The vendor questions, answered before they are asked
Every security team has a vendor questionnaire, and yours will land on your desk whether or not you prepare. Preparing means answering the eight questions that always appear, with the link, before the questionnaire arrives. Most of the answers live in the Trust Center and the help center; the remaining ones are about your setup, not the vendor's.
The two answers that carry the most weight are the ones about actions. 'Does the system take autonomous actions?' The honest answer is: it can, and here is the list of the ones we allow, each gated. 'Can it be disabled?' Yes, in under a minute, by disconnecting the connector or revoking the integration user's token, and here is who holds that. A reviewer who sees a kill switch with a name on it relaxes visibly. I have watched it happen.
- Is our data used to train the model? Business and API tiers: not by default. Link the privacy documentation.
- Where is data processed and how long is it retained? Link the Trust Center and the retention documentation; name your plan's setting.
- Which certifications does the vendor hold? Link the Trust Center's current list rather than typing acronyms that go stale.
- How does the agent authenticate to our CRM? Per-user OAuth for interactive plays; a named integration user for unattended ones. No shared credentials.
- What can it read? The bucket-one and bucket-two field list, attached.
- What can it write? The gated list, with the gate and the approver named.
- What is logged? Vendor logs by plan, plus the agent fingerprint and job log you built.
- How is it switched off? Disconnect, revoke, pause. One minute. Named owner.
Writing the one page that gets a yes
Everything above compresses onto a single page, and the compression is the point. Seven headings: purpose (one sentence, the play and the reps it serves), data read (the field buckets), actions and gates (the write list), identity (whose login, per surface), prompt rule (three lines), logging (vendor by plan, plus yours), and kill switch (who, how, how fast). Under each heading, two to four lines and a link. If a heading needs a paragraph, the design of the agent is too vague, and the review is telling you that before security does.
Two edits my reviewer made that I now put in every review: a review date, because the agent's permissions should be re-checked when the play changes or a quarter passes, whichever comes first; and a named business owner separate from the technical owner, so that when I leave or change roles the agent does not become an orphan with a live token. Both took a line. Both would have taken me a year to think of.
Then the last thing, which is a habit rather than a heading: start the agent read-only and run it for two weeks before you ask for the first write. Bring the reviewer the log from those two weeks. 'Here is what it read, here is what it would have written, here is how often a human would have changed the draft' is the most convincing security document I have ever produced, and I did not write a word of it.
- What can it read?Field buckets: fine / with care / never
- What can it write?Two or three actions, each behind a named human gate
- Whose login does it run under?The rep's own connector, or a role-scoped integration user
- What goes in a prompt?Three-line rule; no customer lists in shared Projects
- What is logged?Vendor logs by plan + your fingerprint on every CRM write
- How is it switched off?Disconnect / revoke / pause, under a minute, named owner
TipKeep the one-pager in the same folder as the play card and the field classification. When a new agent is proposed, copy the last one and change the specifics. The third review takes an afternoon.
Where it goes wrong
Building on the admin's login. It works, so nobody questions it, and the agent can see every field on every record until the day someone asks. Test on a role-scoped account from the first day, even when it is slower.
Reviewing the model instead of the workflow. Three meetings about training data, zero about the fact that the routine can change deal stages. The model questions have documented answers; the workflow questions are yours, and they are the ones that bite.
The free-text field surprise. Notes and transcripts are treated as harmless because they are 'just text', and then a customer's health condition, mentioned on a call, ends up summarized in a Slack digest. Classify the free-text fields as bucket two at minimum and decide per play whether they go in.
Logging that exists but nobody joined. The vendor logs say a connector was used; the CRM says a field changed; nothing links them. Fingerprint every write and build the report before the first incident, not after.
The orphaned agent. The person who built it changes roles, the integration user keeps its token, the routine keeps running, and eighteen months later it is doing something nobody can explain. A named business owner and a quarterly review date on the one-pager are the whole fix.
The GTM version
If you are the RevOps lead, here is the shape of it. You own the fields, so you classify them. You own the process, so you name the actions and the gates. You know the roles, so you pick the identity. Security owns the posture, so you cite their vendor facts and hand them a page with the five unknowns already known. The agent gets approved because you made it boring, and boring is the highest compliment a security review can pay.
Start with the play that reads a lot and writes nothing, the pre-call brief or the Monday pipeline digest. Run it read-only for two weeks under a role-scoped account, bring the log, get the yes. Then add the first gated write, the post-call note, with a rep approving each one. By the third agent the review is a template and the security lead is asking you what else you want to connect. Which play would you put on the first page?
How to set it up
Classify the CRM fields into three buckets
Export the property list from your CRM and sort every field into fine-to-read, read-with-care, and never. Do it in a shared sheet with an owner column. The free-text fields (notes, transcripts, descriptions) go in read-with-care at minimum. Budget ninety minutes; it is the most persuasive artifact on the page.
TipAsk Claude to do the first pass: paste the property names and descriptions and ask for a proposed bucket per field with a one-line reason. You will correct a dozen; it saves an hour.
Write the actions list with a gate on every write
For the specific play, list every read and every write. Reads get a broad allow within the buckets. Each write gets a named gate: who approves, where (a Slack checkbox, a Claude Code approval, a draft the rep sends), and what happens on a no. If a write cannot be gated, the play does not get that write yet.
Pick the identity per surface
Interactive plays in the Claude app: each rep connects their own account, and the connector inherits their CRM role. Unattended plays: create a named integration user in the CRM with a purpose-built role scoped to the buckets and writes above, and connect that. Record both on the page. Never a shared admin login.
Run read-only for two weeks and keep the log
Ship the play with zero writes. Log what it read, what it proposed, and what a human would have changed. Fingerprint any future write with the play name and the integration user so the CRM's own reports can find it. Add a hook or a plain log file for unattended runs.
Write the one page and send it before the meeting
Seven headings: purpose, data read, actions and gates, identity, prompt rule, logging, kill switch. Two to four lines and a link under each. Add a review date and a named business owner. Attach the field sheet and the two-week log. Send it forty-eight hours before you meet, and arrive expecting edits, not a questionnaire.
Frequently asked questions
What should an AI security review cover for a sales or RevOps agent?
Five things: what data the agent can read (classified by field, with PII named), what it can write (each write behind a human gate), whose login it runs under (connectors inherit the user's permissions), what is logged (vendor logs by plan, plus your own fingerprint on CRM writes), and how it is switched off, by whom, how fast. Put the answers on one page with citations.
Is it safe to connect Claude to HubSpot or Salesforce?
With the right identity and gates, yes. The connector inherits the permissions of the account that connected it, so it cannot see more than that person can. Allow reads broadly, gate every write behind a human approval, forbid deletes, and start read-only for two weeks before you add the first write.
Does Claude train on our CRM data?
On Team, Enterprise, and the API, your data is not used to train models by default, and retention windows are documented, with zero-data-retention arrangements for eligible accounts. Cite the current privacy documentation and Trust Center on the review rather than paraphrasing; the wording matters to security teams.
Should the agent run under an admin account?
No. Admin accounts see every field on every record. Interactive plays should run as each rep, through their own connector. Unattended routines should run as a named integration user with a purpose-built CRM role scoped to exactly the objects and writes the play needs.
What logging do we get, and does it depend on the plan?
Team and Enterprise get the usage analytics dashboard (active members, skills and connectors used, spend by model, CSV export). Enterprise adds audit logs and the Compliance API. On any plan, build your own layer: a fingerprint on every CRM write so the CRM's reports can find agent changes, and a job log for unattended runs.
How do we handle PII in prompts?
Write a three-line rule reps can recite: bucket-one fields freely, bucket-two only for the play that needs it and never into a shared or public surface, bucket-three never. Keep customer lists out of shared Projects, disable public projects at the org level, and review Project membership quarterly.
How long should the review take?
With a one-page write-up sent ahead of the meeting, one to two weeks is typical, most of it the reviewer verifying citations. Without it, expect a vendor questionnaire and a quarter. The classification sheet takes ninety minutes; the page takes an afternoon; the read-only run takes two weeks and is worth every day.
What is the kill switch, concretely?
Disconnect the connector in the Claude app, revoke the integration user's token in the CRM, or pause the routine or scheduled job. All three take under a minute. The review names the person who holds it and a backup, so the agent never depends on one calendar.
Sources & further reading
- MCP connectors and inherited permissions (Claude Help Center)
- Authorize MCP connectors for your entire organization (Claude Help Center)
- View usage analytics for Team and Enterprise plans (Claude Help Center)
- Access audit logs (Claude Help Center)
- Access the Compliance API (Claude Help Center)
- Anthropic Trust Center
- Anthropic Privacy Center
Claude ships fast. This page was last reviewed Sep 4, 2026; verify time-sensitive details against the official docs above before relying on them.