Power BI is a high-impact surface for enterprise agents because it can reveal sensitive business metrics and, via official API with enterprise buildout controls, can also change content like datasets, reports, workspaces, and sharing. Claw EA runs agents on OpenClaw as the baseline runtime, then adds permissioned execution so every Power BI action is allowed by policy-as-code, not just a “please be careful” prompt.
Prompt-only controls fail because a malicious or misconfigured skill can still call APIs once it has credentials. Use a WPC = Work Policy Contract to declare what the agent may do, issue a CST = scoped token bound to that policy, and require proof artifacts (gateway receipts and proof bundles) for audit and replay checks.
Step-by-step runbook
-
Define the Power BI job boundary. Start with a single workspace, a small set of datasets or semantic models, and a narrow task like “refresh and read metrics” or “export a report snapshot for finance review.”
-
Choose identity and least-privilege scopes in Microsoft terms. Use Entra ID app registration or a service principal with explicit Microsoft Graph permissions and Power BI permissions/scopes that match your task, and keep “admin” capabilities off by default.
-
Write a WPC that gates Power BI operations. The WPC should enumerate allowed API families (read vs write vs admin), allowed workspace IDs, and any required human approval steps for write or sharing actions.
-
Issue a CST from clawscope for the specific job. Pin the CST scope hash and optionally pin the WPC policy hash so the runtime fails closed if a different policy is presented.
-
Run the agent in OpenClaw with tool policy and sandboxing set to minimize blast radius. Keep the Power BI capability as an explicit tool, deny generic “HTTP to anywhere” patterns, and avoid elevated host execution unless there is a documented reason.
-
Route model calls through clawproxy where applicable. This produces gateway receipts for model calls, which later become part of the proof bundle for the run.
-
Export and store the proof bundle for audit. Attach the bundle to your ticket, store it in your evidence system, or publish it to Trust Pulse when you need a marketplace-stored artifact for audit/viewing.
Threat model
| Threat | What happens | Control |
|---|---|---|
| Over-broad Power BI permissions | The agent can enumerate workspaces, read unintended datasets, or change content outside the intended business unit. | Entra ID least-privilege app permissions plus a WPC that restricts workspace IDs and action families (read vs write vs admin). |
| Prompt injection through descriptions, report text, or dataset fields | Model output is steered into unsafe tool calls, such as sharing a report externally or exporting more data than needed. | Policy-as-code gates for write/share/export, plus OpenClaw tool allow/deny profiles so the model cannot call arbitrary tools when it is manipulated. |
| Misconfigured sharing and access grants | The agent adds users/groups, changes workspace roles, or generates sharing links that widen access. | Write and admin actions require WPC approval gates, CST enforcement, and explicit least-privilege auth scopes. Use PIM for admin elevation outside the agent path. |
| Data exfiltration via exports | The agent exports reports or underlying data and writes it to a location that is not approved. | WPC restricts export operations and destinations at the tool layer. Egress allowlists can be implemented outside clawproxy (optional) if you need network-level enforcement. |
| Replay of prior authorizations | A captured token or workflow artifact is reused to repeat a sensitive operation later. | Marketplace anti-replay binding using job-scoped CST binding, and proof bundles that tie receipts and run metadata to a specific job. |
| Unverifiable “what did the model see and decide?” | You cannot reconstruct why a report was modified or why a set of data was queried. | Route model calls through clawproxy to emit gateway receipts, then bundle them into a proof bundle for verification and audit. |
Policy-as-code example
This example shows the shape of a WPC for a Power BI job. It separates read actions from write/admin actions, pins the allowed workspaces, and requires an explicit approval gate for anything that changes sharing or permissions.
{
"wpc_version": "1",
"tool": "powerbi",
"connection": {
"mode": "official_api",
"auth": {
"entra_id": {
"principal_type": "service_principal",
"tenant": "YOUR_TENANT_ID"
},
"required_scopes": [
"PowerBI.Read.All"
]
}
},
"limits": {
"allowed_workspaces": ["WORKSPACE_ID_FINANCE"],
"allowed_actions": [
"list_reports",
"get_report",
"query_dataset",
"refresh_dataset_status"
],
"deny_actions": [
"add_workspace_user",
"update_workspace_role",
"create_sharing_link",
"publish_report",
"update_dataset",
"delete_report"
]
},
"approval_gates": [
{
"when_action_in": [
"add_workspace_user",
"update_workspace_role",
"create_sharing_link",
"publish_report",
"update_dataset",
"delete_report"
],
"require": "human_approval"
}
],
"attestation": {
"require_gateway_receipts": true,
"require_proof_bundle": true,
"cst_policy_hash_pinning": "optional"
}
}
Operationally, the CST is minted for this job and is only valid for the policy scope hash. If an agent tries to step outside the allowed workspaces or actions, the run should fail closed at the execution layer, not rely on the model to self-correct.
What proof do you get?
For model calls routed through clawproxy, you get gateway receipts: signed receipts emitted by clawproxy for model calls. These receipts are designed to make later verification possible without trusting the agent’s own logs.
For the overall run, you get a proof bundle: a harness artifact bundling receipts and related metadata for audit/verification. If you use Trust Pulse, you can store and view the artifact as a marketplace-stored artifact for audit/viewing, which helps when you need to share evidence across teams.
For Power BI itself, evidence still depends on what Microsoft logs you already retain. The Claw EA side focuses on proving the agent’s execution path, the policy in effect (WPC hash), and the job binding (CST binding) used to authorize the work.
Rollback posture
| Action | Safe rollback | Evidence to check |
|---|---|---|
| Agent queried more data than intended | Revoke the CST, tighten the WPC allowed_actions, and re-run with narrower dataset queries or a smaller workspace list. | Proof bundle showing the WPC hash used, job-scoped CST binding, and gateway receipts for the model calls that led to the query. |
| Agent changed a report or dataset | Disable write actions in the WPC, rotate Entra ID credentials if needed, then restore Power BI content using your standard workspace versioning or admin recovery process. | Proof bundle for the run that performed write attempts, plus Microsoft audit logs and workspace activity logs where available. |
| Agent modified sharing or permissions | Remove added principals, revert workspace roles, and require PIM elevation for any future permission changes. Add a permanent WPC approval gate for sharing-related actions. | WPC approval records (if you require them), proof bundle and receipts for the run, and Entra ID or Power BI audit logs showing the access change. |
| Suspected prompt injection from report content | Freeze the integration by revoking CST issuance for the tool, quarantine the affected dataset/report, and re-run only after adding explicit deny rules and narrowing tool access in OpenClaw. | Gateway receipts around the injection window and the proof bundle event metadata that ties the run to the affected session. |
This rollback posture assumes Power BI is connected via official API with enterprise buildout controls, not a native connector. If you need network-level containment, egress allowlists enforced outside clawproxy can be implemented (optional) as part of an enterprise buildout.
FAQ
Why isn’t prompt-only guidance enough for Power BI access?
Because once the agent has credentials, a malicious or coerced tool call can still hit the API. Permissioned execution uses a WPC and CST enforcement so the platform can refuse actions even when the model tries to do them.
Is this a native Power BI connector in Claw EA today?
No. Power BI can be connected via official API with enterprise buildout controls, and you should plan for explicit policy gates and least-privilege scopes for each action.
How do WPC and CST map to Microsoft controls like Entra ID and Conditional Access?
Entra ID and Conditional Access govern who can obtain tokens and under what conditions. WPC and CST govern what the agent is permitted to do once it is running, and they make that permission set portable and hash-addressed for audit.
What should require approval versus being fully automated?
Read-only analytics tasks can usually be automated when constrained to a known workspace and dataset set. Write, publish, share, and permission changes should be gated by WPC approval rules and backed by explicit admin scopes, ideally with PIM for any human elevation path.
What artifacts should my auditors expect to see?
Expect the WPC hash, the job-scoped CST binding, gateway receipts for model calls (when routed via clawproxy), and a proof bundle tying the run together. Pair that with Microsoft audit logs for the Power BI tenant and the specific workspace actions.