> For the complete documentation index, see [llms.txt](https://docs.podigee.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.podigee.com/documentation/grow-and-monetize/monetization/grant-temporary-sensitive-access.md).

# Grant temporary sensitive access

Give a verified person limited access to sensitive information for a clear purpose and time.

Podigee Audio Video Ad Server lets an authorized operator grant limited access to sensitive information for a specific purpose. After the first mention, this article uses Podigee Ad Server for the product name. The grant has an exact person, permission set, workspace scope, start time, and end time. It expires automatically and never lasts more than 24 hours.

Use this task when a support, privacy, or security operator must inspect protected information to resolve a verified case. Do not use it as a general team-access method. Use the normal role and workspace access settings for ongoing work.

## Before you start

* You have permission to grant sensitive access in the selected workspace.
* An active privacy or security case supports the request.
* The case has an exact approved scope and current review.
* You know the verified person who will receive access.
* You know the smallest set of information needed.
* You know the reason, start time, and end time.

The case must support the access. The person must be active and verified. Service accounts are not eligible for this grant.

## Open the sensitive access job

1. Open **Monetization > Revenue jobs**.
2. Select **Security, privacy, and audit**.
3. Select **Grant temporary sensitive access**.
4. Choose the supporting privacy or security case.

The case list shows only active cases in the current workspace. Check the case reference and state before you select it.

## Choose the recipient and purpose

1. Select **Person receiving access**.
2. Enter **Why access is needed**.
3. Write a short reason that names the case and the work to complete.

Use a person who is active and verified. Do not enter a password, token, raw customer identity, or other secret in the purpose field. A good purpose is specific, for example, “Investigate the verified privacy request in case 1234 and confirm the affected records.”

## Select the smallest permission set

1. Open **Allowed information**.
2. Select only the permissions needed for the stated purpose.
3. Remove any permission that is not needed to complete the case.

The available permissions are controlled by the workspace. The exact set is recorded with a digest. A later change to the permission list does not silently change an existing grant.

![The current One Podigee access form shows a named person, a role, the workspace scope, and the review boundary before access is saved.](https://2032417310-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FbqUKO6lljHGzkEAzliPI%2Fuploads%2Fgit-blob-bc33d9a199390707136322a3145c260505448d35%2Fdoc-monetization-016-change-access.png?alt=media)

*Review the person and scope before you save any access change.*

## Set the access window

1. Set **Starts at** to the time when the operator needs access.
2. Set **Ends at** to the time when the work should stop.
3. Keep the window within 24 hours.
4. Use the shortest useful window. Do not leave it open for a whole shift when one hour is enough.

The end time is an automatic revocation boundary. The grant is not active before its start time or after its end time.

![The current One Podigee End access section shows a time boundary and confirmation controls for stopping access.](https://2032417310-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FbqUKO6lljHGzkEAzliPI%2Fuploads%2Fgit-blob-d335fec7070c7866db0d4ec9721f0fad7c59c2d8%2Fdoc-monetization-016-end-access.png?alt=media)

*Use an explicit end boundary when you stop access. Keep the action and its receipt with the case.*

## Review and apply the grant

1. Review the supporting case, recipient, purpose, permissions, workspace scope, and time window.
2. Check the permission count and the exact allowed-information list.
3. Confirm the case review and scope are still current.
4. Select **Apply action**.
5. Wait for the result page.

The operation checks the current case version, active permission definitions, permission-set digest, and time window. If any of these changed, no grant is created. Review the current case and submit again only after the authority is clear.

## Confirm completion

The result shows:

* the person who received access;
* the stated purpose;
* the allowed information;
* the start and end times;
* the supporting case; and
* the active access state.

Keep the receipt with the case. Tell the recipient how to stop when the work is complete. If the work finishes early, revoke any related normal workspace access using **Monetization settings > People and access**. The sensitive grant still ends at its declared boundary, and its history is retained.

## If the grant cannot be created

* **The case is not active:** do not select another case to bypass the state check. Reopen or replace the case through the approved security process.
* **The person is disabled or unverified:** keep the request pending until the person is verified.
* **A permission is unavailable:** remove it and reassess the purpose. Do not copy a permission name into a free-text field.
* **The time window is too long or already ended:** set a shorter future window.
* **The case changed during review:** reopen the current case and check the scope again.
* **Access must stop immediately:** use the approved workspace access revocation or security containment process, then keep both receipts with the case.

## Expected result

One active, purpose-bound grant exists for one verified person, one workspace scope, one exact permission set, and one short time window. The grant expires automatically, and the case, receipt, permissions, and access state can be reconstructed without exposing protected data.

## Next useful tasks

Use [Create and test a custom role](/documentation/grow-and-monetize/monetization/create-and-test-a-custom-role.md) for recurring team access. Use [Fulfill a privacy access or export request](/documentation/grow-and-monetize/monetization/fulfill-a-privacy-access-or-export-request.md) when the requester needs a protected data package.


---

# 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 dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.podigee.com/documentation/grow-and-monetize/monetization/grant-temporary-sensitive-access.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

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.