Security & Azure IAM Permissions
WasteRadar is built on a strict read-only security contract. We analyze cloud waste without the ability to modify, delete, or disrupt your production infrastructure.
1. The Zero-Mutation Guarantee
WasteRadar is physically and programmatically incapable of modifying or deleting your Azure resources. We enforce this through two immutable design principles:
Zero Write Operations
Our codebase contains zero ARM write, delete, patch, or restart API calls. WasteRadar performs only `GET` and `POST` query operations to discovery endpoints.
Least Privilege IAM Roles
We require only standard Azure `Reader` and `Cost Management Reader` roles. We reject Contributor, Owner, or custom write permissions.
Read-Only Telemetry Architecture
2. Required Azure IAM Permissions
To run automated waste detection scans, you create a dedicated Azure Service Principal assigned the following two built-in Azure roles:
`Reader` (Microsoft.Resources)
Purpose: Allows querying Azure Resource Graph to inspect resource metadata (disk attachment state, VM power state, public IP associations, snapshot parents, and resource tags).
`Cost Management Reader` (Microsoft.CostManagement & Consumption)
Purpose: Allows reading month-to-date billed spend, budget limits, and forecast telemetry. If this role is omitted, scans run in "Partial" mode using Azure public retail rate estimations.
Create with a Single Azure CLI Command:
az ad sp create-for-rbac \
--name "wasteradar-audit-sp" \
--role "Reader" \
--scopes "/subscriptions/{YOUR_SUBSCRIPTION_ID}"3. What WasteRadar Does NOT Access
- ✕No In-Guest Access: We never log in to your Virtual Machines, SSH keys, or OS environments.
- ✕No Storage Data Access: We inspect disk metadata (size, SKU, attachment state) but cannot read files on storage disks or blob containers.
- ✕No Database Content: We analyze database SKUs and provisioned compute tiers, not your SQL data or records.
- ✕No Network Traffic Interception: We do not route or inspect your live application or VPC traffic.
4. Encryption & Credential Protection
Encryption at Rest: Azure Client Secrets are encrypted using authenticated symmetric AES-256-GCM encryption with server-side master keys before persisting to database tables.
Zero Browser Exposure: Azure credentials, access tokens, and decrypted keys never leave our secure server-side runtime and are never sent to the browser.
Multi-Tenant Isolation: Data tables in Supabase PostgreSQL enforce strict Row Level Security (RLS) policies. Users can only query rows associated with their authenticated organization ID.
Encryption in Transit: All web traffic and Azure ARM API communications are strictly encrypted with TLS 1.3.
5. Authenticated AI Architecture & Data Protection
Enterprise Data Flow & Boundary Protection
Your Azure environment is never handed directly to the AI model. Whenever WasteRadar AI needs customer context, WasteRadar first verifies the user's identity, organization and permissions. Only the minimum authorized information required to answer the question is passed to the AI service.
Zero customer credentials, access tokens, database secrets, or PII are transmitted. Prompts and completions are never used to train foundation models.
Cost, waste, forecast, budget and verified-savings calculations remain deterministic and server-side. AI does not create or alter authoritative financial values.
6. Immutable Audit Logs & Team RBAC
Every administrative action (connecting a subscription, creating a budget, updating an alert, inviting a team member, exporting data) is permanently logged in your organization's audit trail with timestamp, user email, and action metadata.
7. Security Inquiries & Trust Center
If you have security questions or wish to review our subprocessors, encryption controls, or compliance posture, explore our Trust Center or reach out directly:
WasteRadar Security Response Team
Email: security@odinext.com