Today, Vantage is launching Data Access Policies, allowing organizations to enforce data boundaries inside Vantage so that users can only view and create reports containing the data they have access to. Organization Owners can create Access Policies and assign them to teams in Vantage, restricting the cost and resource data team members can see to specific accounts, providers, regions, or tags.

Previously, Vantage customers controlled team and user access to cost data through workspaces (via the integrations assigned to them), as well as through access to individual reports in those workspaces (e.g., Cost Reports and Dashboards). Customers with strict data-segregation requirements, such as financial services firms and enterprises with compliance-sensitive business units, needed more granular control over which costs, resources, and accounts each group could see. However, data boundaries don't always follow integrations. Organizations often divide their data by business unit, product, or cost center, across many accounts and providers. Separating that data by workspace meant replicating the same reports and dashboards in every workspace, one copy for each way the organization chose to view its data, and keeping every copy in sync as reporting needs changed.

Now, with Data Access Policies, Organization Owners can define what each team has access to at the data layer. Policies are enforced wherever team members view data, inclusive of Cost Reports, Dashboards, Active Resources, Cost Recommendations, FinOps Agent answers, and more. To create a policy, Owners navigate to the Policies tab on the Teams page in Settings, define access using common filter criteria across Vantage report types—such as provider, billing account, account, region, or tag—and assign the policy to one or more teams. When creating or auditing an Access Policy, Owners can Preview its impact, ensuring that it is correctly scoped and does not include any data a team should not have access to. Access Policies narrow what each team sees when viewing a report, but never widen it, so organizations can build universal Cost Reports and Dashboards once and share them with every team, without needing to recreate the underlying scope for each team. For example, a financial institution running several research teams from one workspace can use a Virtual Tag to map costs to each team, create a policy for each team's Virtual Tag value, and assign it to the matching team in Vantage, so every team uses the same dashboards and Cost Reports while seeing only its own spend.

Data Access Policies are generally available to Vantage Enterprise customers with contracted Build Hours. To get started, navigate to the Teams page in Settings, open the Policies tab, and select Create Policy. For more information, see the Access Policies section of Vantage's documentation.

Frequently Asked Questions

1. What is being launched today?

Vantage is launching Data Access Policies, which allow Organization Owners to restrict the cost and resource data each team can see, so team members only see the data they're allowed to across Cost Reports, Dashboards, Active Resources, Cost Recommendations, and more, no matter which report they open or how it's filtered.

2. Who has access to Access Policies?

Access Policies are generally available to Vantage Enterprise customers with contracted Build Hours. They are designed for organizations with strict data-segregation requirements, such as financial services firms, enterprises with multiple business units, and regulated industries where groups cannot view each other's cloud spend. They also suit any organization that wants to give broad teams self-serve access to Vantage without exposing costs outside each team's scope.

If eligible, Organization Owners can create policies from the Policies tab on the Teams page in Settings. If you are not currently eligible, contact the Vantage sales team at sales@vantage.sh.

3. How much do Access Policies cost?

There is no cost to create Access Policies. However, for accounts using Access Policies, Vantage generates a separate set of Forecasts and Anomalies for each unique combination of Access Policies on every Cost Report that has Forecasts and Anomaly Detection turned on, so that restricted users see results based only on their own data. This processing consumes Build Hours for each iteration beyond what is included as the standard (i.e., no Access Policies applied) Forecast and Anomalies. The amount of Build Hours consumed for each Cost Report depends on your data retention, the number of services included in the Cost Report, and the number of unique Access Policy combinations in your account. As an estimate, an average size enterprise customer would add 1 additional build hour per enabled cost report per month for every combination of Access Policies assigned to teams.

To manage consumption, you can set defaults for Forecasts and Anomaly Detection for all Cost Reports in a workspace, or turn each on or off for individual Cost Reports. See questions 17 and 18 for more information.

4. How do I set up an Access Policy?

Navigate to the Teams page in Settings, open the Policies tab, and select Create Policy. Enter an Access Policy Name and an optional Description, then select the Teams the policy applies to. Under Access Policy Filters, add the rules that define what those teams can see, using filter criteria that are common across every report type Access Policies apply to. You can preview the effects of the Access Policy by clicking “Preview”, which will show all reports with the Access Policy applied (note: anomalies and forecasts will not be shown in cost reports). The policy takes effect immediately for everyone on the selected teams.

You can also start from a team. On the Teams page in Settings, select a team, open the Access tab, and in the Policies section select Add Policy, then Add Existing Policy or Create Policy. A single policy can be assigned to many teams, so editing it once updates the boundary everywhere it's used. To detach a policy from one team without deleting it, select Remove from Team.

5. What permissions do I need to create or manage Access Policies?

Only Organization Owners can view, create, edit, assign, delete, or preview Access Policies.

6. Who do Access Policies apply to?

Access Policies apply to every user who belongs to a team with a policy assigned with the exception of Organization Owners. This includes users with the Integration Owner, Editor, and Viewer roles.

Organization Owners are not restricted by Access Policies and always see all data, even if a policy is assigned to a team they belong to. This ensures an administrator can never lock themselves out. Owners can use Preview to see what restricted users will see.

7. What can an Access Policy filter on?

Policy rules can use the following attributes:

• Provider
• Billing Account
• Account
• Region
• Service
• Tags, such as team:data-platform

Each rule uses "is" or "is not", and values must match exactly. Wildcard and prefix matching are not supported.

Not every area of Vantage describes data the same way. Active Resources are organized by resource type rather than by service, so Service rules don't narrow Active Resources. When a Service rule is combined with other rules, such as Account is production and Service is Amazon EC2, Active Resources are narrowed by the other rules only, so the team sees every resource in that account. A policy built only from Service rules shows no Active Resources at all. For a boundary that applies the same way everywhere, build policies from Provider, Billing Account, Account, Region, or Tags.

8. How do I create an Access Policy via the API?

Send a POST request to the /v2/access_policies endpoint with a title, the teams the policy applies to, and a filter written in Vantage Query Language (VQL). To create or change policies through the API, use a personal API token that belongs to an Organization Owner and has the write scope. Team service tokens cannot create or change Access Policies.

For example, the following request creates a policy that limits a team to AWS costs in the us-east-1 region. Save the request body as access_policy.json:

{
  "title": "Research Team A",
  "description": "Limits visibility to AWS costs in us-east-1.",
  "team_tokens": ["team_fd5c524ba104712b"],
  "policy": {
    "api_version": "v1",
    "policy": {
      "filter": "(vantage.provider = 'aws' AND vantage.region = 'us-east-1')"
    }
  }
}

Then send the request:

curl --request POST \
  --url https://api.vantage.sh/v2/access_policies \
  --header 'Authorization: Bearer <YOUR_API_TOKEN>' \
  --header 'Content-Type: application/json' \
  --data @access_policy.json

The API also supports listing, updating, and deleting Access Policies. Full details are available in the Vantage API documentation.

9. How do I create an Access Policy via Terraform?

Use the vantage_access_policy resource in the Vantage Terraform provider, so policies and their team assignments can be managed as infrastructure as code. The provider uses the same API token requirements described in the previous question. For example:

resource "vantage_access_policy" "research_team_a" {
  title       = "Research Team A"
  description = "Limits visibility to costs tagged for Research Team A."
  team_tokens = [vantage_team.research_team_a.token]

  policy = {
    api_version = "v1"
    filter      = "(tags.name = 'research-team' AND tags.value = 'team-a')"
  }
}

10. What format do Access Policy filters use in VQL for the API and Terraform?

Access Policy filters are written in VQL using the vantage and tags fields, which apply across every report type Access Policies cover, rather than the report-specific fields used elsewhere in Vantage, such as costs.provider. The following fields are available:

• Provider: vantage.provider
• Billing Account: vantage.provider_account_id
• Account: vantage.account_id
• Region: vantage.region
• Service: vantage.service
• Tags: tags.name and tags.value

Each condition uses = (is) or != (is not). Combine conditions with AND and OR, and pair tags.name with tags.value to match a specific tag. For example, (vantage.provider = 'aws' AND vantage.account_id = '123456789012') OR (tags.name = 'team' AND tags.value = 'research') allows one AWS account plus any costs tagged team:research.

11. How are rules evaluated if a team has multiple Access Policies applied, or if a user is part of multiple teams with Access Policies?

Within a single policy, rules combine as follows:

• Rules within a single filter are combined with AND. For example, Account is production and Region is us-east-1 matches data in both that account and that region.
• Multiple values on one rule are combined with OR. For example, Account is production, staging matches either account.
• Separate filters, added with Add a Filter, are combined with OR.

Across policies, a user sees data that matches any of the policies that apply to them, whether those policies are assigned to one team or come from several teams. Policies grant visibility, so each additional team or policy adds to what a person can see rather than reducing it. To narrow what someone sees, remove them from a team or tighten the policy on a team they belong to. Teams without an Access Policy are not restricted, so a user on any team without a policy sees all data in the workspaces that team can access.

12. Can I define an Access Policy that has no filter rules?

No, Access Policies must have at least one filter condition in order to be saved. You will receive an error if attempting to save an Access Policy without filter conditions.

13. How do I check what a policy will do before saving it?

Use the preview capability on the Access Policy in order to view its effect when building. On the policy form, click Preview to apply that policy to your own session and browse Vantage as a member of its teams would. Preview works on unsaved drafts and saved Access Policies. On a team's Access tab, click Preview in the Policies section to see how all of that team's policies work together. A banner shows what you're previewing; click the X on the banner to exit.

Previewing doesn't save anything or affect anyone else. Each preview covers either one policy or one team, so a person on several restricted teams may see more data than a single team's preview shows. A preview session ends on its own after about four hours.

14. Which parts of Vantage are scoped by Access Policies?

When an Access Policy applies, the following are scoped to the policy:

• Cost Reports, including their Forecasts, Anomalies, and dashboard widgets
• Active Resources and Resource Reports, including their dashboard widgets
• Cost Recommendations, active and archived, including their dashboard widgets
• Actual spend shown against Budgets
• Anomaly alert emails sent to Vantage users
• CSV and PDF exports of Cost Reports and Dashboards
• The FinOps Agent
• The Vantage MCP
• Canvas, which reflects the access of the user who created it (see question 25)
• Associated Vantage APIs for the reports and alerts above

15. Which parts of Vantage are not scoped by Access Policies?

The following are not filtered by Access Policies. Access to them can be managed through Vantage's existing RBAC controls for each report:

• Financial Commitment Reports and the Commitments list page
• Kubernetes Efficiency Reports
• Network Flow Reports
• Savings models
• Virtual Tag configuration

Cost Alerts, Budget Alerts, and Report Notifications are evaluated against the full data in the report or budget they monitor rather than each recipient's policies, so send them only to people and channels who should see that data.

16. How do Forecasts and Anomalies work for users with an Access Policy?

Restricted users see Forecasts and Anomalies calculated only from the data their policies allow. Vantage runs forecasting and anomaly detection separately for each unique combination of policies, so two users with different policies can see different forecasts and anomalies on the same Cost Report. Archiving or ignoring an anomaly applies only to users with the same combination of policies. After a policy or a team's membership changes, Forecasts and Anomalies for the new combination appear after Vantage's next scheduled run.

Anomaly alert emails sent to Vantage users only include anomalies from that user's own combination of policies. Alerts sent to Slack, Microsoft Teams, or Jira are sent for every policy combination, so route those alerts to channels whose members should see that data.

17. How do I set the default setting for Forecasts and Anomaly Detection for Cost Reports in a workspace?

Navigate to the Workspaces page in Settings and select the workspace. Under Cost Report Settings, set Anomaly Detection and Forecasts to Enabled or Disabled. The defaults apply to every Cost Report in the workspace that doesn't have its own setting, including existing reports. Reports set to On or Off in Manage Forecasts & Anomalies keep their own setting. Disabling these defaults for workspaces where they aren't needed is the simplest way to manage Build Hours consumption.

18. How do I turn Forecasts and Anomaly Detection on or off for a Cost Report?

Open the Cost Report, click the ellipses (...), and select Manage Forecasts & Anomalies. Set Anomaly Detection and Forecasts to On or Off, then click Save. You need edit access to the Cost Report to change these settings. Reports without their own setting follow the workspace default. To return a report to the workspace default, click the selected On or Off option again to clear it, then click Save.

Turning Forecasts or Anomaly Detection off for a Cost Report stops that processing for the report, which reduces the Build Hours consumed by Access Policies.

19. Do I need to change my existing reports, dashboards, or workspaces?

No. Existing Cost Reports, dashboards, workspaces, roles, and team permissions work exactly as they did before. Access Policies only restrict the teams they're assigned to, so teams without a policy see no change. A policy is never saved onto a report: when a restricted user creates or shares a report, every viewer sees it through their own policies.

20. How do Access Policies work with workspaces?

Workspaces and Access Policies work together. Workspaces continue to organize integrations and reporting items and control what teams can open. Access Policies control which data appears inside those items. Policies apply across your whole account, so a policy follows a person into every workspace they can access. Make sure the accounts, providers, and regions a policy names make sense in every workspace its teams can reach.

Because Access Policies isolate data within a shared workspace, you no longer need separate workspaces, or duplicate copies of the same reports and dashboards, just to keep teams' data apart. You can keep your current workspace structure, or consolidate shared reporting into fewer workspaces whenever it suits you.

21. Can I assign an Access Policy to an individual user?

At launch, Access Policies can only be assigned to teams. To restrict one person, add them to a team with the appropriate policy. If you map SSO groups to Vantage teams, team membership is updated each time a user signs in, so Access Policies follow people automatically as they move between groups. Support for assigning policies directly to users is planned.

22. How should I set up teams for Access Policies?

Every user is automatically a member of the Everyone team, and Access Policies apply to people through the teams they belong to. A user with no policy on any of their teams sees all data in the workspaces they can access. Once any of their teams has a policy, they see only the data their policies allow, and teams without a policy, including Everyone, don't add to it.

To set up and maintain teams:

• Map SSO groups to teams. On the Authentication page in Settings, turn on SSO Team Assignment. Each time a user signs in, Vantage adds them to the teams whose names match their SSO groups and removes them from teams that no longer match, so policies follow people as they change roles. Use Custom Mapping to connect an SSO Group Name to a Vantage Team with a different name.
• Manage teams as code. Create teams with the vantage_team resource in the Vantage Terraform provider, then assign policies to them with team_tokens on the vantage_access_policy resource, as shown in question 9.
• Decide what the Everyone team should see. A policy on the Everyone team applies to every user except Organization Owners and adds to their other policies, so it sets the baseline everyone sees. To make sure new users don't see all data before they're added to a team, assign the Everyone team a policy limited to data every user may see, such as shared platform costs.

23. Will users know that an Access Policy is applied to them?

Not directly. The policy is not shown as a filter on their reports, and they can't view, edit, or remove it. Their totals reflect only the data they're allowed to see, and filter menus only show values within their scope.

24. Do Access Policies change what users can create, edit, or delete?

No. Access Policies only control which data a person sees. What a person can open, create, edit, delete, and share is still governed by their role, their team's workspace access, and any item-level access grants. Because the data boundary holds however a report is built, restricted users can safely be given the Editor role to build and explore their own reports.

25. Do API tokens, the FinOps Agent, Canvas, and the Vantage MCP respect Access Policies?

Yes. A personal API token returns the same data its owner sees in the console, including the policies from their teams. A team service token returns the data allowed by the policies assigned to that team. The FinOps Agent and the Vantage MCP query Vantage on behalf of the signed-in user, so their answers are limited to the data that user's policies allow, and two people asking the same question can get different answers.

A Canvas shows the data from the last time its creator refreshed it, so it reflects the creator's access rather than each viewer's access. To control who can see a Canvas that contains sensitive data, use Manage Access on the Canvas.

26. Are changes to Access Policies logged in the Audit Log?

Yes. Creating, updating, and deleting Access Policies is recorded in the Audit Log under the Access Policy object type, along with the user who made the change.

27. What happens if a policy matches no data?

Reports open normally but show no costs. The user doesn't see an error or an access-denied message. This usually happens when a policy names accounts that don't exist in the workspace the user is viewing.

28. How do Access Policies work for MSP Managed Accounts?

Access Policies are configured per Vantage account. A policy created in a Management Account applies only within that account and does not follow users into Managed Accounts. To restrict what a user sees inside a Managed Account, create an Access Policy in that Managed Account.