feat: threat intelligence async guards with external API integration#25
feat: threat intelligence async guards with external API integration#25
Conversation
Implement asynchronous guard infrastructure for threat intel: - Async guard runtime with background processing support - Threat intel guards for VirusTotal, Snyk, and Safe Browsing APIs - Policy schema extensions for async guards configuration - TypeScript policy validator updates for new guard types - CI workflow updates for threat intel testing - Documentation and example policies Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 6d6d264e53
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| for (_idx, g) in sequential { | ||
| let result = self.evaluate_one(g, action, context).await; | ||
| out.push(result); | ||
| if out.last().is_some_and(|r| !r.allowed) { | ||
| return out; |
There was a problem hiding this comment.
Honor fail_fast=false when evaluating async guards
The runtime ignores the fail_fast flag and always short-circuits on the first deny (e.g., the sequential loop returns immediately), which means policies with fail_fast: false will still skip later async guards. Since the engine passes effective_fail_fast() into this method, this behavior makes async guard evaluation inconsistent with the policy setting and can suppress additional denies/warnings or side effects from later guards in the list.
Useful? React with 👍 / 👎.
| Err(_) => fallback( | ||
| &name, | ||
| &cfg, | ||
| AsyncGuardErrorKind::Timeout, | ||
| "timeout", |
There was a problem hiding this comment.
Count async guard timeouts as circuit-breaker failures
Timeouts bypass record_failure(): the Err(_) => fallback(...) branch does not update the circuit breaker, so repeated timeouts will never open the circuit. This defeats the breaker’s purpose for slow/blocked endpoints and can keep the system waiting on every request instead of backing off.
Useful? React with 👍 / 👎.
Summary
Test plan
🤖 Generated with Claude Code