Security / Events
Security events
The Events feed is a single, aggregated stream of every security signal across your workspace — rejected attestations, rate limits, brute-force attempts, CORS blocks, key anomalies and successful verifications, from all your apps at once. It unifies three underlying data sources into one time-ordered list you can filter. This is a workspace-level feed for reading what happened — it is not the same thing as the per-app Security tab, which is where you configure App Identity and attestation (see App Identity).
Where to find it
Open your workspace Settings → Security → Events tab. The feed lists the most recent signals across every app in the workspace, newest first, and gives you three filters:
| Filter | Options | What it does |
|---|---|---|
| Time range | 24h / 7d / 30d | How far back the feed looks. Defaults to 7 days. Events are kept per your plan’s retention window (Free 7 / Pro 30 / Business 90 days), so longer ranges show at most what your plan retains. |
| Category | Auth rejection, Rate limited, Brute force, CORS rejected, Bypass attempt, Verified, Key anomaly, Monitored | Narrows the feed to one category (see the table below). Leave it unset to see everything. |
| App | Any app in the workspace | Scopes the feed to a single app. Unset shows all apps combined. |
Each row shows the app, the category, the underlying reason, and — where available — the platform or origin, an anonymized IP (last octet zeroed) and a user-agent. The feed is capped at the 100 most recent matching signals.
The three sources it unifies
The feed merges three tables into one stream so you don't have to check them separately:
| Source | What it carries |
|---|---|
sdk_security_events | SDK-wire events — the signals raised at the SDK/API boundary: attestation and integrity results, OAuth flow failures, rate limits, CORS blocks, brute-force sign-ins. |
security_events | Per-user and widget-level events. Branding-bypass and unknown-origin signals surface under Bypass attempt; OAuth sign-ins under Verified; informational events like a new-device sign-in under Other. |
sdk_key_anomalies | Key / traffic anomalies — leaked- or abused-key detections from the 15-minute traffic cron. Surfaced read-only here under Key anomaly. |
Categories
Every signal is bucketed into one category by its reason. Attestation failures written as attest_verify_failed:<code> (e.g. attest_verify_failed:chain_invalid) are matched by their base, so the whole family lands under Auth rejection. Anything unmatched falls into an Other bucket.
| Category | What it means | Example reasons |
|---|---|---|
| Auth rejection | A request was rejected because device attestation, app integrity, bundle/codesign identity or a refresh token failed to verify. | attest_invalid, attest_expired, attest_verify_failed:*, integrity_invalid, integrity_expired, bundle_id_mismatch, codesign_mismatch, refresh_token_reuse_detected |
| Rate limited | A caller exceeded the allowed request rate and was throttled. | rate_limit_exceeded |
| Brute force | Repeated failed sign-ins, a detected brute-force pattern, or an account lockout triggered by it. | failed_login, brute_force_lockout |
| CORS rejected | A browser request came from an origin that is not on the app’s allowed-origins list. | cors_origin_rejected |
| Bypass attempt | A request tried to reach a protected surface around the hosted widget — e.g. posting to a form or waitlist directly, bypassing the Onelo-branded UI. | branding_bypass_attempt |
| Verified | A successful verification — attestation, integrity or bundle checks that passed, and auto-registrations of a new device/app via App Attest, codesign or Play Integrity. | attest_verified, integrity_verified, bundle_verified, oauth_signin, auto_register_app_attest, auto_register_codesign, auto_register_play_integrity |
| Key anomaly | A leaked- or abused-key detection from traffic analysis (many IPs, many user agents, high sign-in failure ratio, sustained volume). Shown read-only here. | See Anomalies → |
| Monitored | A request from a platform whose attestation is still being finished (React Native, Flutter). Nothing was blocked — the request went through and is recorded here so you can see the traffic ahead of time. | auth_completer_unattested, integrity_unenforced_monitor |
Workspace feed vs per-app config
It's easy to confuse two surfaces that both say “Security”. They do different jobs:
| Security → Events (this page) | Per-app Security tab | |
|---|---|---|
| Level | Workspace — all apps at once | A single app |
| Purpose | Read an aggregated feed of what happened | Configure App Identity / attestation for that app |
| You do here | Filter, inspect, spot patterns | Turn on attestation, manage authorized devices/bundles |
| Direction | Observability (past signals) | Configuration (future enforcement) |
Think of the Events feed as the place you watch, and the per-app Security tab as the place you set the rules the feed then reports on.