> For the complete documentation index, see [llms.txt](https://docs.powermonitor.com.br/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.powermonitor.com.br/en/principais-funcionalidades/auditoria-e-seguranca.md).

# Audit and Security

Power Monitor Audit and Security: who has and who had access to what, who viewed each report and from where, service principals, RLS, direct sharing, subscriptions and behavioral risk, with a historic

"Who had access to this report on the day the numbers leaked?" The Power BI portal tells you who has access **today**, workspace by workspace. The activity log keeps events for a limited time, in a format nobody can read without building a data project.

Power Monitor collects, stores and organizes all of it so you can answer in minutes whatever the auditors, the legal team or information security ask.

## Who has access, and through which path

The **Permissions Audit** and the **Permissions Dashboard** show every permission on workspaces, Fabric items, gateways, connections and Power Embedded, including access **inherited from groups** and **from the workspace**. Risk findings are ready for you: external accounts with write permission, workspaces with no administrator, access that perhaps should not exist.

<figure><picture><source srcset="/files/r5wgD6f4H4S5KxK2WsjW" media="(prefers-color-scheme: dark)"><img src="https://3938213054-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FH2bFRBmIfyK3kwVKbldl%2Fuploads%2Fgit-blob-9eda8bf1677b088705f367a7ebfe9e5a585e1a5c%2Fpm-dashboards-permissoes-revisao-acesso-en.png?alt=media" alt="Permissions Dashboard with the access that deserves review"></picture><figcaption><p>Permissions Dashboard: access that deserves review</p></figcaption></figure>

## Who had access on a past date

The **Permission history** records who gained, lost or changed access over time and answers, for any covered date, **who had access** to a workspace or artifact. It is the question every incident investigation starts with.

<figure><picture><source srcset="/files/ok3U27ayCAzTeRH88Dxm" media="(prefers-color-scheme: dark)"><img src="https://3938213054-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FH2bFRBmIfyK3kwVKbldl%2Fuploads%2Fgit-blob-5d189e5957a8e755f4cde608e9a0f86b88cab7c8%2Fpm-auditoria-historico-permissoes-quem-tinha-acesso-en.png?alt=media" alt="Permission history answering who had access on a past date"></picture><figcaption><p>Who had access on a given date</p></figcaption></figure>

## Who viewed what, and from where

* **Events Overview:** every Power BI and Fabric activity (views, edits, deletions, sharing, Copilot, administration), with a shortcut to the **Critical Actions**.
* **Report Views:** who opened each report or dashboard, with the country, state and city the access came from.
* **Access alerts:** access from a new country, improbable distance jumps between two accesses and simultaneous access.

## Behavioral risk

A **daily score from 0 to 100**, per person, that compares each person's activity with their own history and flags changes that deserve attention: a spike in exports, an account coming back after months of inactivity, access from distant locations within a short time. Each score shows the factors behind it, with no black box, and the organization decides whether to turn on the feature and the network signals. It helps you find the risk before it becomes an incident.

<figure><picture><source srcset="/files/oB0yNJOBiF9kw08BgjT0" media="(prefers-color-scheme: dark)"><img src="https://3938213054-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FH2bFRBmIfyK3kwVKbldl%2Fuploads%2Fgit-blob-f2bf8f33611752b2e9c55a081333aeb8e9236914%2Fpm-auditoria-risco-comportamental-en.png?alt=media" alt="Behavioral risk screen with the per-person ranking and the trend"></picture><figcaption><p>Behavioral risk per person</p></figcaption></figure>

## The audits nobody does by hand

* **Service Principals:** applications with direct permission in the environment, highlighting write access and workspace administration by third parties.
* **Row-Level Security:** each model's RLS roles, members and filters, and the findings (labeled model without RLS, role with no members or no filter).
* **Direct Sharing:** who accesses an item without having access to its workspace.
* **E-mail Subscriptions:** reports with a scheduled subscription and how many subscribers are from an external domain.
* **Access reviews:** campaigns in which the owners of each workspace confirm, person by person, who should keep access, with a record of every decision.

## And the audit of Power Monitor itself

Logins, pages accessed, configuration changes, consents, emails sent and actions executed on capacities are also recorded. Whoever administers Power Monitor is auditable too.

## Why it matters

* **Compliance without spreadsheets:** LGPD, ISO 27001 and SOC 2 require a historical trail, and it is already in place.
* **Investigation in minutes:** who had access, who viewed and from where, in a single tool.
* **A smaller risk surface:** excessive, external and forgotten access shows up before the audit does.

## Related pages

* [Audit](/en/power-monitor/auditoria.md): every screen in the module
* [Permissions Dashboard](/en/power-monitor/dashboards/dashboard-de-permissoes.md)
* [Permissions and Access](/en/principais-funcionalidades/permissoes-e-acessos.md)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.powermonitor.com.br/en/principais-funcionalidades/auditoria-e-seguranca.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
