Capabilities

What the self-hosted build does and does not do: each capability's status, every module that runs with the IAM actions it makes, what is never read, and the versions it is tested on.

The capability matrix for the invitation-only self-hosted build: what ships, what is still in development, what is planned, and what is deliberately never done. The statuses use the public site's three words:

• available now — implemented and test-backed in the build. That is not a claim that a pilot has validated it.
• in development — implemented or partly implemented, with live verification or a production dependency still open.
• planned — a direction with no delivery date. It is not in the build.

Two tests in observability/internal/cli hold this page to the code. TestTheCapabilityMatrixNamesWhatRuns checks that every module the scheduler runs has a row here, that no row names a module it does not run, and that every IAM action a collector makes is listed beside it. TestTheCapabilityMatrixMatchesTheRolesGrants checks each role's section against its CloudFormation template, in both directions: every action the template grants is listed there, and nothing listed there is ungranted.

Scope

• Cloud: AWS, and Google Cloud projects in Estate (Compute Engine instances, GKE clusters, Cloud SQL instances, Cloud Storage buckets, VPC networks and subnets, load balancers, Cloud Run services, Pub/Sub topics and subscriptions, BigQuery datasets, service accounts, Firebase apps and Cloud Functions, read through workload identity federation), and Google Cloud billing in Spend: a billing account's BigQuery export, read daily. Azure subscriptions in Estate: the platform signs in and collects virtual machines, AKS clusters, SQL databases, PostgreSQL flexible servers, storage accounts, virtual networks and App Service apps, and Admin → Accounts connects a subscription; every collector and the reader role's exact reads were verified against a live test subscription. Azure spend in Spend: a subscription's Cost Management export, read daily. Azure provisioning through the library's templates, each run live on a test subscription. Import's generated template for an Azure resource and Azure templates of your own and Blueprints with Azure slots are in development.
• Deployment: self-hosted, with Docker Compose or the Kubernetes kustomizations in deploy/. A hosted service is planned, after the first self-hosted pilot.
• Licence: offline, verified by the binary alone. The tiers are Essentials (Estate), Professional (Estate and Spend) and Enterprise (Estate, Spend and Provisioning, and the enterprise capabilities). Performance comes with Professional and Enterprise.
• Validation on a live account: one AWS account, the platform's own, was onboarded, collected, alerted on and billed end to end. That covers the external id's negative check, a status change delivered to a webhook, and a delivered Cost & Usage Report reconciled against Cost Explorer. A test estate was brought up and torn down through the product's own Provisioning templates, the agent applying them against that account as the reader role. Validation across separate customer accounts is in development.

Capabilities

The reader role

deploy/cloudformation/reader-role.yaml, deployed in every connected account. It grants exactly the actions in the three lists below, and no wildcard. None of them returns S3 object contents, log events, CloudFront configurations or Lambda source, each of which can hold a customer's data or credentials. One returns the metadata of API calls: cloudtrail:LookupEvents, CloudTrail's event history — who called what, on which resource, and when — read for the one resource that changed, between its two observations, and only for an account whose administrator turned CloudTrail attribution on (the owner, 2026-10-07). Of an event the platform keeps its id, name, time and principal, never its request, its response or its source address, and it reads no Lake query, trail bucket or data event. The template lists the reasons, and its test holds the allowlist. Its trust policy lets the platform assume it with the account's external id (sts:AssumeRole), set its source identity (sts:SetSourceIdentity) and tag its session (sts:TagSession).

Called by the inventory collectors

Most run per account and region. S3's and CloudFront's resources have a global identity, so those two run once per account. CloudFront's distributions and Lambda's functions are found from the metrics each publishes, not from their configuration, which carries the origins' custom headers and the functions' environment variables.

Called by the other jobs and by onboarding

Granted ahead of a collector

These were granted when the template was written, for the EC2 collectors still to come: instance types, security group rules, network interfaces, route tables, gateways, endpoints, regions and zones. Each was reviewed as metadata-only. Nothing calls them yet. A collector that starts calling one moves it into its own list, as the NAT gateway collector did and the volume, VPC, subnet, security group and Elastic IP collectors did and the VPC peering collector did, and one that nobody ever calls is removed from the template.

ec2:DescribeInstanceTypes, ec2:DescribeSecurityGroupRules, ec2:DescribeNetworkInterfaces, ec2:DescribeRouteTables, ec2:DescribeInternetGateways, ec2:DescribeVpcEndpoints, ec2:DescribeTags, ec2:DescribeRegions, ec2:DescribeAvailabilityZones

The Google Cloud reader

deploy/gcp/reader-role.yaml, a custom role in each connected Google Cloud project, bound to the project's reader service account. The platform signs in by workload identity federation from its own AWS identity and impersonates that account; no key file exists. The role grants exactly the permissions below. No predefined viewer role would do: each reads content somewhere, Datastore entities, a routine's body, a function's environment, a service account's keys, or the project's shared instance metadata. Cloud Functions are read from the Functions API's listing, masked, never its get. Verification also reads the reader account and the project (iam.serviceAccounts.get, resourcemanager.projects.get).

A load balancer's backend health is read with backendServices.getHealth, a POST that reads and changes nothing; it needs the backend service's get permission. It is the only POST the platform makes to Google Cloud, and the platform refuses any other before it is sent.

Twelve permissions allow more than the product reads. compute.instances.list returns each instance's metadata items (startup scripts, SSH keys, any value an operator stored there); container.clusters.list returns each cluster's master credentials and its nodes' metadata; run.services.list returns each Cloud Run service's containers' environment variables and their values, arguments and commands, and its build's configuration; pubsub.topics.list returns each topic's message transforms, which are JavaScript source; pubsub.subscriptions.list returns the same transforms and each push subscription's endpoint, a URL that may carry a credential; compute.backendServices.list and compute.regionBackendServices.list, and the get permissions beside them, return each backend service's custom request and response headers, whose values may carry a credential, the identifier of an AWS access key it signs with, and its IAP client and that client's secret's hash; compute.urlMaps.list and compute.regionUrlMaps.list return the header values a URL map's routes add and match; and cloudfunctions.functions.list returns each function's build and service configuration, its environment variables and their values and its secret references among them, and its event trigger. None of them can be granted without those fields. Every request the platform makes carries a partial-response field mask (fields=) that names only the metadata it shows, so the content never crosses the wire, and an answer that carries it anyway is refused whole and nothing of it is stored (MILESTONE_1 §13.3). The mask is enforced by the platform's code and its tests; the role itself would let the reader see the content.

Regions. Instances, clusters, subnets, Cloud Run services and regional load balancers are read one region at a time, in the regions the project uses; global load balancers once per project. A project registers with none; region discovery finds them and adds them to the project's account, and an admin may add more by hand. Discovery only adds: a region is removed by an admin. A resource in a region the project had never used appears after the next discovery, which runs daily and once when the project is verified, rather than at the next collection. The subnets Google creates in every region for an auto-mode network, such as default, are not counted as use: a region holding only those is not added, and those subnets are listed on their network rather than as rows of their own.

The Google Cloud billing export

Spend reads a Google Cloud billing account's detailed usage cost export, the table gcp_billing_export_resource_v1_<billing account> that Google writes into a BigQuery dataset the customer chooses. The export is enabled in the Cloud console's Billing export page by someone holding Billing Account Administrator or Billing Account Costs Manager; Google has no API for that step. A dataset in the EU or US multi-region is backfilled from the start of the previous month.

The read is not made under the reader's custom role, which stays metadata only. The project holding the export is connected like any other project, and its reader is bound two predefined roles beside that role:

The job cost.gcp_billing runs daily for every Google project. The project holding an export runs one query a month for the current month and the two before it, through BigQuery's jobs.query and jobs.getQueryResults. Each query is capped by maximumBytesBilled (10 GiB unless the export's configuration says otherwise), filtered on the export's partitions from the month's start to the moment of the pull, and paged. A query over the cap is refused whole by BigQuery, bills nothing and writes nothing; the run says to raise the cap. A reader without the two roles is refused the same way, and the run names them. The export's conversion rate is never read: each currency stays apart. Corrections Google appends up to two months after their usage are read by a later pull; older months keep what the last pull that reached them wrote.

An administrator configures each export on Spend's Settings page (or POST /cost/gcp-billing-exports): the billing account, the table as project.dataset.table, and the byte cap. Changing or removing one asks for the password again; each write is in the audit log. The page shows each export's last read — the latest run of cost.gcp_billing for the table's project, with the reason when it was refused. Removing an export stops its reads; what was read stays.

The Azure reader

deploy/azure/reader-role.json, a custom role in each connected Azure subscription, assigned at the subscription to the app registration the platform signs in as (deploy/azure/reader.bicep). The platform signs in by outbound identity federation from its own AWS identity, or with a certificate on a deployment off AWS; no client secret exists. The role grants exactly the actions below, no wildcard and no data action. The built-in Reader would not do: its */read reads a site's configuration and Key Vault's secrets' names. Verification also reads the subscription (Microsoft.Resources/subscriptions/read) and the app's own permissions there (Microsoft.Authorization/permissions/read), and fails a role that grants any action besides these.

Every Azure module runs once per subscription: an Azure resource's id names no location, so its region is a property the region filter reads, as a Cloud SQL instance's is. Each list is paged to its end, and a list that Azure throttles past its retries is incomplete, not empty.

No action here returns content. A storage account's keys, a cluster's credentials and a site's app settings come from other actions (listKeys, listClusterAdminCredential, config/list), which the role never grants and verification refuses to see granted. The sites' list returns no settings; an answer that carried them would be refused whole and nothing of it stored.

One job that is not a collector reads the subscription too, and the role holds its one action:

A role that predates it fails verification's scope check, naming the action, and its runs are reported, not failed, until the role is updated from deploy/azure/reader-role.json.

The Azure export reader

Spend reads an Azure subscription's spend from the customer's own Cost Management export (FOCUS, daily, to a storage container) — or from the ActualCost and AmortizedCost exports of the same scope, both in that container — never from the Cost Management APIs. deploy/azure/export-reader-role.json is a second custom role, assigned to the same app on that one container (deploy/azure/export-reader.bicep), never the storage account or wider. It holds one data action and no action:

An administrator configures each export on Spend's Settings page (or POST /cost/azure-billing-exports): the subscription whose reader reads it, the storage account, the container, the export's directory — and, for the ActualCost and AmortizedCost pair, the second export's directory — and the most one file may hold. Changing or removing one asks for the password again; each write is in the audit log. The page shows each export's last read — the latest run of cost.azure_billing for its subscription, with the reason when it was refused. Removing an export stops its reads; what was read stays.

The platform asks for a Storage token for this read alone and sends it to the Blob service and nowhere else. It never writes or deletes a blob, never reads the account's keys and never asks for a user delegation key. The reader role above keeps no data action.

The report role

deploy/cloudformation/cost-report-role.yaml is deployed only in an account that delivers a Cost & Usage Report, and only for the bucket and prefix that account names. It is the one role that reads object contents: the report's own files, which hold the account's billing line items.

It has no bucket-wide read and no wildcard resource. A bucket encrypted with a customer-managed KMS key also needs a decrypt grant on that key, which the account adds to its own copy. Its trust policy is the reader role's: the external id (sts:AssumeRole), the source identity (sts:SetSourceIdentity) and the session tags (sts:TagSession).

The jobs that are not collectors

Versions