Skip to content
Sprinty
Built for Microsoft 365 admins and MSPs

Audit and clean up Exchange Online mailbox delegates fast – with proof, not fragile scripts.

Sprinty's Dynamic Throttling-Aware Orchestrator is designed to drive scans toward the highest sustainable throughput Microsoft service conditions allow – turning mailbox delegate audits and cleanup into one repeatable, evidence-backed workflow.

Watch 2-minute demo
Preview of the Sprinty product walkthrough2:13
Honest Live ETA
Appears after calibration and adapts to throttling.
Baseline diffs
See what changed since the last clean snapshot.
Preview-first cleanup
Filter the working set, target exact users, and remove risky delegates safely.
Evidence + run truth
Export recipient-verifiable proof while surfacing retry counts, throttle events, completeness, failed objects, stale objects, and resumability status.

Current beta: high-fidelity, explicitly simulated Pre-MVP.

THE PROBLEM

Scripts don’t fail because you’re bad at PowerShell.

They fail because the platform is dynamic: throttling ceilings move, tenants are noisy, and audits require evidence – not just output.

Throttling + retries
429s happen. A serious auditor must honor Retry‑After and adapt to live signals – every run.
No baselines = no answers
“What changed since last week?” is painful without a baseline + incremental diffs.
Audit evidence
CSV output alone isn’t enough. Security and compliance teams need defensible reporting.
Operational friction
Manual scripts break workflows: no scheduling, no alerts, no consistent UX for teams.
Serial-Exchange-Delegate-Audit.ps1
# Old way: serial mailbox-by-mailbox delegate audit
$mailboxes = Get-EXOMailbox -ResultSize Unlimited `
-RecipientTypeDetails UserMailbox,SharedMailbox,RoomMailbox,EquipmentMailbox `
-Properties PrimarySmtpAddress,RecipientTypeDetails,GrantSendOnBehalfTo
foreach ($mbx in $mailboxes) {
Get-EXOMailboxPermission -PrimarySmtpAddress $mbx.PrimarySmtpAddress `
-ResultSize Unlimited
Get-EXORecipientPermission -PrimarySmtpAddress $mbx.PrimarySmtpAddress `
-AccessRights SendAs `
-ResultSize Unlimited
$mbx.GrantSendOnBehalfTo
}
Scroll
HTTP 429
Exchange Online
Throttling limit exceeded
429 received
Retry-After honored
Retry budget drains
Operator confidence drops / rerun risk rises
Serial mailbox-by-mailbox scope only
delegate-audit.csv
Flat rows only • Mailbox + type + principal + permission
Why this matters:

Scripts fail silently or take days when they hit Microsoft's dynamic throttling limits.

THE SOLUTION

A throttling-aware audit workflow, not a fragile script loop.

Mailbox delegate wedge (simulated in beta)
Full Access bulk-first collection
Mailbox-targeted follow-up + supporting trustee resolution
Dynamic Throttling-Aware Orchestrator
Adaptive throttling
Baselines + diffs
Recipient-verifiable evidence
Audit Evidence Pack
Built from immutable scan context + signed verification artifacts
Separate Working Set / Remediation

Sprinty adapts to live throttling signals, preserves baseline context, and turns mailbox delegate reviews into a repeatable workflow with safe cleanup, evidence packs, and verification.

Adaptive throttling control
Honors Retry-After and bounded backoff based on live Microsoft service behavior.
Exchange-first delegate collection
For the active mailbox delegate wedge, Sprinty stays Exchange-first: tenant-validated Full Access bulk collection where that tenant proves complete, org-wide Send As collection, and mailbox-targeted follow-up only where fallback, retry, verification, or edge handling is needed.
Baseline + diffs
Captures current permission state and highlights what changed over time.
Recipient-verifiable Evidence Pack
Bundles a concise report, machine-readable evidence, manifest, and verification artifacts into one workflow recipients can validate.
Completeness + resumability
Reports retry counts, throttle events, completeness, skipped objects, failed objects, stale objects, and resumability honestly — and keeps incomplete targets in a separate review path before final sign-off.
Preview-first cleanup proof
The current Pre-MVP beta demonstrates the cleanup workflow inside Sprinty’s browser-retained working set. In real connected MVP 1, remediation requires additional Exchange Online RBAC beyond audit-only posture.
Why this matters:

A true orchestrator adapts to the tenant's load, ensuring the audit finishes reliably and produces verifiable evidence.

CLEANUP

Sprinty does not stop at finding risky delegates.

The active wedge is not just discovery. Sprinty helps admins move from mailbox delegate audit to safe cleanup with a filtered working set and exact assignment preview. In the current Pre-MVP beta, that cleanup proof runs inside Sprinty's retained simulation working set; in real connected MVP 1, remediation requires additional Exchange Online RBAC.

Filtered working set
Narrow the scope to the exact user, shared, room, and equipment mailboxes you want to review.
Exact assignment preview
See the exact delegate assignments Sprinty will change before any removal happens.
Targeted removals
Bulk cleanup can target all matching users or only the exact principals you specify inside the current Pre-MVP working-set demo flow.
MVP 1 remediation gate
The beta proves the operator workflow. In real connected MVP 1, cleanup remains a separately permissioned Exchange Online RBAC capability beyond audit-only posture.
Step 1
Discovery
Filter working set
User
Shared
SendAs
Step 2
Scope
Define remediation scope
alice@company.com
Impact Preview
12 assignments
Preview & remove
MVP 1 requires Exchange Online RBAC
Why this matters:

Sprinty replaces fragile delegate audit-and-cleanup scripts with a safer admin workflow.

HOW IT WORKS

The Sprinty audit workflow.

From first connection to recipient verification, the current Sprinty beta follows a clear flow aligned to Sprinty’s active wedge: connect once, establish a baseline, monitor diffs, run a preview-first delegate cleanup workflow, export a recipient-verifiable Evidence Pack, review incomplete targets before final sign-off, and hand recipients proof they can independently verify.

1

Connect tenant

Connect your tenant once. In the current beta demo, Sprinty shows a simulated Microsoft consent step before binding a demo tenant.

Work-email beta gate
Turnstile + OTP
Desktop-only admin posture
Enforced
Simulated consent
Signed tenant binding
2

Capture baseline

Capture a baseline snapshot of current mailbox-permission state.

Immutable baseline snapshot
3

Watch Sprinty calibrate into Live ETA

Sprinty calibrates first, shows an estimated phase early, then transitions into Live ETA once the throughput window is stable.

Calibrating
56s
Early estimate available now · Live ETA appears after the 60-second throughput window stabilizes.
Orchestration progress45%
Estimated ETA42m 15s
4

Run incremental diffs

Run incremental scans to surface gained/lost permissions and anomaly patterns.

1mailbox: ceo@contoso.com
2delegate: admin@contoso.com
-Lost FullAccess
+Gained SendAs
5

Preview and clean up delegates

Review the retained working set, target exact principals, and preview every removal before Sprinty changes anything.

Step 1
Discovery
Filter working set
User
Shared
SendAs
Step 2
Scope
Define remediation scope
alice@company.com
Impact Preview
12 assignments
Preview & remove
MVP 1 requires Exchange Online RBAC
6

Export Evidence Pack

Generate an Evidence Pack ZIP with a concise report, machine-readable evidence, manifest, and verification artifacts. Incomplete targets stay on a separate review path before sign-off.

Evidence_Pack.zip
CSV shards
Audit report PDF
Manifest
SignatureVerify
7

Recipient verifies

Recipients independently verify the Evidence Pack against Sprinty's published trust roots.

Verification Passed
Signature matches trust root
Manifest HashValid
Ed25519 SignatureValid
COMPARISON

Designed to be faster than serial Exchange audits – without fake promises.

Live ETA
Adapting to throttling conditions
42m 15s
Illustrative UI state
Post-calibration
CalibratingEstimated ETALive ETAFinalizing
Orchestration progress45%
Literal mailbox scope progress45,291 / 100,000
ETA logic
Observed completions + throttle state + drain overhead
60s windowLive-adaptiveNot a fixed benchmark
Before stabilityCalibrating / Estimated ETA
After stabilityLive ETA
As throttling changesETA rises or falls
Throttle state
Retry-After
Retry-After5s
Drain overhead1m 20s

In connected operation, Sprinty’s “Scan Time” is an honest live ETA derived from observed throughput under current throttling – it rises and falls with real conditions. The current beta illustrates this ETA behavior on simulated scan data.

Serial Exchange audit baseline
  • Mailbox enumeration plus delegate surfaces drained in serial
  • No retained baseline diffs or recipient-verifiable export flow
  • Manual reruns, weaker retry orchestration, and guesswork ETAs
Sprinty
  • Live ETA that adapts to throttling
  • Baselines + incremental diffs
  • Preview-first delegate cleanup + audit‑ready exports
Note: We don’t promise fixed scan times (e.g. “100k in 90 minutes”). ETA is computed from real throughput.
Benchmark posture

Sprinty is designed to materially outperform serial Exchange delegate audits by keeping tenant-validated Full Access bulk collection on the hot path where a tenant proves complete, keeping mailbox-targeted follow-up limited to the targets that still need it, and supporting the whole run with retained baselines, diffs, and evidence workflows.

Live ETA always adapts to actual throttling conditions. Public benchmark categories and numeric claims are published only after real tenant testing.

The current browser demo is intentionally capped to full scans from 100 to 100,000 mailboxes so the workflow stays repeatable and trust-safe. Larger Exchange Online estates move to the connected MVP 1 platform and are benchmarked separately by tenant and workload.

Why this matters:

Admins see a real, throttling-aware ETA instead of guessing whether the job is stuck.

UNDER THE HOOD

Transparent by design – from live ETA to evidence verification.

Sysadmins don’t adopt black boxes. Sprinty is designed to be explainable: clear orchestration behavior, honest timing, supported Microsoft surfaces, and evidence packs that are meant to be shared and verified.

Independent verification remains available at Sprinty’s public verifier and published trust roots for buyers and recipients who need to validate signature authenticity, manifest integrity, and key metadata without turning proof into a competing landing CTA.

Throttling compliance is correctness
Honor Retry‑After on 429s, fall back to bounded backoff when it is absent, and don’t hard-code requests-per-minute assumptions. When Sprinty uses supporting Microsoft Graph batching, each batch is strictly capped at 20 requests.
Scan Time = live ETA
ETA is computed from observed throughput under current conditions – it changes as throttling changes.
Evidence Pack + verification
Evidence Pack exports combine a concise human-readable report, machine-readable evidence, manifest, and verification artifacts into one review workflow.
Completeness + follow-up truth
Sprinty surfaces retry counts, throttle events, completeness, skipped objects, failed objects, stale objects, and resumability status for the active mailbox delegate wedge. Incomplete targets stay in a separate review queue instead of being quietly treated as final sign-off material.
Sprinty is built on supported Microsoft surfaces. For the active mailbox delegate wedge, authoritative collection stays Exchange-first: Sprinty prefers tenant-validated Full Access bulk collection where that tenant proves complete, keeps org-wide Send As collection on the hot path, and uses mailbox-targeted follow-up plus Microsoft Graph only where extra verification, trustee resolution, retries, or edge handling are needed. Sprinty has zero EWS dependency.
Dynamic Throttling-Aware Orchestrator log
Simulation
14:02:11Warm path calibrated. Sprinty is opening a validated Full Access bulk lane first, then keeping mailbox-targeted follow-up reserved for fallback, retry, verification, and edge handling.
14:02:13Mailbox inventory is pinned to user, shared, room, and equipment mailboxes before Full Access validation and delegate expansion continue.
14:02:15Exchange delegate collection surfaced HTTP 429 with Retry-After; Sprinty is freezing only the affected retry wave and will replay delayed collector work after the longest applicable wait.
14:02:18Queue leveling reduced live throughput to bounded Exchange sessions while the delegate retry backlog drains.
14:02:22Where Retry-After is absent, Sprinty falls back to bounded exponential backoff for affected delegate collector work instead of guessing fixed limits.
14:02:29Stable drain confirmed. Tenant-validated Full Access bulk collection, org-wide Send As collection, and Send on Behalf reconciliation are reopening toward the tenant’s sustainable ceiling.
14:02:37Trustee and directory context resolution is enriching unresolved identities without replacing Exchange as the authoritative permission source, and mailbox-targeted Full Access checks remain a follow-up lane only where the tenant needs them.
14:02:44Checkpoint persisted. Retry counts, failed objects, stale objects, and completeness state remain attached to this scan path for resumable follow-up.
14:02:51Delegate collectors drained. Finalizing evidence rows, manifests, trustee context, and working-set persistence.
14:03:02Evidence Pack ready for export progress monitoring and recipient verification hand-off.
Scroll
Validated Full Access bulk lane
Directory / trustee resolution
Why this matters:

Sysadmins don't adopt black boxes. Sprinty is transparent about its orchestration behavior and uses supported Microsoft surfaces.

TRUTH BOUNDARIES

What Sprinty is built to prove.

Sprinty's current beta is designed to be explicit about what is proven, what is simulated, and where the evidence boundary stops. Today the beta demonstrates this workflow on simulated scan data; connected MVP 1 turns it into real tenant operation. That keeps the landing page aligned to Sprinty's real product truth instead of implying broader Microsoft 365 coverage than the active wedge actually delivers. It also means Sprinty keeps executive evidence concise and sends incomplete targets into review before final sign-off.

Current-state permission inventory
The current beta simulates who has mailbox delegate access at scan time across Full Access, Send As, and Send on Behalf for user, shared, room, and equipment mailboxes; connected MVP 1 produces this as real tenant inventory.
Scan Time
Full Access
Send As
Send on Behalf
Historical change evidence
Historical proof comes from Sprinty-owned snapshots and diffs, supplemented by Microsoft audit records only where available. Sprinty does not assume one Microsoft feed can reconstruct every prior permission state.
Baseline
Diff
Snapshot
Not mailbox activity evidence
The current beta does not claim to prove who opened a mailbox, what a delegate did inside it, or complete mailbox/delegate activity history. That is a separate evidence lane.
Mailbox Activity
Delegate Access
Direct delegate wedge only
The active beta simulates direct mailbox delegate inventory plus preview-first cleanup workflow. It does not claim complete group-recursive effective access, folder permissions, public folders, app-only mailbox access, or audit-history coverage.
Folder PermsPublic Folders
App AccessAudit History
Wedge
SECURITY

Security posture in the current Sprinty beta.

Sprinty beta uses work-email allowlist gating, email OTP sign-in, Turnstile abuse prevention, protected export routes, Stytch-backed session cookies, nonce-based CSP, hardening headers, and a desktop-only admin posture. The current Pre-MVP demonstrates cleanup inside a browser-retained working set; in real connected MVP 1, remediation requires additional Exchange Online RBAC beyond audit-only posture.

No mailbox content read for audit-only posture
Sprinty’s current mailbox delegate audit wedge is positioned around permission inventory and evidence workflow, not mailbox message-content access.
No tenant-wide send capability for audit-only posture
The current audit workflow is not positioned around sending as users or relaying mail on their behalf.
Cleanup stays separately permissioned
The beta proves the preview-first cleanup workflow, but real connected MVP 1 remediation remains a separate Exchange Online RBAC capability beyond audit-only access.
Admin access is deliberately gated
Work-email allowlist checks, OTP sign-in, Turnstile verification, protected exports, and session-cookie auth are there to keep Sprinty aligned to an admin tool posture.
Audit-only by default
Designed to support audit-only access by default, with remediation kept as an optional, separately permissioned capability.
Audit-Only
Remediation(MVP 1 remediation requires extra RBAC)
Why this matters: Admin teams can review delegate exposure without widening the posture to full cleanup permissions first.
Evidence Pack verification
Exports and verification artifacts are first-class outputs for security, compliance, and recipient trust checks.
Evidence_Pack.zip
Manifest
CSV
Report
Signed + verifiable
Why this matters: Recipients can independently validate what Sprinty produced.
Protected admin posture
Work-email beta access, Turnstile checks, OTP sign-in, session-cookie auth, protected export routes, nonce-based CSP, hardened headers, and desktop-only usage reinforce the admin workflow.
Access Flow
Work email
Turnstile
Email OTP
Desktop-only
Authenticated admin session
Why this matters: Sprinty is framed like an admin surface with deliberate gates, not a casual self-serve utility.
ROADMAP

A focused roadmap built around Sprinty's real wedge.

Sprinty is not trying to launch as a generic Microsoft 365 governance suite. The roadmap stays disciplined: prove the mailbox delegate audit-and-cleanup wedge first, connect that same scope for MVP 1, then expand into adjacent Exchange access-graph modes only after the core engine is operationally strong.

Current stage
Now
01

Current beta (Pre-MVP)

High-fidelity validation of Sprinty’s mailbox delegate workflow across user, shared, room, and equipment mailbox types.

  • Simulated only where explicitly labeled
  • Browser demo full-scan range intentionally capped at 100 to 100,000 mailboxes
  • Connected MVP 1 takes larger Exchange Online estates beyond the browser-demo cap
  • Live ETA, baselines, diffs, Evidence Pack, and verification UX aligned to real product posture
  • Preview-first cleanup workflow proven in the retained working set
Next
02

MVP 1 (real connected implementation)

Pre-MVP and MVP 1 keep the same wedge. MVP 1 turns this exact scope into the real connected product.

  • Mailbox Delegate Audit for Full Access, Send As, and Send on Behalf
  • Exchange-first collection: tenant-validated Full Access bulk lane where complete, plus mailbox-targeted follow-up only where needed
  • Connected targeted follow-up collection for incomplete or stale mailbox-delegate targets
  • Bulk cleanup remains part of the wedge, with remediation gated behind the right Exchange Online RBAC posture
Then
03

MVP 2 (access-graph expansion)

After wedge success in production, Sprinty expands into adjacent Exchange access-graph workflows without platform sprawl.

  • Recipient and group delegation expansion
  • Deeper folder and public-folder coverage as separate scan modes
  • Broader evidence, compliance, and adjacent Exchange access reporting
Later
04

Post-MVP scale-up

Enterprise packaging follows after the core engine is proven repeatable in production.

  • MSP multi-tenant and white-label direction
  • Advanced rule-based anomaly and policy layers
  • Additional benchmark-gated validation tracks only when Microsoft coverage and market demand justify them
Active right now

Sprinty is onboarding teams into the current Pre‑MVP wedge: mailbox delegate audit + preview-first cleanup proof.

Browser demo full-scan range: 100 to 100,000 mailboxes. Larger Exchange Online estates move into connected MVP 1, where Sprinty scales through the server-side orchestrator instead of the browser-demo cap.

Watch 2-minute demo
FAQ

Answers for skeptical admins, security reviewers, and Exchange teams.

FOUNDER

Built from a real operational problem.

“Sprinty started with a real operational problem: scanning around 10,000 Exchange Online mailboxes with PowerShell was slow, difficult to monitor, and repeatedly ran into throttling.

That experience became the foundation for Sprinty’s Dynamic Throttling-Aware Orchestrator and the wider workflow – designed to adapt to Microsoft service limits, make progress and constraints visible, and turn mailbox delegate auditing into a clearer, more resilient and verifiable process.”

Omeir AliTechnical Founder, SWEView Omeir on LinkedIn ↗
BETA ACCESS

Request beta access.

Work-email beta access. Clearly qualified teams can get access immediately; exceptions are reviewed in waves.

Current browser demo supports full-scan runs from 100 to 100,000 mailboxes. Larger Exchange Online estates move to Sprinty's connected MVP 1 platform, where scale is handled by Sprinty's server-side orchestrator and benchmarked separately by tenant and workload.

Sprinty Shield
Complete verification before requesting Sprinty beta access.
Not verified
Powered by Cloudflare TurnstileComplete verification
Use your work email. Clearly qualified teams may get access immediately, and exceptions are reviewed in waves.

Built for Microsoft 365 admins, Exchange Online admins, MSP operators, and security/compliance teams managing Exchange Online mailbox estates.