Governing HubSpot Breeze AI agents: consent and proof
A prospecting agent acts on people who asked for nothing. It is the one case where the legal basis of the contact — not the transfer — is the central question, and it changes with the recipient's country.
Breeze agents work inside the marketing CRM: they qualify leads, draft sequences, follow up, personalize. Their productivity comes from contacting many people quickly — and that is exactly what makes them a particular compliance case.
Unlike the other integrations in this wiki, the dominant question is not data transfer but the legal basis of the contact itself. Did this person consent? Does that consent cover this purpose? And crucially: the answer changes with the recipient's country — some regimes require explicit prior consent where others admit a framed legitimate interest.
The integration scenario
HubSpot can call external services from its workflows: you insert the decision before the send step and route on the answer. The consent logic you already have in HubSpot stays in place — the authority layer adds the jurisdictional dimension a CRM does not model.
- 1
Generate your organization's profile
The free assessment (start here) establishes the jurisdictions you prospect in, your sector and your data categories. That profile is what separates a decision for a recipient in Quebec from one for a recipient in Europe.
- 2
Create an API key with the authority scope
From your StructureClerk dashboard. Personalized decisions go through the key; evidence verification stays public.
- 3
Insert the decision before the send
In the workflow preceding the sequence or automated send, an external action calls the endpoint with metadata — never the message content or the contact list.
curl -X POST https://structureclerk.ca/api/v1/authority/decide \ -H 'Authorization: Bearer $API_KEY' \ -H 'Content-Type: application/json' \ -d '{"agent":{"id":"breeze-prospecting-agent","autonomy_level":3},"action":{"type":"send.customer_email","data_categories":["personal"]},"context":{"jurisdictions":["CA_QC","FR"],"sector":"tech"}}' - 4
Route on the four verbs
ALLOW lets the sequence go. APPROVE creates a validation task before the send. DENY removes the contact from the sequence and logs the reason. ESCALATE notifies the marketing or compliance owner. The evidence identifier attaches to the contact record.
The decision contract
POST https://structureclerk.ca/api/v1/authority/decide
{
"agent": { "id": "breeze-prospecting-agent", "autonomy_level": 3 },
"action": {
"type": "send.customer_email",
"data_categories": ["personal"]
},
"context": { "jurisdictions": ["CA_QC", "FR"], "sector": "tech" }
}
// →
{
"decision": "APPROVE",
"reason": "external_personal_data_transfer",
"confidence": 0.95,
"evidence_id": "ev_6e2b…d870"
}The decision is advisory — StructureClerk decides, your infrastructure enforces. The engine sees neither your contact list nor your email content: only the action type, data categories and jurisdictions involved.
| Decision | Effect in HubSpot |
|---|---|
| ALLOW | The sequence goes out, evidence attached to the record |
| APPROVE | A validation task is created before the send |
| DENY | The contact exits the sequence, the reason is logged |
| ESCALATE | The owner is notified, the send waits |
Proving the basis of each send
Every decision leaves Ed25519-signed, chained evidence. The day a complaint arrives or a regulator asks, you do not reconstruct a rationale after the fact: you produce the decision as it was rendered at send time, verifiable on our verification page by whoever is asking.
And the jurisdictional dimension does exactly what a CRM does not: the same sequence can go out to one jurisdiction and be held for another, because the recipient's law differs. No suppression list carries that nuance.
+How do I prove consent for automated outreach?
By rendering a decision before each send: the signed evidence carries the jurisdiction, the rule applied and the reason, at the moment of the send. It is a contemporaneous record — not a reconstruction, which is precisely the difference a regulator looks at.
+Aren't HubSpot suppression lists enough?
They prevent contacting whoever asked not to be — necessary, and insufficient. They do not say whether the legal basis of the first contact was valid in the recipient's country, nor whether the consent obtained covers this purpose. They are two complementary layers.
+Is the decision rendered per contact or per campaign?
Both work, depending on the granularity you want. Per campaign is cheaper and often enough when the list is homogeneous. Per contact is more precise when your recipients span several jurisdictions — and that is where the layer adds the most.
+Does the engine see our contacts?
No. The request describes the action as metadata: type, data categories, jurisdictions. Neither the list, nor the addresses, nor the message content are transmitted.
Start with the profile
The assessment is what personalizes the decisions your agents receive. It is free, and only needs your website address.