Review Secret access and follow up safely¶
Use this guide to understand the intended Secret access experience in Tenant Admin. It is based on current 06 Final Screens and implemented backend rules. The frontend is still in progress; these steps apply when the corresponding screens are delivered. The current design does not provide a complete creation form.
Before you begin¶
Confirm the workspace, exact information needed and the person or governed group involved. Prepare the business purpose, a justification or decision reference, and an appropriate start and end time. Use your organization's authorized channel for sensitive details.
Your account needs the applicable HiveAI access and governance permissions. Changing a grant additionally requires organization-head or delegated tenant-administrator authority. View-only access does not permit changes. The person receiving access must meet the current identity and source-access requirements; an external participant is not automatically eligible for a workforce-backed grant.
If HiveAI says it has not granted access, treat that as guidance to seek an authorized decision. A conversational request is not a saved exception.
Find current access¶
- In the intended Tenant Admin experience, open Secret access in the Settings area.
- Choose Refresh to read the current list.
- Review the person, Secret source and access end time.
- Choose View on the relevant row.
- If Show more is available, use it to inspect the next portion of the active list.
The full Settings-to-Secret-access navigation is not implemented in the inspected frontend. Do not substitute another settings page or assume a direct product link exists.
The list contains active grants within your permitted scope. Its displayed count describes what is shown, not all grants ever made. New decisions, expiry and revocation can change the list while you browse. Refresh before relying on an earlier result.
Read a known decision¶
On the detail screen, check:
- Who has access or Who had access, including any warning that the current name could not be confirmed.
- The exact information and Secret classification.
- Why access was granted and its justification.
- The start and end of the access window.
- Who granted the decision and, when shown, why access ended.
A name marked as checked when granted is historical evidence. Do not infer that it is a current identity check. If the person or source cannot be identified confidently, obtain authorized clarification before making a change.
A known record may show Starts later, expired access or revoked access even though it is absent from the active list. Keep the record reference where your organization permits it.
Handle missing access scope¶
- Choose Grant access only if it is available to your role.
- If the setup screen says an exact person or group and Secret source must be confirmed first, return to the relevant work context.
- Identify the exact recipient and information, purpose, justification and time window with an authorized administrator.
- Continue only when a supported preparation flow supplies those details for review.
The inspected setup screen has no person picker or source picker. This guide cannot supply selection steps that are not designed or implemented. The HiveAI handoff provides explanatory text; the inspected examples do not expose a working Tenant Admin handoff button.
Review a prepared grant¶
This is a conditional journey: use it only when a supported flow has prepared the exact details and opens Review Secret access.
- Check the named person or governed group and the exact source.
- Check the purpose and justification.
- Check both the start and end time, including the displayed time zone.
- If anything is wrong, use Back to details. Do not confirm a broader or ambiguous grant.
- If you have the required authority and the details are correct, choose Grant access.
- Read the saved record and confirm its recipient, source and access window.
The sample review says access takes effect immediately. That applies only when the access window has already begun. A future-start decision becomes usable no earlier than its start, and only while the remaining checks pass.
This decision does not include a separate enforced second-person approval stage. Organizations needing independent review must arrange it explicitly. A management integration can save a grant without proving that the underlying source is available, so successful creation is not a successful information-access test.
Revoke active access¶
- Open and refresh the exact active record.
- Choose Revoke access if the action is available.
- Enter the reason and decision reference on the revocation screen.
- Choose Review revocation.
- Verify the recipient, source, original end time, reason and reference.
- Use Back to access details if you need to reconsider. Otherwise choose Revoke access.
- Read the resulting record and confirm that access is shown as revoked.
Revocation ends this exception. It cannot restore the same grant afterward and does not erase history. Other independently authorized access may still exist.
The current future-start detail does not offer revocation, and the backend rejects revocation before the start. Escalate an incorrect future grant to an authorized administrator for resolution; this guide does not promise a cancellation control. Expired and revoked records have inspection screens, without a verified renewal or restore journey.
Recover an uncertain or changed decision¶
If the screen says the outcome could not be confirmed:
- Keep the original record or action reference.
- Use Refresh this access record when available.
- Read the current decision before attempting another change.
- If it now reflects your decision, use that result.
- If it remains unavailable or ambiguous, contact authorized support with the reference and approximate time.
A failed response can follow a successful save. Refreshing must read the record; it must not submit the change again.
If a creation response was lost before you received a record reference, the active list may not recover it, particularly for a grant that starts later. Report the uncertainty rather than submitting a new grant on the assumption that nothing happened.
If the screen says Access changed, refresh and review the new state. An earlier review is no longer a reliable basis for the next decision. For a conversational action, follow the original action's recovery guidance, keeping its identity rather than creating a replacement request to bypass uncertainty.
Interpret empty, loading and unavailable views¶
| What you see | What to do |
|---|---|
| Checking current access | Wait for the read to finish; there is no confirmed result yet |
| No active access | Check your scope and remember that future and ended grants are omitted |
| Current list unavailable | Use Try again or Refresh before deciding who currently has access |
| Known record unavailable | Return to the active list or try again; the record may be outside your scope or temporarily unavailable |
| View-only access | Inspect permitted records; ask an authorized decision maker to handle a change |
| Current name could not be confirmed | Treat the saved name as historical and establish the current identity before acting |
An unavailable record does not prove that it never existed. An empty view does not grant permission to create a replacement.
When a grant exists but information remains unavailable¶
Check the exact recipient, source, purpose and time window with the administrator. A group grant requires current eligible membership. Source permissions, organizational scope, classified-service approvals, current licensing and operational controls may still block use.
Do not widen the grant, change classification, borrow another person's identity or paste the source into an unapproved channel to work around a refusal. The administrator should establish which requirement is unmet and follow the authorized process.
Managers and executives should confirm the business need and accountable decision maker. Support and platform staff should help investigate the specific outcome without assuming their own role confers access to the protected information.
Keep decision history distinct from deletion¶
Revocation and expiry stop eligibility under the exception. They do not delete the grant's history, the original information or copies already lawfully obtained. Conversation deletion and removal of personal memory are separate actions. Ask your organization's responsible administrator about applicable retention or erasure requests rather than using revoke as a deletion control.
Give support useful context¶
Provide the workspace, visible outcome, record or original action reference, approximate time, whether you were reading/granting/revoking, and the last confirmed result. Include a time zone when discussing start or end times. Share names, source details and justification only through an authorized channel.
The initial documentation reviewer should test whether the recipient, purpose, time window, decision authority and next step are understandable in the active, future, expired, revoked, view-only and unconfirmed scenarios. These walkthroughs are still pending; a documented journey is not evidence that a reader has successfully completed it.
