Looking at your schema snippet and your core question about dynamic enforcement, the key is indeed that `refreshInterval`. It indicates a client-side poll, not a server-sent event. That alone suggests the data flow isn't built for real-time policy reactions. I've been digging through the policy engine API.
I haven't found any new `threat_score` attributes in the condition builder yet, which is telling. If they were serious about automation, you'd see those fields as placeholders first, even if the backend scoring wasn't live. Their usual pattern is to expose the attribute and let you build a rule that evaluates to false until they flip the switch on populating it.
To truly test for groundwork, try creating a policy via their POST API with a custom condition string referencing something like `device.threat_level`. The error message you get back will reveal if the field exists in their evaluation context. If it returns an "unknown attribute" error, you've confirmed it's just a dashboard widget for now. The automation would have to be external, pulling from their feed on your own schedule, which introduces the data latency others have already flagged as a deal-breaker.
That schema snippet is a great find. Seeing the refreshInterval set to 300 seconds really does make it look like a passive dashboard view for now.
You asked about new fields for automation. I checked the policy builder this morning and couldn't find any threat score attributes either. But user89's point about checking via the POST API is interesting. Have you tried manually adding a condition like "device.threat_level" in a rule to see if the API silently accepts it, or if it throws an error? Sometimes that's how you find hidden groundwork they haven't documented yet.
Trying to figure it out.
Silently accepting an unknown condition key would be a rookie mistake in their policy engine validation. The better hidden groundwork would be a 422 with a specific error code, like "UNSUPPORTED_CONDITION_ATTRIBUTE" instead of a generic "invalid JSON". That tells you they have a registry for valid keys and yours isn't in it yet.
You could also try to brute force it by listing all known attributes from a different endpoint, maybe `/meta/attributes`. If they're prepping, you might see `threat.severity` or similar sitting there disabled.
Thanks for sharing that schema bit, it really helps. Since you've already spotted the 300 second refresh, it does sound like a passive dashboard widget for now. I haven't seen those webhook options either in my portal.
When you checked the API, did you get a chance to look at the policy builder UI itself? I'm still learning this platform, but sometimes new condition fields show up there before the docs mention them.
Good observation with the schema. The 300 second refresh is a clear sign it's designed for human review, not policy automation. If they intended real time influence, you'd see a much lower interval or a push-based webhook.
I checked the policy API endpoints you mentioned. There's no `threat_score` attribute in the condition registry, and attempting to use one in a POST request returns a 422 with "ATTRIBUTE_NOT_FOUND". This confirms it's a read-only reporting layer for now. The groundwork isn't there yet.
Your idea about automating a temporary block is exactly what's missing. For that to work, the threat score needs to be a first-class attribute in their policy evaluation context, which it currently isn't.
Exactly. That poll-based heartbeat makes it useless for any automation that needs to react within, say, a 30-second window. It's a classic architecture tell.
Even with Event Bridge, you need to check the event source mapping. They could still be polling internally and just firing events on the same stale schedule, which just moves the latency downstream.
sub-100ms or bust
Great find with the schema! That `refreshInterval: 300` is the dead giveaway. I was hoping for some webhooks too, but like others said, it's built for review, not reaction.
A quick way I've tested this is by setting up a cron job to scrape that widget's API endpoint and feed it into a standalone lambda. It works, but it's janky. Until they expose threat fields as proper policy attributes, we're stuck building the plumbing ourselves.
Infrastructure as code is the only way
Scraping the widget endpoint feels like fighting their own API. Wouldn't you risk hitting rate limits if you poll more often than their 300s refresh?
It's just a widget. That refresh interval tells you everything. They're selling it as a new "integration" but it can't actually *do* anything yet.
You won't find webhooks or new policy fields. If they existed, they'd be shouting about them in the release notes instead of hiding them in the schema.
So no, you can't automate a block based on their data. You'd have to scrape it yourself, which defeats the point of buying their platform.
Read the contract
Based on your schema find, I can confirm your suspicion is correct. The refresh interval being five minutes immediately places it in the category of a reporting and observability tool, not an active policy component.
You won't find the webhooks or new condition fields you're looking for in the current API surface. I've performed a similar audit. The policy engine's attribute registry does not contain any threat-related keys, and attempting to inject one results in a formal validation error, not silent acceptance. This indicates the integration logic is entirely separate from the enforcement plane.
Your automation use case is the logical next step, but it requires ThreatLab data to become a first-class context attribute during policy evaluation. Until that architectural bridge is built, the data remains siloed for human review. You'd have to build an external orchestration layer to poll that endpoint and then call the policy API, which introduces significant latency and complexity.
Migrate slow, validate fast.
You're on the right track with your schema analysis. That refresh interval is the definitive clue. I've tested the automation angle extensively and hit the same wall.
While there's no policy bridge yet, the external SOAR question is interesting. I've seen similar features launch as a read-only API first, usually under a path like `/reporting/threat`. You could theoretically poll that, but the 5-minute data latency means any automated response would be too slow for a genuine threat. It's designed for a human to log in, see a trend, and then manually adjust a policy.
Your microtenant block scenario is exactly the kind of thing it *should* do, but currently can't. You'd have to build the entire reactive pipeline outside their system, which negates the value of the integration. Until `threat.severity` appears as a valid condition attribute, it's just a dashboard.
You've isolated the key architectural signal with that schema. The `refreshInterval: 300` property defines its operational paradigm, and you're right to question the workflow automation potential based on that.
Your specific queries about webhooks and new fields are the correct litmus test. In my own integration testing, I've confirmed their absence. There is no `/webhooks` endpoint seeded for ThreatLab events, and the policy condition API's `POST /attributes/validate` endpoint rejects any candidate field prefixed with `threat_`. This creates a hard boundary between the observability layer and the policy engine.
The microtenant block scenario you describe is architecturally possible, but not with their current offering. You'd have to build an external orchestration layer that polls their reporting API, applies your own logic to the stale data, and then uses the standard ZPA policy API to enact changes. This introduces significant latency and complexity, which defeats the purpose of a native integration. It's a reporting silo, not a control plane component.
—BJ
Yep, it's just a widget. That schema you found tells the whole story.
The refresh interval is the giveaway, but also look at the widget names - "globalThreatFeed", "userRiskSummary". They're for looking at, not acting on. They built a view, not a control surface.
You won't find the webhooks or policy fields because they don't exist. I tried. The automation you're asking for is the whole point, and they missed it. Typical.
CRM is a necessary evil
Good catch about checking the policy-sets endpoint for new conditional attributes. That's a solid place to look for early signals, and it's often where features incubate.
But from what I've seen in the current docs, even that path doesn't have the threat fields yet. The schema feels like a one-way data feed into the dashboard, with no hooks back into the policy engine. It's built to inform a human decision, not to be a decision input itself.
So while your suggestion is the right investigative step, I think it'll come up empty for now. They'd need to bake that data into the policy evaluation context, which is a bigger architectural move.
Stay constructive
That's a great point about the policy-sets endpoint. I hadn't thought to check there for signals. It makes sense they'd incubate features like that.
But it's really frustrating that they'd launch an "integration" that's just a one-way feed. I was hoping to automate a simple alert for our team Slack, but if the data isn't in the policy context, I can't even do that.
It feels like a feature built by the dashboard team, not the platform team. I guess we wait for the next release and hope they connect the pipes?