Security and access
What access does Arrio need to our systems?
The short answer
Arrio reads your repositories, and it reads them read-only. It does not need write access, it does not need production systems, and it does not need your customer data. Beyond that, Arrio supports several deployment and security models, so exactly where the analysis runs and what it touches is set to what your business requires rather than fixed by us.
Repository access, and read-only
Arrio works from the record your engineering organisation already produces: the codebases and their history. That access is read-only in every supported setup. Arrio does not commit, does not open pull requests, does not change configuration and does not need permission to do any of those things.
The practical version of that: a reviewer asking "could this tool change our code" has one answer, and it is no.
What Arrio does not ask for
Not your production environments. Not your customer data. Not your ticketing system as a condition of starting, though delivery context can be connected where it makes the reading more useful. The analysis is of the work, not of the people doing it, so Arrio has no reason to hold anything that identifies an individual beyond what a commit already carries.
We measure the work, never the worker. That is a design decision rather than a setting, and it is the reason several of the things an engineering-analytics product would collect are simply absent here.
Where it runs is a decision, not a default
Arrio supports multiple security, safety and deployment models, chosen against what your organisation actually needs. That includes running in your own cloud. You choose where your data lives.
The specifics change as the product does, so they live in the documentation rather than on a marketing page, where they would quietly go out of date.
What your security team will want to see
Most reviews come down to the same four questions: what is accessed, what is retained, where it is processed, and who can see the result. Those are answered concretely in the documentation, including the sub-processor list and the data processing agreement, and a founder will go through them with your team directly.
Bring your security team. The answers are the same either way.