Notifications
Clear all
Topic starter
16/09/2026 9:21 am
TL;DR: SOC 2-style access reviews are difficult when IdP logs prove login but not why an application allowed or denied a specific tenant or resource action, according to PermitIO. The practical issue is authorization evidence, not authentication evidence, because reviewers need decision provenance that links identity, policy, resource, and result.
NHIMG editorial — based on content published by PermitIO: Explainable Deny: Authorization Decision Evidence for SOC 2-Style Access Reviews
By the numbers:
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes.
Questions worth separating out
Q: What breaks when application authorization is not explainable in access reviews?
A: Access reviews become inferential instead of evidential.
Q: How do decision logs help with SOC 2-style access reviews?
A: Decision logs connect identity, policy, resource, and outcome in a single record.
Q: Why do AI agents complicate authorization evidence?
A: Because the request path now includes a human, an agent, a tool, and a resource.
Practitioner guidance
- Define the evidence shape for every authorization decision Require subject, action, resource, tenant, policy version, matched rule, enforcement point, and outcome in one decision record.
- Separate authentication evidence from authorization evidence Keep IdP logs for identity proofing and session history, but add application-level decision logs for allow and deny outcomes.
- Map delegation chains for AI agent use cases Record which human initiated the task, which agent acted, which tool was invoked, and which policy governed the tool call.
What's in the full article
PermitIO's full blog covers the operational detail this post intentionally leaves for the source:
- A practical decision-log schema for allow and deny outcomes that teams can adapt to production authorization systems.
- Examples of evidence packs for SOC 2-style access reviews, including grant, review, revoke, and exception handling.
- How Permit.io structures policy, PDP, and OPAL flow for explainable authorization in real applications.
- Guidance on using debug mode for development without confusing it with production evidence handling.
👉 Read PermitIO's explanation of decision provenance for SOC 2-style access reviews →
Explainable deny and access review evidence: are your controls auditable?
Explore further
16/09/2026 9:21 am
Explainable deny is becoming the missing control surface in application authorization. Most teams still treat authentication evidence as if it were authorization evidence, which is why access reviews turn into manual archaeology. In reality, reviewers need a runtime record of the decision, not just a record of the login. That is the difference between asserting least privilege and proving it under audit.
A few things that frame the scale:
- The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
A question worth separating out:
Q: Should organisations keep IdP logs and authorization logs separate?
A: Yes. IdP logs prove authentication, account state, and session events, while authorization logs prove why an application allowed or denied a particular action. Keeping them separate avoids false confidence and gives auditors the evidence they actually need for access-control testing.
👉 Read our full editorial: Explainable deny for SOC 2 access reviews: why evidence matters
