Skip to content
redactsure
Book a demo

Explore.

Data Report · By Chris Sowa · Published
Last updated

Does HubSpot Breeze Expose Customer Information?

It depends on administrator switches: standard contact, deal and ticket fields flow to Breeze agents, now in Agent Hub, once a Super Admin turns on CRM data, only custom Sensitive Data properties are withheld, and model training is on unless an admin opts out. Check the CRM data switch, the Sensitive Data list and the training setting first.

Customer profile and activity cards pass through a data boundary along several connected information streams.

It depends on administrator switches: standard contact, deal and ticket fields flow to Breeze agents, now in Agent Hub, once a Super Admin turns on CRM data, only custom Sensitive Data properties are withheld, and model training is on unless an admin opts out. Check the CRM data switch, the Sensitive Data list and the training setting first. HubSpot moved Breeze Agents into Agent Hub on July 23, 2026 (Resolve247, 2026), and the knowledge base now describes administrators configuring what data is shared with AI, deferring the detail of data use to its AI Trust FAQs (HubSpot, 2026). Nothing in the pages reviewed describes agents reaching data outside the portal. The question is which of the portal's own customer fields an agent reads, who decided that, and whether the decision was deliberate or a default left in place. The answer is a chain of three switches, each with a default, and the defaults favor access, the structure API connectors that give an agent more data than the task needs share, applied inside a single CRM. This page sets out which switches govern access, which fields flow by default, how the Sensitive Data restriction works and what it leaves uncovered, what happens once an agent acts or the model trains, how to measure exposure in a specific portal, and which claims a buyer should refuse.

Key findings

  • A Super Admin must turn on the CRM data switch before assistants and agents in Breeze studio can use CRM records, and HubSpot notes that additional permissions may be required depending on the agent's goal (HubSpot, 2026).
  • Once CRM data is on, the documented withholding mechanism is the Sensitive Data restriction, which prevents custom property values for Sensitive Data properties from being used by AI tools; standard properties are not described as withheld (HubSpot, 2026).
  • AI model training on account data is opt-out: Super Admins can opt out at any time, which means the default position for a portal that has not acted is opted in (HubSpot, 2026).
  • The MIT AI Agent Index recorded that approval of agent actions is required by default, that users can switch it off, and that automatically triggered agents run without approval (AI Agent Index, 2026).
  • Breeze Agents moved into Agent Hub on July 23, 2026, so documentation, settings paths and defaults read before that date describe a different arrangement (Resolve247, 2026).
  • Customer records in a CRM are the paradigm case of the data OWASP's sensitive information disclosure entry describes a model surfacing when it has been given access to more than the task requires (OWASP, 2025).

Which administrator switches decide what Breeze agents in Agent Hub can read?

Three, as documented. The first is the CRM data switch. HubSpot's knowledge base for Breeze studio states that a Super Admin must turn on CRM data before assistants and agents can use it, and that additional permissions may be required depending on the goal of the assistant or agent (HubSpot, 2026). Off, agents work without the portal's records. On, they can read them, subject to the other two switches. The second is the Sensitive Data restriction, which withholds custom Sensitive Data property values from AI tools. The third is model training, which Super Admins can opt out of at any time.

Consider a single record type: a customer contact record with associated deal and ticket. It carries name, email, phone, company, lifecycle stage, deal amount and stage, ticket subject and the conversation thread, plus any custom properties the portal has added, say a date of birth collected for an age-gated product and an account number for billing. With the CRM data switch on and no Sensitive Data properties defined, every one of those fields is readable by an agent whose goal calls for it. With the date of birth and account number defined as Sensitive Data properties, those two are withheld and the rest flow.

The Agent Hub overview page describes the general setting, administrators configuring what data is shared in AI settings, and points to the AI Trust FAQs for how data is used (HubSpot, 2026). What granularity that setting offers below the CRM data switch, for instance withholding a standard property or an object type from a specific agent, is not described in the pages reviewed. The architecture as documented is one switch for access, one list for exceptions and one setting for training.

Which customer fields flow to agents by default, and which are withheld?

The honest framing is that the documentation describes what is withheld and leaves the rest to inference. The Sensitive Data page states that restrictions prevent custom property values for Sensitive Data properties from being used by AI (HubSpot, 2026). Two words in that sentence carry the weight. "Custom" means the restriction applies to properties the portal created and designated, not to HubSpot's standard contact, company, deal and ticket properties. "Values" means the restriction is about the content of those fields, not about the record's existence or the other fields on it.

On the contact record, that yields a clear split. Standard fields, the identifying ones such as name, email and phone and the commercially sensitive ones such as deal amount and ticket history, are not described as withheld and should be assumed readable once CRM data is on. Custom fields are readable unless designated as Sensitive Data. Whether the designation is available on every subscription tier, and whether it can be applied to standard properties, are not described in the pages reviewed.

The result is that the fields most organizations would call customer information, who the person is and what they bought, flow to agents by default once the access switch is on. The fields the restriction protects are the ones a portal took the step of designating, which are typically the regulated categories, health details, government identifiers, financial account numbers, that prompted the designation. For a financial services portal, the FTC Safeguards Rule's requirement to control access to customer information and to design safeguards around it applies to the full record, not to the designated subset (FTC, 2026), which is why a buyer should read "only Sensitive Data properties are withheld" as a gap rather than a reassurance.

How does the Sensitive Data restriction work, and what does it leave uncovered?

Dimension HubSpot, per its documentation What a buyer should verify
Access switch Super Admin turns on CRM data in Breeze studio; more permissions may be needed per goal Whether the switch is on, who turned it on and when
Withheld fields Custom property values for Sensitive Data properties are not used by AI The portal's actual Sensitive Data property list, and which standard fields hold regulated data
Standard properties Not described as withheld Which standard fields an agent can read for each goal
Model training Super Admins can opt out at any time Whether the portal has opted out, and when
Action approval Required by default per the Index; users can switch it off; automatic triggers run without it Which agents run on triggers, and whether approval is still on
Data use detail Deferred to the AI Trust FAQs What the FAQs state about retention and sub-processors

The restriction is a property-level exclusion. It works for a portal that has already done the classification work: identified which custom fields hold regulated values and designated them. It leaves three things uncovered. First, standard properties, which are not described as eligible and which hold the identifying and commercial fields. Second, free text. A ticket thread or a deal note can contain anything a customer typed, including the account number the portal designated elsewhere, and a property-level exclusion has no view inside prose. Third, undesignated custom fields, which a portal adds over years and rarely audits.

The Index adds a fourth: approval of agent actions is on by default, can be switched off, and does not apply to automatically triggered agents. An agent that reads the full contact record and then runs on a trigger moves customer information without a person seeing it. The restriction governs what the model reads from designated fields; it does not govern where the model sends what it read from the others.

What happens to customer information once an agent acts or the model trains?

Two further paths carry customer information beyond the read. The first is action. Breeze agents send emails, update records, draft responses and route tickets, and the Index finding that automatically triggered agents run without approval means some of those actions happen with no human review of the content (AI Agent Index, 2026). On the contact record, a triggered agent that drafts and sends a follow-up email has carried whatever it read, the deal amount, the ticket history, into an outbound message. Whether the recipient should see those details is a question the trigger never asks. OWASP's excessive agency entry describes this exact combination, broad read access plus autonomous action, as the condition under which a well-behaved agent causes a disclosure (OWASP, 2025).

The second path is training. HubSpot's documentation states that Super Admins can opt out of AI model training at any time (HubSpot, 2026). The sentence establishes that the default is in. A portal that has never visited the setting is contributing account data to model training, and the page reviewed does not describe which fields, whether Sensitive Data properties are excluded from training as they are from AI tools, or how long contributed data persists. Those are the questions to put to the AI Trust FAQs the Agent Hub page points to.

Both paths share a feature: they are governed by a default rather than a decision. Approval is on until someone turns it off or builds a trigger. Training is on until someone opts out. A shadow AI agent is usually described as one security never knew about; an agent that security approved without visiting these two settings is a close cousin.

How should an organization measure its own exposure in a specific portal?

Audit the three switches, then test one agent. Record the state and change history of the CRM data switch, the Sensitive Data property list and the training opt-out. For each, note who set it and when; the Agent Hub migration on July 23, 2026 is a useful boundary, because settings and defaults read before it may describe a different arrangement. Then export the property schema for contacts, companies, deals and tickets and mark every field that holds identifying, financial, health or other regulated values. Compare that marked list with the Sensitive Data list. The difference is the set of fields an agent can read that the organization would not have chosen to share.

Next, take one agent with CRM data on, give it a task against a test contact record whose fields are known, and capture what it produced. If the portal can surface the agent's context or reasoning, capture that too. Count the fields that appeared in the output or context, and mark which were standard, which were undesignated custom fields and which were free text. Then run the same agent on a trigger and observe whether anything paused before the action. The NIST AI Risk Management Framework's Map and Measure functions ask organizations to identify the data an AI system uses and to measure against their own context; a per-field count on a real record schema is that measurement (NIST, 2023).

Finally, write down what the measurement cannot see. The pages reviewed do not describe a per-agent log of fields read, so the count above is reconstructed from outputs rather than observed directly. That limitation belongs in the risk register alongside the count.

What does a governed environment change?

In a governed environment, the standard contact, deal and ticket fields that flow to an agent once the CRM data switch is on reach the model as tokens, so the protection no longer depends on which custom properties a portal designated as Sensitive Data.

The mechanism is a class of control that works on the rendered record rather than on the vendor's property list. Sensitive values on the screen, standard fields and free text included, are replaced with consistent tokens before any model reads them, and the task runs on those tokens. Real values resolve only at an approved destination at the moment of an approved action. A named person confirms what is tokenized and approves consequential actions, including payments, submissions and record changes, from a screen that shows the content of the change rather than a prompt that omits it. Every screen as tokens, every action and every approval is recorded and exported to the organization's own logging.

This bears on three of the four questions above. HubSpot's restriction prevents AI tools from using custom property values marked Sensitive Data, and nothing in the pages reviewed extends it to standard properties (HubSpot, 2026); tokenizing the record covers the fields the restriction leaves out. The Index records that approval is on by default, can be switched off, and does not apply to automatically triggered agents (AI Agent Index, 2026); an environment-level approval applies regardless of trigger. And values the model never read in clear form are not available for training.

The control does not change the HubSpot portal, the CRM data switch, the training opt-out, user permissions or the model; those settings still need to be checked and recorded as described above.

Where does RedactSure sit?

The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company. Where HubSpot's controls decide which designated fields an agent may read inside the portal, RedactSure's design decides what any model sees on any screen, including a CRM contact record, regardless of the portal's switches. Work runs in a governed environment in the customer's cloud. Substitution happens at the render layer before any model reads the screen, so the contact's name, email, account number and deal amount appear to the model as consistent tokens such as ACCT_001 or PATIENT_001 for the whole run, standard property, custom property and free text alike. Real values resolve only at approved destinations at the moment of an approved action, so an outbound email carries real values only where a person approved that destination. A named person confirms the tokenization policy and approves every payment, submission and record change, a model RedactSure calls Supervised Delegation. Every screen as tokens, every action and every approval lands in the AI Control Record and exports to the customer's SIEM. The design is model agnostic, requires no per-application integration, and leaves user permissions unchanged.

Deployments are in pilot. A pilot on the reader's own contact and ticket workflow would show, field by field, which customer values a portal-native agent would have read and which the model saw as tokens instead, with the AI Control Record as the evidence. Everyone else controls where data can go. RedactSure controls what the AI can see.

Methodology and limitations

This page rests on HubSpot's published knowledge base: the Agent Hub overview, the Breeze studio tools page, the Sensitive Data page and the AI model training page, each carrying its update date. It draws on the MIT AI Agent Index entry for Breeze Agents (research dataset), on an industry blog post documenting the July 23, 2026 move of Breeze Agents into Agent Hub (industry analysis), on OWASP's Top 10 for LLM Applications entries on sensitive information disclosure and excessive agency (industry standards), on the FTC Safeguards Rule at 16 CFR Part 314 (regulation) and on the NIST AI Risk Management Framework (official guidance). All sources were read as of October 16, 2026.

No hands-on testing of HubSpot or any other named product was performed. Where this page says a capability is not described in the pages reviewed, it means the specific knowledge base pages listed below do not describe it, which is not a statement that the capability is absent; HubSpot's AI Trust FAQs, which the Agent Hub page points to, were not among the pages reviewed. Vendor features change, and the Agent Hub migration during 2026 is an example; the page carries its date. Statements about RedactSure describe its current design, with deployments in pilot. The contact, deal and ticket record examples describe record types, not any organization; no customer or prospect is described.

Whether a given HubSpot portal's switch settings, Sensitive Data designations, trigger configuration and training election meet an organization's obligations for customer information is a determination for its counsel, its assessors and its own security and compliance officers, not for a research page.

What the record shows

HubSpot's documentation describes agent access to customer information as a chain of administrator settings: a Super Admin turns on CRM data, custom properties designated as Sensitive Data are withheld from AI tools, and model training continues until a Super Admin opts out. The MIT AI Agent Index adds that action approval is on by default, can be switched off, and does not apply to triggered agents. Read together, the record says that standard contact, deal and ticket fields, which are what most organizations mean by customer information, flow to agents in Agent Hub once access is on, and that the protections are exceptions an administrator must configure rather than a floor the platform supplies. A render-layer design of the kind RedactSure describes governs the fields themselves rather than the switches. The test is to name one agent and one task, run it against a known contact record, and count the fields that appeared in what it produced.

Frequently asked questions

Do Breeze agents in Agent Hub read CRM data automatically?

Not until a Super Admin turns on the CRM data switch in Breeze studio, according to HubSpot's knowledge base, which also notes that additional permissions may be required depending on the agent's goal. Once the switch is on, agents can read the portal's records subject to the Sensitive Data restriction. The switch is portal-wide as described; a per-agent or per-object narrowing below it is not described in the pages reviewed, so a buyer should check the setting's state and history.

Which customer fields does the Sensitive Data restriction protect?

Custom property values for properties the portal has designated as Sensitive Data. HubSpot's documentation states that restrictions prevent those values from being used by AI tools. Standard properties such as name, email, phone, deal amount and ticket history are not described as withheld, and free-text fields such as conversation threads are not covered by a property-level exclusion. The protection is only as complete as the portal's designation work, which should be compared against the full property schema.

Does HubSpot train AI models on customer data by default?

HubSpot's documentation states that Super Admins can opt out of AI model training at any time, which establishes that a portal that has not acted is opted in. Which fields are used, whether Sensitive Data properties are excluded from training as they are from AI tools, and how long contributed data persists are not described on the page reviewed; the Agent Hub overview points to HubSpot's AI Trust FAQs for data use detail. Record the opt-out date if the portal has exercised it.

Do Breeze agents ask for approval before acting?

The MIT AI Agent Index recorded that approval is required by default, that users can switch it off, and that automatically triggered agents run without approval. The practical exposure sits in the third clause: an agent that reads a full contact record and then runs on a trigger carries what it read into an email, a field update or a routing decision with no person reviewing the content. A buyer should inventory which agents run on triggers and confirm the approval setting for the rest.

What changed when Breeze Agents moved into Agent Hub?

HubSpot moved Breeze Agents into Agent Hub on July 23, 2026. For a buyer, the practical consequence is that settings paths, documentation and defaults read before that date may describe a different arrangement, and that any internal security review of Breeze completed earlier should be revisited against the current knowledge base pages. The data access switches described on this page are those documented after the move, each page carrying its own update date.

How can an organization find out what its own agents can read?

Audit the CRM data switch, the Sensitive Data property list and the training opt-out, with dates. Export the property schema, mark every field holding regulated or identifying values, and compare it with the Sensitive Data list; the difference is the exposure. Then run one agent against a known test record and count the fields that appear in its output, including free text. A render-layer control such as RedactSure's design adds a record of what the model saw as tokens.

Book an AI Agent Security Review →

Bring your hardest questions.

Bring one sensitive workflow and the decisions your team needs to keep in its hands.

Book a demo

About the author

Christopher Sowa
Chris SowaCo-Founder, President and Chief Commercial Officer, RedactSure

Chris Sowa is a founder of RedactSure and a former CEO of an AI company; he started it years before ChatGPT existed. He previously led AI at Accenture, served as Global VP of Strategy & Innovation at Schneider Electric, was CCO of Sovos, and spent more than a decade at Oracle, with earlier roles at SAP and IBM.

Book a demo

Book a demo

Having trouble? Open the booking page or email us.