A governance platform that doesn't hold your keys
Stratoscope is built on a simple principle: a governance tool should never be the thing that needs governing. Least-privilege credentials, explicit human approval for every mutating operation, and a full audit trail from finding to outcome.
Read the full write-up: Governing Azure Without Owning It →
Security principles
Six commitments that govern how Stratoscope handles credentials, permissions, and your data.
Least privilege by default
Stratoscope registers a service principal in your Azure tenant with the minimum RBAC assignments needed: Reader at the subscription scope for discovery, and Contributor for specific remediation operations. No Owner. No standing elevated access.
Borrow, don't own
When a remediation requires permissions beyond what the service principal holds, Stratoscope requests a specific, scoped elevation — the exact permission, the exact resource scope, the exact operation. You approve it. It executes under your delegated identity. The elevated access expires immediately after.
Full audit trail
Every operation — discovery sweep, WAF assessment, remediation execution, and permission escalation — is logged with timestamp, identity, the exact command executed, and the outcome. The log is append-only and queryable from the console.
Tenant isolation
Each Azure tenant connected to Stratoscope is fully isolated. Credentials, discovery data, and audit logs for one tenant are never accessible from another. Isolation is enforced at every layer — API, database, and agent context.
No speculative execution
The governance engine never executes a mutating Azure operation without explicit human approval. HITL is not a configuration option — it is an architectural invariant. There is no mode that bypasses it.
Your data, your environment (BYOA)
Enterprise customers can deploy the Stratoscope agent inside their own Azure VNet. In BYOA mode, raw Azure governance data — inventory, cost signals, WAF findings — never leaves your environment. The intelligence runs in Stratoscope's managed cloud; your data stays in yours.
How permission escalation works
SP attempts the operation
The service principal tries the remediation step. If it succeeds, done — no escalation needed.
Permission gap detected
Azure returns AuthorizationFailed. Stratoscope parses the error: which action, which scope, which resource.
Escalation request surfaced
The platform presents the exact permission gap to you — not a generic "needs more access" message. You see the action, the scope, and why this specific operation requires it.
You approve and execute
You approve the escalation request. The operation runs under your delegated identity — your credentials, your authorization, Stratoscope orchestrates the command.
Logged, access expires
Full audit record: who approved, what ran, the outcome. Delegated access expires immediately. No standing elevation.
Security questions
What RBAC roles does Stratoscope need?
Reader at the subscription scope for discovery and assessment. Contributor is requested for specific resource types during remediation — never at subscription scope, always at the minimum scope required for the operation. Owner is never requested.
What happens when a remediation needs Owner-level permissions?
Stratoscope surfaces the specific permission gap — the action, the scope, and why it's needed — and requests a one-time delegation from you. You run the operation under your own identity, with Stratoscope orchestrating the command. Delegated access expires immediately after the operation completes.
Where is my Azure data stored?
Console SaaS stores discovery results and audit logs on Azure Container Apps + PostgreSQL in Azure Commercial. Enterprise customers using BYOA mode keep raw Azure data in their own environment. Embeddings and agent memory are stored in pgvector within the same PostgreSQL instance — not sent to third-party vector databases.
Does Stratoscope support Azure Government?
Not yet. Current support is Azure Commercial only. Azure Government is on the roadmap.
Is my credential stored in Stratoscope?
Service principal credentials (client ID, client secret or certificate) are stored in Azure Key Vault — never in application configuration or environment variables. Access to the vault is scoped to the running service only.
What AI providers does Stratoscope use?
Stratoscope uses Anthropic Claude models exclusively for all AI processing. No OpenAI, Google, or other AI providers. Anthropic's usage policy prohibits training on API inputs by default.
Questions about our security model?
Email us directly. We'll answer questions about our credential architecture, data handling, and compliance posture.
engineering@stratoscope.io