Continuous Delta Scanning

How delta detection works

For each inventory type, Rencore maintains a change cursor, a record of the last known state. On each scan cycle the scanner queries the source API for changes since the cursor, applies the changes to the local inventory, advances the cursor, and re-evaluates affected policies. The API call volume is proportional to change rate, not inventory size.

For sources that do not natively expose a change feed (some connectors), Rencore implements a polling-based delta with hash-based change detection. The trade-off is slightly higher API load, but the user-visible latency is the same.

Throttle awareness

Microsoft Graph in particular has complex rate limit behavior, per-tenant limits, per-app limits, burst limits, sustained-rate limits. The Rencore scanner tracks all of them and stays within bounds while maximizing throughput. The result is enterprise-scale scanning without triggering Microsoft-side throttling penalties or interfering with other tooling that shares the quota.

Why this matters operationally

Detection latency directly determines remediation timing. A governance platform that catches violations 18 hours after they occur cannot prevent damage; one that catches them in minutes can. For sensitive scenarios, Copilot oversharing, AI agent sprawl, license waste, the difference between hours and minutes is the difference between detection-only governance and closed-loop governance.