---
title: "Metacenta security: what a review reads and what it can't see"
description: "What you send for a Metacenta review, how we handle it, what we can't see, the fifteen areas we check and what you get back. No warehouse connection needed."
url: "https://metacenta.com/security"
updated: "2026-10-31"
tokens: 2444
---

Security and scope

# What we read, what we can't see, and what you get

Here's what a review reads, how we handle it and where its limits are.

We don't need access to your data. We don't need your credentials. And your source code doesn't have to leave your network.

## What you send

It's all output your team already produces. Only `manifest.json` is essential; each extra file answers something the manifest can't.

## Security and your data

We read named dbt artefacts and repository metadata through a read-only token. We never see a row of your data, and we never clone your repository.

If you pick a project folder, your browser reads it and only the findings come to us. Measure definitions in SQL, LookML, DAX or Tableau become fingerprints, unless you ask to see them side by side. We skip `profiles.yml` entirely, because that's where warehouse credentials live.

The checks make no LLM calls and produce the whole report on their own. An optional extra pass sends a digest (check ids, severities, counts, example asset names) to an LLM provider. It's off unless you ask for it, owner names and email addresses are left out, and the report lists what was sent.

## Limitations

- **Your data.** We never read a row. From `catalog.json` we use the warehouse's own statistics about each relation, so we can point out the biggest tables and whether anything reads them.
- **Cost.** We put a figure on it only at rates you give us. It's estimated from usage unless you run our billing script on Snowflake. Query speed isn't covered.
- **Your code.** We read repository metadata, dbt config files and your dependency manifest. A project folder is read in your browser. We don't open notebooks, and we keep nothing we read.
- **What happens outside the files.** We can't see how jobs actually ran or which dashboards people open unless you send that history: OpenLineage events for the first, a BI usage export for the second. Looker views link to tables, not fields to columns.
- **Owners we can't see.** If ownership lives in a rota rather than in dbt groups or `meta`, those assets show up as unowned. That says something about the metadata, not your team.
- **Doing the fixes.** We write the report and the worklist. If you'd like help with the work itself, ask: it's a separate scope.

## What we look for

Fifteen areas, and what we check in each.

- **Metric consistency**: Logic copied between models, tables that skip `ref()`, models that never say what one row means, and columns your YAML lists but the warehouse doesn't have.
- **Metric definitions**: The same measure defined differently across Looker, Power BI, Tableau and dbt metrics, and Looker joins that inflate a total.
- **Build reliability**: Tests and models that failed in the last run, and everything downstream that they held up.
- **Source freshness**: Sources that were past their freshness limit last time they were checked, and sources nobody checks at all.
- **Change risk**: Long dependency chains, models everything leans on, models with no contract, and whether the models that change most are the tested ones.
- **Build performance**: The models eating most of your build time, full rebuilds on every run, and tests that cost more than the thing they check.
- **Orchestration**: Scheduled jobs with no owner, retry or alert, and the dashboards that depend on a job that would fail without telling anyone.
- **Platform and lineage**: Terraform grants wider than they need to be, public buckets, warehouses that never suspend, and jobs whose last run failed.
- **Ownership**: Models, sources and exposures with no group, no owner in `meta` and nobody to contact when they break.
- **Documentation**: Models, columns and sources with no description, and how much of the project that adds up to.
- **Actual usage**: Which models anyone actually queries, how often each is built against how often it's read, and which tables cost the most to scan.
- **Governance readiness**: Whether you have CI and CODEOWNERS, how much rests on one or two people, and credentials committed to the repository.
- **BI semantic layer**: Measures pointing at columns that don't exist, untested join keys, and BI models reading tables your pipeline doesn't build.
- **AI lifecycle**: Unpinned model libraries, no record of which run produced which model, outputs nobody evaluates, and notebooks committed with their results.
- **SQL without dbt**: No dbt? We rebuild the lineage from plain SQL files, then look for cycles, tables with two writers, unbounded selects and untested tables.

If a check can't run, we say so rather than counting it as a pass. Where someone has already published the rule, like dbt Labs' `dbt_project_evaluator` or OpenSSF Scorecard, we name it and say how closely we follow it.

## What you get

- **Report**: A PDF that opens with the verdict and then backs it up. Every area gets a score, and every score says what it's based on.
- **Worklist**: A spreadsheet with one row per finding: the asset, the file, the evidence, the fix and the owner. Ready to drop into your backlog.
- **Portal**: A private page with every finding in one table you can filter by model, check or owner. Your team signs in with a link.

Send your warehouse query history and your own rates, and the report also prices each model and dashboard, and shows where that money pays for work nobody reads. If you use AI, you get a level from 0 to 4 for each of enablement, use, governance and security. The levels are never averaged into one score, and each says whether it rests on your files or your answers.

| Artefact | How you get it | What it adds |
| --- | --- | --- |
| manifest.json | dbt parse, or any build — already in target/ | Testing, documentation, lineage, modelling, ownership, the dbt semantic layer |
| run_results.json | Sits beside it after dbt build | What the last build did, plus per-model build times |
| sources.json | dbt source freshness | Whether upstream sources are arriving on time |
| catalog.json | dbt docs generate | Where the YAML and the warehouse disagree, plus table sizes and row counts |
| A read-only repository token | GitHub, GitLab or Bitbucket, and read-only. On GitHub a private repository needs Contents as well as Metadata to list its files. We open only named config files | CI, contributor concentration, CODEOWNERS |
| Your change history | One git command you run yourself — commit dates and file paths only, no names or messages | Which models change most often, and whether those are the tested ones |
| Your LookML project | A copy of the .lkml files. Measure SQL is reduced to a fingerprint | Whether dashboards read the models dbt builds, and whether their joins count correctly |
| A project folder | Picked in your browser and read there: SQL, Power BI, Tableau, Terraform, Airflow and Dagster files | Lineage without dbt, one measure defined several ways, broad grants, jobs behind dashboards |
| OpenLineage events | An export from Marquez or your lineage backend | What actually ran, which jobs failed, and which tables two jobs write |
| A BI usage export | A CSV you export from Looker, Power BI or Tableau: dashboard ids and view counts, no viewer names | Which dashboards anyone actually opens |
| Warehouse query history | A read-only query you run yourself — no credential | Which models anyone actually reads, what scans the most, and how often each is built against how often it's read |
| Warehouse credentials | Optional, never required | Nothing the query above does not already give us |
| Your own rates | Per credit, per DBU, per TiB or per compute hour, as you pay them, and who supplied them | What each model and dashboard costs a month, in your currency. Without rates we show counts only |
| Answers about how you use AI | A short form in your portal, asking only what your files can't show | A level for each of AI enablement, use, governance and security |

A review can start from the manifest alone, or from a project folder.

## Frequently asked questions

### How long does it take, and what do we need to do?

Upload the artefacts to your portal and answer a few questions about what the platform is for. By default your browser reads each file and only the findings come to us. The checks run over every model, source and test, not a sample. Then a person goes through each finding, cuts the ones that aren't worth your time, and writes the report. Most reviews are back within a week.

### Can you tell us what the platform costs, and where to save?

Yes, if you send your query history and the rates you actually pay. We price each model's builds and storage, and say which dashboards keep which models running. Each saving is an upper bound, counted once per model, never a forecast. Without your rates we show how often each model is built and read, and leave the money out.

### Can we compare our score with another review?

With an earlier review of your own project, yes. The report names the check-suite version it ran, and we tell you when a version change means two scores don't compare. Not with another company, and not with a standard. Where a check matches a published rule, we name the rule.

### Who can see the findings?

You can. Findings are kept per client, isolated at the database level. The portal has no sign-up: access is by invitation to named addresses, and we can withdraw it straight away.

[Request a review](https://metacenta.com/enquire?src=security&via=md)

## Related pages

- [The Technical Review](https://metacenta.com/)
- [Pricing](https://metacenta.com/pricing)
- [How we assess](https://metacenta.com/standard)
- [Every rule we check](https://metacenta.com/rules)
- [Privacy notice](https://metacenta.com/privacy)
- [Terms of engagement](https://metacenta.com/terms)