Protect named resources
Set access for a particular workflow, case, knowledge store, model deployment, connection or other governed resource.
Access governance
A broad role can be useful, but it rarely tells the whole story. Pūnaha lets you control access to named resources and exact actions, then explain the roles, groups, assignments and denials behind the final decision.
Access with context
Control can be specific without becoming impossible to manage.
Set access for a particular workflow, case, knowledge store, model deployment, connection or other governed resource.
Separate actions such as viewing, changing, publishing, running and administering instead of treating access as all or nothing.
Grant access to an individual, a local or external group, or a service identity used by another part of the platform.
Start access on a chosen date, let it expire automatically, or remove it when the work changes.
A deny takes precedence when a person or service must not use a resource, even if another assignment would normally allow it.
Inspect the final access decision and the assignments that contributed to it before trying to diagnose a problem from the outside.
From request to review
Start with what the person or service needs to do, not with the broadest role available.
Use a person, local group, external identity group or service identity that matches how the work will actually run.
Review the complete result, including role access, grants, denials and time limits.
Apply the decision when the resource is opened or used, with the explanation available for investigation.
Ask the responsible reviewer to keep, change or remove access and retain an exportable record of the review.
Delegated administration
The person responsible for access does not always need permission to open or run the protected resource.
Pūnaha can separate the right to manage access from the right to use the resource. That makes it possible to give an access manager a focused responsibility without quietly widening their operational access.
The same principle supports formal reviews. A reviewer can see who has access, why they have it and whether it should remain, then record a keep, change or remove decision.
Distinguish access administration from resource use.
Show the role, group, grant, denial and timing behind effective access.
Export review results in CSV or JSON for the organisation's own assurance process.
What to evaluate
| Question | What Pūnaha provides | What your team decides |
|---|---|---|
| Who needs access? | People, local groups, external groups and service identities | The appropriate subject and accountable owner |
| Access to what? | Named resource types and individual resources | The scope needed for the work |
| What may they do? | Exact resource actions and delegated administration | The least access that remains practical |
| For how long? | Immediate, scheduled and expiring assignments | The start, end and review timing |
| Why was it allowed or denied? | An explainable effective-access decision | How the evidence fits your assurance process |
No. The responsibility to manage access can be kept separate from permission to view, change or run the resource.
The explicit deny takes precedence. The effective-access view explains the assignments considered in the decision.
Yes. A formal review can present current access for a keep, change or remove decision, with results available for export.
No. Pūnaha provides access controls and review evidence. Each organisation still decides how those capabilities support its policies, assurance work and regulatory obligations.
We can follow it from the person or service to the protected resource, the final decision and the evidence available for review.