Dev-time audit meets runtime enforcement.
Microsoft Dev Proxy and GraphWarden both act on Microsoft Graph API traffic. They operate at different stages of the lifecycle and solve different problems. This page explains when to use each, and why most organizations benefit from both.
Microsoft Dev Proxy is an open-source CLI tool published by Microsoft. In a Graph context, its GraphMinimalPermissionsGuidancePlugin intercepts requests issued from a developer's machine, compares the scopes present in the token to the scopes actually required, and reports unnecessary permissions at the end of a recording session.
It is a well-designed tool, actively maintained, and genuinely useful. Teams building Graph-based applications — whether .NET, Node.js, or PowerShell SDK — should use it as part of their development workflow. It closes a real gap: before Dev Proxy, mapping Graph endpoints to their minimal permission set was a manual, error-prone exercise.
If you are not using Dev Proxy during development, you probably should. It is free, open-source, and takes only a few minutes to set up.
Dev Proxy is, by Microsoft's own documentation, a development tool. It is not designed as a production runtime, and it does not claim to be one. That leaves four problems unaddressed once your code ships.
Your developer cleaned the manifest using Dev Proxy. Six months later, the admin deploying the app grants User.Read.All instead of User.Read "to be safe". Dev Proxy is no longer in the loop. The token going to Graph in production has scopes that never went through audit.
Dev Proxy runs on the machine where code is being developed. It has no reach over Power Automate flows, SaaS connectors authenticating in your tenant, vendor applications, or PowerShell scripts running on admin workstations. You cannot record what you do not own.
Dev Proxy tells you whether User.ReadWrite.All can be downgraded to User.Read.All. It does not tell you — and cannot enforce — that an app allowed to read users should not receive their personal phone numbers, home addresses, or birthdays. Property-level minimization is out of scope by design.
A Dev Proxy report lives in a terminal on a developer's laptop. It is not timestamped, signed, centralized per tenant, or structured for export to a SIEM. For regulated environments (Law 25, GDPR, HIPAA), it is not evidence.
The two tools sit on the same axis — controlling Graph traffic — but at opposite ends of the software lifecycle.
Microsoft Dev Proxy
shift-left
dev machine
clean app manifest
production deployment
GraphWarden
shift-right
runtime, multi-tenant
Dev Proxy (shift-left, dev machine) → clean app manifest → production deployment → GraphWarden (shift-right, runtime, multi-tenant)
Dev Proxy ensures your application asks for the right permissions. GraphWarden ensures that what actually flows through the Graph API — from any application, yours or someone else's — matches your organization's policy.
Developers use Dev Proxy to trim scopes before each release. GraphWarden runs in production to enforce per-property filtering and log every call for audit.
The organization does not have source access to the vendor's code. Dev Proxy cannot help. GraphWarden intercepts calls from the vendor app transparently and applies policy without modifying the application.
The compliance officer needs evidence that personal data is minimized and that access is logged per user, per app, per call. A Dev Proxy session report on a developer's laptop does not qualify. A GraphWarden audit trail does.
Dev Proxy is not multi-tenant and runs per developer. GraphWarden is natively multi-tenant and scales across customer tenants with a single policy framework.
A side-by-side look at what each tool does — and where its scope ends.
| Capability | Microsoft Dev Proxy | GraphWarden |
|---|---|---|
| Pricing model | Free, open-source | Commercial, per Microsoft tenant |
| Published by | Microsoft | GraphWarden |
| Deployment target | Developer CLI (local machine) | Windows Service or Azure Container App |
| Stage in lifecycle | Development | Production runtime |
| Operating mode | Session-based recording | 24/7 inline enforcement |
| Multi-tenant | No | Yes |
| Enforcement | No (advisory only) | Yes (allow / filter / block / log) |
| Scope-level permission analysis | Yes (primary use case) | No (not the goal) |
| Per-property filtering | No | Yes |
| Per-object scoping (AAD group, attribute, AU) | No | Yes |
| Response data transforms | No | 9 types (mask, hash, redact, domain-only, initials, truncate, noise, regex, mask-start) |
| Covers third-party / vendor apps | No (requires code access) | Yes (any Graph caller) |
| Audit trail | Local CLI output | Structured, centralized, per-call |
| Compliance reporting (Law 25 / GDPR) | No | Yes |
| Error simulation / chaos testing | Yes | No |
| Zero-knowledge credentials | N/A | Yes |
| Data residency | N/A | Azure Canada Central (Hosted) or your infrastructure (on-premise) |
Even after a clean Dev Proxy pass, GraphWarden adds four distinct capabilities that have no equivalent in the shift-left toolbox:
Policy applied on every call, not a report at the end of a session.
Allow the call, filter the sensitive fields — without changing the application.
Vendor SaaS, Power Automate, legacy scripts — all flow through the same policy.
Per-tenant, per-app, per-call, timestamped, exportable to your SIEM.
Dev Proxy cleans up your app before it ships. GraphWarden takes over the moment it goes live. Request a demo and see how the two tools work together on your own tenant data.
Beta · Now Accepting Partners