Does HubSpot's Audit Logs tool cover what Breeze sends to the underlying AI model?

No. The Audit Logs tool, available on Enterprise plans, records account-level events such as logins, permission changes, and data exports. It documents actions taken inside the HubSpot application. It does not capture the content of a prompt a Breeze feature sent to a model or the policy basis for sending it.

What is the difference between HubSpot's activity timeline and an AI-request audit trail?

The activity timeline shows what changed on a CRM object and who or what changed it. An AI-request audit trail shows what data entered a specific prompt, which identity authorized that request, and which policy was evaluated before the model received it. One describes a record's history. The other describes a single request's authorization.

Can a security team see which customer fields a Breeze agent included in a prompt?

Not reliably through HubSpot's native logging today. The activity feed shows the resulting change, such as a drafted email or an updated note, but it does not consistently expose the underlying prompt content or the specific fields that populated it. Teams that need that visibility typically add a request-level control in front of the model call.

Is HubSpot's security documentation sufficient for a vendor risk review of Breeze?

It answers infrastructure and platform questions well: encryption, access control, and data handling at the account level. It does not answer request-level questions about a specific prompt, a specific user, and a specific policy decision, because that evidence lives at a different layer than platform security documentation is written to cover.

Does adding a policy gateway in front of Breeze replace HubSpot's own permission model?

No. HubSpot's permission model still governs who can access which objects and features inside the CRM. A policy gateway adds a request-level decision and an independent audit record for the AI traffic that HubSpot's own permission model was not built to evaluate at the prompt level.

HubSpot Breeze Audit Logs Need a Request-Level Record

HubSpot Breeze runs as a layer across the CRM rather than as a separate destination a user visits. When a sales rep asks Breeze Copilot to summarize a deal, or a Breeze agent drafts a follow-up email from a contact record, the application pulls fields out of the CRM object, sends that content to the underlying model, and writes the result back onto the record. That round trip is an HTTP request carrying customer data to an LLM, and it happens inside HubSpot's own application layer rather than through a tool the security team configured directly. I want to walk through what HubSpot's existing logging actually captures about that round trip, and where a review still needs a different kind of record.

TL;DR

HubSpot's activity timeline and the Enterprise Audit Logs tool record CRM changes and user actions inside the HubSpot admin console.
Neither was built to show which customer fields entered a specific Breeze prompt or which policy authorized that request.
An AI-request-level audit trail needs the identity, the data that traveled, and the policy decision, tied to one prompt.
CRM record-level audit and AI-request-level audit answer different questions and neither substitutes for the other.

The activity log records what changed, not what was said

Every HubSpot object carries an activity feed: a contact record shows email opens, note additions, deal-stage moves, and workflow enrollments, each stamped with a user or automation and a timestamp. Enterprise accounts add a dedicated Audit Logs tool under account settings, covering events like logins, permission changes, and data exports. HubSpot's own documentation is the source to check for the current event list on a given plan, since HubSpot has extended audit coverage more than once since Breeze launched.

That evidence is genuinely useful for an admin trying to reconstruct who changed a field or exported a list. It answers a record-centered question: did someone touch this object, and what did the object look like before and after. When a Breeze agent runs, the observable trace is typically the outcome, a new note, an updated field, a drafted email sitting in a queue, attributed to the user who triggered the workflow or to the automation itself. The log rarely shows the sentence the agent actually sent to the model or the fields that sentence was built from.

A prompt is a different event than a record edit

I sat in a client conference room this spring while a compliance analyst scrolled a printed activity log, page after page, trying to find the one line that would show what a Breeze agent had actually put into a prompt after a customer complained about a data-handling issue. The log showed a contact record updated at 2:14pm. It did not show which fields from that contact populated the message the agent sent to generate the update, and it did not show under what authorization that specific request went out.

That gap exists because HubSpot Breeze is designed to make the AI call disappear into the workflow. The product goal is a rep who never sees a prompt window. The security cost of that design is that the prompt itself, the request carrying customer data to the model, sits below the layer HubSpot's activity feed was built to describe.

Two different questions need two different records

A CRM audit record answers: did an authorized user perform this action on this object, and when. An AI-request record answers a narrower and harder question: what specific customer data crossed into this specific prompt, on whose authorization, and against what policy. My honest view is that a feature literally named "Audit Logs" invites more confidence than it has earned for AI traffic, and no vendor page says that out loud.

The two records can agree completely and still leave a gap. A record edit can be fully authorized under HubSpot's permission model while the prompt behind it included a deal amount, a support ticket's contents, or a health-adjacent note that a compliance policy would have redacted had anyone evaluated the request before it reached the model. Signed audit logs for AI requests describes the fields that record needs: the acting identity, the route, the data classification, the policy version, and the decision.

What a review should ask for

A security review of a Breeze deployment should start by listing which Breeze features call an external or HubSpot-hosted model endpoint, then ask four things about each one. Does a separate record exist for the prompt content, independent of the resulting CRM change? What is the retention period for that record, and who can read it? Is a data classification available at the moment the request is built, so a policy could act on it? Can a specific user's or role's access to a specific Breeze feature be denied before the model call fires, rather than reviewed afterward.

HubSpot's security page covers the platform's broader controls, encryption, access management, and infrastructure posture. Those controls matter and they answer a different question than the four above. A regulator or a customer's security team asking "what did the AI see about me, and who allowed it" needs the request-level answer, not the platform posture answer. AI audit trail requirements by regulation walks through how that request-level expectation shows up across different regimes, even where the vocabulary differs.

The record has to exist before the request completes

A record built after the fact, assembled from application logs once the response has already reached the rep's screen, cannot support a deny decision. It can only support a postmortem. Why AI security must be inline makes the case that a control positioned after the model has already answered is a reporting tool, not an enforcement point. The same logic applies to Breeze: a record of what a prompt contained is valuable, but a decision on whether that prompt should have gone out at all requires a control sitting on the request path, ahead of the model.

DeepInspect

This is the gap DeepInspect closes for teams running Breeze alongside other AI tools. DeepInspect sits as a stateless proxy between authenticated users or agents and HTTP LLM endpoints, evaluating identity, data classification, and policy on each request before it reaches the model.

Each decision produces its own audit record, independent of the application that generated the request. That record names the acting identity, the classification applied to the prompt, the policy version evaluated, and the outcome, giving a security team a request-level answer that a CRM activity feed was never built to provide.

For organizations running Breeze across Marketing, Sales, and Service Hub, this adds a policy decision and an evidence trail at the point where customer data actually leaves the CRM for a model, without asking HubSpot's own logging to do a job it wasn't designed for. Book a demo today.