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.