# Read runtime permissions and revoke access

Runtime permissions report the function authority currently returned for the workspace. Inspect the exact policy ID, revision, scopes and approval requirements; a saved instruction document or a missing observation is not evidence of an active runtime grant.

## Read the owning record

Open [Runtime permissions](https://dashboard.ouros.md/policy/board). Use **All**, **Active**, **Revoked** or **Device drafts** to identify the record you need. Device drafts describe authored material; they are not active function policies.

| Observation | Interpretation |
| --- | --- |
| Policy ID and revision | Identity of the runtime record being inspected |
| Allowed or denied function | Reported permission for that function, not unrestricted host access |
| Approval required | The action must pass its approval gate before dispatch |
| Exact permissions and scopes | Full returned permission data; inspect resource limits as well as the function name |
| Spent, Held, Remaining and Limit | Runtime-reported spending state for that policy; not membership price or promised allowance |
| Runtime unavailable | Permission state could not be loaded; do not infer there are no policies |
| No rules reported | No rules were returned for that record; not a grant of unrestricted permission |

Missing amounts remain unavailable. Do not read a blank or absent observation as zero, or derive a monthly usage total from one policy's budget fields. Hosted billing owns purchase terms.

## Review a governed action

In Loop Builder, open **Runs & approvals**, select the intended run and inspect its exact action. A request to save a note and a model request have different inputs and effects. Review the target, content and any displayed hold before choosing **Approve action** or **Deny action**.

Approval can execute the pending function action. This differs from **Activate in Bar** for a hosted loop version, which makes that version available but starts no run. Neither control proves the result satisfies the task.

## Revoke deliberately

1. Identify the policy and revision whose access should stop.
2. Choose **Revoke permission** on that active record.
3. Read the confirmation and confirm only the intended revocation.
4. Refresh and confirm that the same policy is reported as revoked.
5. Inspect already dispatched work and its result separately.

Revocation stops pending and future actions under that policy; work already sent cannot be recalled. Revocation is not a file rollback, a refund, a deletion request or cancellation of a separate hosted artifact run. If the response is uncertain, read back the original policy before repeating a change.

## Change limits in the owning workflow

Loop Builder's **Permissions & spending** panel manages its workspace functions. Do not increase a limit or remove approval requirements as a routine response to a failed run. Establish the task's authority first, then use [same-run review](/docs/loop-builder/review-agent-performance) to determine what actually happened.