Explainable deny for SOC 2 access reviews: why evidence matters

At a glance

What this is: This is an analysis of why application authorization needs decision provenance so access reviews can prove both explainable allow and explainable deny.

Why it matters: It matters because IAM, IGA, and PAM teams cannot demonstrate effective least privilege, tenant scoping, or break-glass governance if authorization decisions are not auditable at the application layer.

By the numbers:

• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes.

👉 Read PermitIO's explanation of decision provenance for SOC 2-style access reviews

Context

Application authorization is the control that decides whether a specific user, service, or agent can perform a specific action on a specific resource. In SOC 2-style reviews, the hard part is not proving that someone authenticated, but proving why the application allowed or denied the request in the first place. That is the evidence gap PermitIO is addressing in its discussion of explainable deny and decision provenance.

This matters across human IAM, NHI governance, and agentic workflows because review teams need more than IdP logs or role lists. They need a traceable link from identity to policy to enforcement point, especially when access is tenant-scoped, exception-driven, or delegated to an AI agent. For related identity lifecycle framing, see the NHI Lifecycle Management Guide.

The article also points to a wider pattern in modern application security: authorization is often split across code, UI checks, database filters, and support workflows. When that happens, access review becomes a reconstruction exercise rather than a control test, which is atypical for mature programmes but common in fast-growing SaaS environments.

Key questions

Q: What breaks when application authorization is not explainable in access reviews?

A: Access reviews become inferential instead of evidential. Reviewers can see that a user authenticated or holds a role, but they cannot prove why a specific tenant or resource action was allowed or denied. That leaves least privilege, break-glass, and SoD controls difficult to certify under SOC 2-style scrutiny.

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. They let teams show that a sampled access path was evaluated against the right policy version and enforced at the right point. That makes the review about observed control operation, not just intended design.

Q: Why do AI agents complicate authorization evidence?

A: Because the request path now includes a human, an agent, a tool, and a resource. If the evidence stops at the human, the programme cannot show whether the agent acted within delegated scope or became a privilege amplifier. That is why delegation and tool-level provenance matter.

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.

Technical breakdown

Why IdP logs are necessary but incomplete for authorization evidence

Identity provider logs can show who signed in, whether MFA succeeded, and when accounts were suspended or deprovisioned. They do not normally prove why a given application decision allowed access to one tenant and denied another. That difference matters because authentication answers who the subject is, while authorization answers what that subject may do in a specific context. If the application cannot emit decision provenance, auditors and reviewers are left inferring control effectiveness from indirect evidence. Practical models need subject, action, resource, policy version, and enforcement point in the same record.

Practical implication: treat IdP logs as supporting evidence and require application-level decision logs for sampled access reviews.

Decision provenance in allow and deny outcomes

Decision provenance is the record of how a policy engine reached an allow or deny result. A useful record includes the requester, action, resource, tenant, policy version, matched rule, context, and enforcement point. This is not verbose logging for its own sake. It is the minimum shape needed to show that least privilege, separation of duties, and tenant boundaries were actually enforced at runtime. Mature authorization evidence must show both that legitimate requests were permitted and that out-of-scope requests were blocked for a clear reason.

Practical implication: standardise decision logs so every allow and deny can be explained without reconstructing application code.

Why AI agents raise the bar for authorization traceability

When a human delegates work to an AI agent, the request path becomes human, agent, tool, then resource. That adds a second subject to the evidence chain and creates a new audit problem if the agent can act beyond the human's original permissions. Explainable deny at the tool boundary is therefore essential. If the agent can invoke tools or resources that the initiating user could not reach, the control model has quietly turned the agent into a privilege amplifier. The evidence must show which delegation existed, which tool was invoked, and why the action was allowed or denied.

Practical implication: log human-to-agent delegation separately from tool authorization so agent actions remain bounded and reviewable.

Breaches seen in the wild

• FIRST — Forum of Incident Response and Security Teams — incident response standards and CSIRT coordination practice
• Indian Government Breach — Indian government systems breach exposes sensitive credentials and citizen data.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Authorization fragmentation creates an evidence problem before it becomes an access problem. When policy lives in code, UI checks, database filters, and exceptions, no single system can explain the final decision cleanly. The result is control drift that is hard to sample, hard to certify, and even harder to investigate after the fact. This is a governance failure as much as a technical one.

Agentic workflows force IAM teams to extend decision provenance beyond the human user. Human identity, NHI-style tool access, and delegated agent behaviour now intersect at the same enforcement point. If the evidence chain stops at the person and ignores the agent or tool, the programme cannot explain privilege propagation. That means access reviews, break-glass controls, and audit evidence all need to follow the delegation chain, not just the user directory.

Decision logs should be treated as a control outcome, not an observability bonus. Mature programmes do not ask whether they can produce logs after something goes wrong. They design policy, enforcement, and retention so the log itself demonstrates how policy operated. For IAM, IGA, and PAM leads, that shifts authorization from a development concern to a governed evidence layer.

The named concept here is explainable deny. That is the ability to show why the system refused an action, not only why it approved one. In SOC 2-style environments, a deny record is often more persuasive than an allow record because it proves the boundary held. Practitioners should treat that as a core part of authorization design, not an afterthought.

From our research:

• 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.
• Decision provenance gaps tend to surface where lifecycle governance and access evidence meet, which is why the NHI Lifecycle Management Guide is the right next step for teams formalising review and revocation.

What this signals

Explainable deny will become a practical requirement, not an advanced feature, as audit teams push deeper into application-layer evidence. Identity programmes that stop at the IdP will keep struggling to answer simple questions about tenant-level access and scoped actions. Teams should expect access review design to move closer to policy engine telemetry and away from static entitlement exports.

Decision provenance is the named concept that will separate reviewable systems from merely functional ones. Once human-to-agent-to-tool paths become common, the evidence chain has to include delegation, enforcement, and denial at the same granularity as approval. That is where IAM, IGA, and PAM governance start to converge.

Even in mature environments, access review quality is often limited by fragmented authorization architecture rather than missing policy intent. The practical signal for programme owners is whether they can reconstruct a sampled decision without reading source code, which is a far sharper test than a role review alone.

For practitioners

• 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. Make this the canonical format for sampled access reviews and incident investigation.
• 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. Do not rely on SSO or MFA records to prove least privilege.
• 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. This preserves traceability when access is passed through an AI intermediary.
• Review break-glass and exceptions as governed evidence Track who approved elevated access, what scope was granted, how long it lasted, and whether post-use review occurred. Hidden exceptions are where authorization evidence usually fails.
• Align access review samples to runtime decisions Choose sampled users, tenants, and sensitive actions that can be traced from approval through execution and revocation. Pair the review with the actual decision log rather than a role export alone.

Key takeaways

• SOC 2-style access reviews fail when teams cannot explain why a specific action was allowed or denied at the application layer.
• Decision provenance turns authorization from inferred compliance into observable control operation, which is what reviewers actually need.
• AI agents raise the evidence bar because delegation, tool use, and enforcement all need to be traceable end to end.

Key terms

• Decision Provenance: Decision provenance is the ability to explain what signals, data, and reasoning context led to a system’s choice. For autonomous or agentic systems, it is critical because review teams need to know not only what happened, but why the decision was made and where human authority still applies.
• Explainable Deny: Explainable deny is the ability to show why a request was refused, not only why another request was permitted. It matters because a denied action proves a security boundary held and gives auditors stronger evidence than a simple role assignment or login record.
• Application Authorization: Application authorization is the process that determines whether a subject can perform a specific action on a specific resource under defined conditions. It sits after authentication and before execution, and it becomes easier to govern when policy rules are centralised, testable, and tied to the application’s actual resource model.
• Delegated Agent Authority: The permission granted to an AI agent to act on behalf of a human user or another agent, inheriting some or all of their access rights. Delegated authority must be explicitly scoped, time-limited, and auditable.

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.

👉 PermitIO's full post shows how to assemble authorization evidence that stands up in review and investigation.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM, PAM, or identity governance programme, it is worth exploring.