When you connect a client to Spotto, you're putting your name on it. So we built Spotto to earn that, least access, your region, a full audit trail, and nothing changed unless you say so.
This article is the public overview of how Spotto handles access and data. Security and procurement teams can request our full Access & Data Handling document and current controls at any time.
The one that matters most: Spotto is read-only by default. The version that watches over a client estate has no power to change anything in it, and a tool that demands write access on day one can't say that.
Spotto security at a glance
Five things to know before you connect a client.
| Read-only by default | Spotto only needs Reader access to do its job. No write access exists unless you explicitly grant it. |
| You set the boundary | You choose the subscriptions and scope. Limit it to non-production if you want. Revoke any time, three different ways. |
| Your data stays in your region | AU, EU and US deployments are isolated, separate storage, separate keys, separate backups. Your data doesn't cross the line. |
| We read metadata, not your business | Resource configuration, billing and metrics, never workload content or secrets. Azure stays your source of truth. |
| Nothing changes without approval | Every change is scoped, validated, logged before-and-after, and reversible. You approve it, or it doesn't happen. |
Read-only access to your clients' Azure by default
Most platforms ask for more access than they need. Spotto asks for less.
By default Spotto connects with Reader access at the subscription level, enough to surface findings across the five pillars (security, performance, reliability, cost, and operational excellence), and nothing more. It connects through an Azure service principal that you create and control. There is no standing write access, not a narrow slice, not "just in case." None.
That means the version of Spotto reading, analyzing and recommending across a client estate cannot change anything in it. Full stop.
If, and only if, you want Spotto to act on a finding, you grant a custom role built to least privilege, scoped to exactly the subscriptions, resource groups or resources where action is allowed. Every action maps to a specific, documented Azure permission. You build the role from a published permission set, and you decide where it applies.
You decide the scope. You can revoke any time.
You control how much of an estate Spotto sees, and for how long.
Scope it to what you're comfortable with. Connect a whole environment, or limit Spotto to non-production or development subscriptions while you build confidence. Following Microsoft's Well-Architected guidance on subscription separation also keeps Spotto's recommendations accurate.
Revoke in seconds, whenever you want. Three independent paths, all yours:
- Remove the service principal or its secret in the Azure portal, or
- Rotate or revoke the Spotto API keys used by the portal, extension or MCP, or
- Delete the cloud account in the Spotto portal, which removes the connected resource data.
No call to support. No waiting. Access ends when you end it.
Your data stays in your region
Spotto runs isolated regional deployments, Australia, Europe and the United States. Each region has its own dedicated storage and logging, its own unique encryption keys, and its own isolated backups. Your operational data is processed and held in the region you connect to. It doesn't quietly hop to another.
And within a region, no client's data touches another's. Every Spotto API request is authenticated, then checked against the specific company it belongs to before any data is returned. Each company sits in its own partition with role-based access control. The architecture is designed so that cross-customer access cannot occur, and every request is logged for a complete audit trail.
We read metadata, not your clients' business
Spotto talks to Azure exclusively through Azure REST APIs, and reads only the operational metadata it needs to find work worth doing:
- resource configuration, tags, SKUs and settings (for example, TLS configuration)
- billing and consumption data for cost and trend analysis
- performance and utilization metrics for right-sizing
- Azure Advisor context, benefit, risk and trade-off
It does not collect your clients' workload content or secrets for its core workflows. Azure remains the source of truth: Spotto doesn't back up resource data for restore, because it can simply re-read it. When you disconnect a cloud account, the associated resource data is removed. Operational and security logs are kept for up to 180 days, then deleted or anonymised.
One honest note: PII can appear in metadata you control, resource names, tags, activity records. You decide what goes there; we treat it as yours.
The browser extension never touches Azure credentials
Spotto's Azure browser extension puts recommendations right inside the Azure portal, as a read-only overlay, with a hard wall between it and your Azure session.
The extension uses its own independent login (separate authentication, with MFA enforced). It has zero access to your Azure credentials, tokens or cookies, makes no calls to Azure APIs, and can't perform any Azure operation. It reads only what's already visible on the portal page, resource type, subscription ID, to fetch the matching Spotto insight. Its code is reviewed before every release.
In short: it can show you what Spotto thinks. It cannot reach into Azure on your behalf.
AI features are opt-in, and kept on a short leash
Spotto's AI features (like AI Chat) are opt-in. Where you enable them, they run on Azure Foundry / Azure OpenAI endpoints inside the deployment boundary, and per Microsoft's policy, your prompts and outputs are not shared with other customers, not shared with OpenAI, and not used to train foundation models.
On top of Microsoft's platform safeguards, Spotto enforces its own at the application layer:
- Server-owned scope, the AI can only ever see what your access actually permits; if scope can't be resolved, the request fails closed.
- Deny-by-default tools, every tool call is permission-checked; read-only analysis can run, but any change is approval-gated and bound to the exact action you approved.
- Guardrails, layered checks against prompt injection, scope expansion and disclosure of internal state, informed by OWASP guidance for LLM applications.
The model assists. It never holds the keys.
Enterprise-grade controls, end to end
The controls below are the ones your client's security team will ask about on the checklist. They're table-stakes, and they're all in place.
| Area | What's in place |
|---|---|
| Encryption | Encrypted in transit and at rest, with regional key and backup controls. |
| Access governance | MFA enforced for users and staff; least-privilege access with periodic review; Microsoft Entra PIM and managed identity paths. |
| Operational security | Microsoft Defender for Cloud, Azure Policy, and centralized API-layer access control. |
| Edge protection | Cloudflare WAF, DDoS protection, bot detection and rate limiting. |
| Secure development | Ticketed change tracking, peer-reviewed pull requests, automated testing, vulnerability and dependency scanning in CI/CD. |
| Vendor governance | New third-party providers pass a security and privacy assessment before adoption. |
| Incident response | A formal plan covering triage, containment, recovery and post-incident review, with customer notification per law and contract. |
Privacy & compliance
Spotto's design aligns with the New Zealand Privacy Act, the Australian Privacy Act, and GDPR principles. Your clients' data remains owned by your clients; Spotto acts as a processor in support of the service.
Certifications, underway. Spotto is actively working towards SOC 2 and ISO 27001. We don't claim what we haven't earned yet, so we'll be transparent about where we are on the journey, and you can see our current controls and progress live on our trust portal at trust.spotto.ai. Both are on our near-term roadmap, and we'll publish them the moment they're formally certified.
The detail: Spotto's trust portal and security documentation
Security and procurement teams can request our full Access & Data Handling document and current controls, the architecture, the data flows, and the answers to your review questions.