← All updates

Alerts for blocked access attempts, plus security and reliability hardening

See and get alerted when access is blocked from an unexpected location

If you use IP allowlisting on your machines or AI agents, a request that carries a valid signature but arrives from an address outside your allowlist is now recorded in your audit log and triggers your configured alerts. The same applies when a machine enrollment is turned away by your allowlist. You get an immediate signal when a credential is used from somewhere you did not expect, rather than the block passing quietly in the background.

Allowlist rules now also match consistently whether a client connects over IPv4 or IPv6, including IPv4 addresses presented in IPv6 form, so a rule applies the same way regardless of how an address is written.

Two-factor codes are now single-use

A one-time code from your authenticator app can now be used only once. If a code you have already used is submitted again while it is still inside its short validity window, it is rejected. This applies everywhere a code is checked, from signing in to confirming a sensitive action.

Canary tripwires and read limits now cover bulk export

When an app or SDK pulls all of its secrets in one request, your protections now behave the same as they do for a single fetch: a canary secret triggers its project lockdown, and your read-count limits, which can destroy or rotate a secret after a set number of reads, are applied on that path too. These protections previously ran on single secret fetches only.

More resilient managed-secret rotation

For secrets rotated by a sync agent, a delayed or duplicate failure report no longer cancels a newer rotation that has already been prepared, so a managed credential will not get stuck un-rotated because of a late retry.

Stricter webhook delivery