How HubSpot Handles Access Control
HubSpot uses a role-based access control (RBAC) model designed for human users inside the HubSpot UI and API.
User Roles and Permission Sets
HubSpot organizes permissions through permission sets — predefined bundles of privileges assigned to users. Key features:
- Super Admins have unrestricted access across the entire portal. They manage users, billing, and all settings.
- Permission Sets are created in the HubSpot UI (not via API) and bundle granular permissions together. Examples: “Marketing Manager” might get email send + campaign edit + report view, while “Sales Rep” gets deal create + contact edit but no marketing access.
- Teams group users for ownership-based filtering. A sales rep on “Team West” can be restricted to only see deals owned by their team.
- Object-Level Permissions control what a user can do with specific CRM objects — view, edit, create, or delete contacts, companies, deals, tickets, etc.
- Field-Level Permissions (Enterprise tier) restrict visibility of sensitive fields. A support rep might see a contact’s email but not their deal value.
API Access Control
For API integrations, HubSpot uses OAuth scopes and private app tokens:
-
Each private app or OAuth connection is granted specific scopes like
crm.objects.contacts.read,crm.objects.deals.write,settings.users.read - Scopes are coarse-grained — you grant access to an entire object type, not individual records
-
There’s no per-record or per-field filtering at the API level — a token with
crm.objects.contacts.readcan read all contacts - Rate limits (100 requests per 10 seconds for OAuth apps) are the only throttle
What HubSpot Doesn’t Do
HubSpot’s permission model was built for a world where humans click buttons in a UI. It has blind spots when AI agents enter the picture:
- No agent identity — HubSpot sees an API token, not which AI agent used it. Ten different agents sharing one token are indistinguishable.
- No operation-level granularity at the API layer — A token that can create deals can also delete them. There’s no way to say “this token can create but never delete.”
- No behavioral guardrails — HubSpot can’t enforce “don’t send more than 5 emails per hour to the same contact” or “require human approval before bulk updates.”
- No cross-system awareness — HubSpot doesn’t know what an agent did in Slack, your CRM, or your support system before it hit HubSpot’s API.
- No temporal permissions — You can’t grant “access for 2 hours” or “access only during business hours” natively.
How The Orchestrator Handles Access Control
The Orchestrator’s access control layer was designed for a multi-agent world from the start.
Agent-Level Identity
Every request passes through a permission check that knows exactly which agent or user is acting. The Orchestrator doesn’t just see a token — it sees “Agent X, owned by User Y, with permission set Z.” Each agent has its own identity, its own permission boundaries.
Operation-Level Granularity
Permissions in The Orchestrator are defined at the tool level. A HubSpot integration could expose separate MCP tools — hubspot_create_deal, hubspot_read_contacts, hubspot_send_email — each with its own permission key. An agent can be granted hubspot_read_contacts without getting hubspot_send_email. This is finer-grained than HubSpot’s API scopes allow.
Behavioral Guardrails
The Orchestrator can enforce policies that HubSpot can’t:
- Rate limiting per agent, not just per API token
- Content validation before data hits HubSpot (e.g., reject emails containing certain keywords)
- Approval workflows — an agent drafts a bulk update, a human reviews before it executes
- Volume caps — “this agent can create at most 10 deals per day”
Temporal and Conditional Permissions
The Orchestrator supports TTL-based permission grants. An agent can be given HubSpot write access for a 4-hour window during a campaign launch, then it expires automatically. No one needs to remember to revoke it.
Cross-System Audit Trail
When an agent reads from HubSpot, writes to Slack, and updates the local CRM, The Orchestrator logs the entire chain. HubSpot only sees its slice. The Orchestrator sees the full picture — which matters when you’re debugging why an agent sent the wrong email to the wrong contact.
Complementary, Not Redundant
This is not an either/or question. The two systems operate at different layers:
| Concern | HubSpot | The Orchestrator |
|---|---|---|
| Who can log into HubSpot? | HubSpot handles this | Not involved |
| What can a human do in the HubSpot UI? | HubSpot’s RBAC | Not involved |
| Which API scopes does an integration get? | HubSpot’s OAuth scopes | Not involved |
| Which AI agent can call which HubSpot operation? | Can’t distinguish agents | Per-agent, per-tool permissions |
| Can an agent delete data vs. only read it? | Coarse (full scope or nothing) | Fine-grained per operation |
| Is there a rate limit per agent? | Only per token globally | Per agent, per tool |
| Can access expire automatically? | No native TTL | TTL-based grants |
| Is there a cross-system audit trail? | Only HubSpot actions | Full multi-system trail |
| Can a human approve before an agent acts? | No | Approval workflows |
HubSpot’s access control protects HubSpot from unauthorized humans. The Orchestrator protects HubSpot (and every other system) from unauthorized AI agents. They’re complementary layers.
The Architecture
Think of it as defense in depth:
- HubSpot’s layer — The API token has the minimum scopes needed. This is the floor.
- The Orchestrator’s layer — On top of that, each agent gets only the specific operations it needs, with rate limits, TTLs, guardrails, and audit trails. This is the ceiling.
If an agent is compromised or misbehaves, HubSpot’s scopes limit the blast radius to object types. The Orchestrator’s permissions limit it further to specific operations, volumes, and time windows. Neither layer alone is sufficient — together they provide the governance that enterprises require before letting AI agents touch customer data.
The question isn’t whether HubSpot’s access control is good enough. It is, for humans. The question is whether it’s enough for autonomous AI agents operating at scale, across multiple systems, without human supervision. That’s where The Orchestrator fills the gap.