We need to let a contracted marketing agent run a targeted campaign using our HubSpot customer database. They need read access to specific contact fields and the ability to export a filtered list for their external platform.
Our current setup is all-or-nothing user seats, which is a non-starter.
Considering Absolute Secure Access for this. Need to know if it can handle this granularly:
* Can we expose only a pre-filtered view of the CRM (e.g., only contacts with a specific tag or property)?
* Can we restrict which fields they see (hiding financial data, personal notes)?
* What about export controls? Can we block downloads or limit them to certain formats?
* Does the agent need a VPN or any local client software, or is it purely browser-based?
Looking for real-world implementation, not just the spec sheet. What breaks or gets clunky?
null
Absolute Secure Access can technically restrict views with its policy engine, but it won't apply field-level security inside HubSpot itself. That's a crucial distinction.
You're creating a filtered "tunnel" to the entire application. If the agent can log into HubSpot, they see whatever a standard HubSpot user with that seat license can see. The pre-filtered view you want depends on HubSpot's own internal role permissions, which you said are all-or-nothing.
So you'd need to solve the HubSpot permission problem first. Some options:
* A middleware proxy that sits between ASA and HubSpot, stripping out fields.
* Using HubSpot's own API to build a custom portal view, then exposing *that* through ASA.
On export controls, browser-based session recording can detect downloads, but it's a detective control, not a preventative one. They can still screenshot or manually transcribe data from the screen you've allowed them to see.
The real breakage point is the audit trail. How do you prove what data they actually viewed versus what they were allowed to view? ASA logs will show they accessed the app, but you'll need HubSpot audit logs to see the specific records. Make sure those are enabled and being shipped to your SIEM.
Logs don't lie.
Finally, someone cuts through the vendor hype. You're dead on about the breakage point between the access tool and the app's own permissions.
> The real breakage point is the audit trail.
This is where most of these "secure access" solutions quietly fall apart. They sell you on the gateway control, but the actual data access audit is a separate system, often with incompatible logs. You're now correlating events across two platforms for every investigation, assuming the app's logging is even granular enough.
The middleware proxy idea is a theoretical solution that creates a whole new production system you now have to secure, maintain, and monitor. That's not a simple fix; it's a new project with its own attack surface and compliance overhead.
Question everything