Security model
What Access X-Ray can read and write, what it stores, and what leaves your instance.
Access X-Ray is a read-only analysis tool. This document states exactly what it reads, what it writes, who can use it, and what it deliberately does not do.
What it reads
| Data | Why |
|---|---|
| res.users | The accounts being analysed, and their last login for the dormancy finding |
| res.groups | Group membership and the implied_ids inheritance graph |
| ir.model.access | Model-level access rules |
| ir.rule | Record rules, global and per-group |
| ir.model | To resolve model ids to names |
That is the whole list. It reads the permission system; it does not read your business records. It never opens account.move, hr.payslip or any other model it reports on — it reports on who could, not on what is in them.
What it writes
| Data | Notes |
|---|---|
| access.finding | Its own risk findings, replaced on each scan |
| access.user.probe / access.model.probe / access.compare and their lines | Its own transient query results |
Nothing else, ever. It cannot change anyone's permissions, add or remove a group, or edit an access rule or record rule. There is an automated test in the module that asserts exactly this, so the guarantee is enforced rather than promised.
This is why it is safe to install on a production database.
What leaves your instance
Nothing. No external service, no outbound connection, no telemetry, no licence check that phones home. Access data never leaves your Odoo.
Who can use it
Every model in the module is restricted to base.group_system (Settings). There is no viewer role.
This is intentional and it is the most important security decision in the module. The output is a complete map of who can reach what — which is exactly the reconnaissance an attacker or a disgruntled insider would want, handed over pre-computed and sorted by value. Giving it a wider audience than the people who already hold the keys would manufacture the risk the product exists to find.
If that seems restrictive: anyone who can already read ir.model.access and ir.rule can reconstruct this by hand. The module does not reveal anything a Settings user could not already work out. It only removes the hours.
Threat model
| Concern | Position |
|---|---|
| Privilege escalation via this module | Not possible. It has no write path to users, groups or rules. |
| Information disclosure to lower-privileged users | Prevented by restricting every model to base.group_system. |
| Data exfiltration | No outbound connection exists. Findings live in your database. |
| Tampering with findings to hide a risk | A Settings user can delete findings — but a Settings user is already unconstrained, so this is not a boundary the module can defend. Re-running a scan reproduces the findings from live data. |
| Denial of service via a large scan | A scan is bounded by the number of users, groups and rules, not by business data volume. See TROUBLESHOOTING.md for very large directories. |
What it does not claim
- Not a compliance certification. It produces evidence you can act on. It does not certify anything to anyone.
- Not field-level analysis. Field groups= attributes are not resolved in this version. A user reported as able to read a model may still be unable to see individual fields on it.
- Not a substitute for the audit trail. Knowing who can act is not knowing who did. That is Security & Audit Center's job, and neither module requires the other.
Reporting a security issue
Email info@technovision.dev. Please do not open a public issue for a suspected vulnerability. We will acknowledge within two working days.