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.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on PermitIO's blog post: Access reviews need authorization evidence, not just authentication logs, to prove who could do what in an application.
Why it matters: It matters because IAM and IGA teams need evidence that application-level permissions, tenant boundaries, and deny decisions are auditable under review, not merely that users logged in.
Context
Authorization review breaks down when teams can prove identity but not decision. In a SOC 2-style access review, the question is not only whether a user logged in with MFA, but whether the application allowed a specific action on a specific tenant or resource for a policy reason that can be inspected later.
That gap shows up when authorization logic is fragmented across code paths, support tooling, database filters, and exceptions. For IAM, IGA, and application security teams, the operational problem is evidentiary: access may work correctly, yet still be impossible to defend during audit or incident review.
The article frames explainable deny as the missing half of access evidence. A valid control story must show both why access was allowed and why unauthorized access was denied, especially when customer data, privileged roles, or delegated agent actions are in scope.
Key questions
Q: What breaks when access reviews rely only on IdP logs?
A: They cannot prove why an application allowed or denied a tenant- or resource-level action. IdP data shows identity events such as login and MFA, but it does not explain policy evaluation, resource scope, or the boundary that held. That leaves reviewers with authentication evidence but incomplete authorization evidence.
Q: Why is decision provenance important for SOC 2-style access reviews?
A: Because reviewers need a traceable chain from requester to policy to result. Decision provenance shows who made the request, what resource was targeted, which policy version was evaluated, and why the system allowed or denied it. That is the difference between describing a control and proving it operated effectively.
Q: What are the signs that authorization evidence is too weak for audit?
A: The usual signs are scattered rule logic, unexplained exceptions, missing policy versions, and an inability to reconstruct a sampled decision without asking engineers to interpret code. If the team can show login events but not the access rationale, the evidence model is incomplete.
Q: How should security teams handle delegated access when AI agents act on behalf of customers?
A: Security teams should treat delegated access as a separate governance layer, not as a normal login session. Define what the agent can do, how much value it can move, which approvals are required, and how delegation is revoked. Without those boundaries, the agent inherits more authority than the customer intended and fraud risk expands quickly.
Technical breakdown
Why IdP logs are necessary but incomplete for authorization evidence
Identity provider logs prove that a subject authenticated, met MFA, joined a group, or was deprovisioned. They do not prove why an application permitted a tenant-specific action, because authorization is evaluated at the resource and policy layer, not at the login layer. In practice, the gap widens when app logic, support workflows, and break-glass paths all affect the final decision. That is why authentication evidence answers who signed in, while authorization evidence answers why the action was allowed or denied.
Practical implication: treat IdP logs as supporting evidence, not as proof of application-level least privilege.
Decision provenance and explainable deny
Decision provenance is the record of how a request moved from subject and action to policy evaluation and final result. A useful record includes the requester, resource, tenant, policy version, matched rule, enforcement point, timestamp, and outcome. Explainable deny is the same concept applied to rejected actions, which is often more valuable during audit because it proves a boundary actually held. Without that chain, teams can describe intended policy but cannot evidence runtime enforcement.
Practical implication: log the policy reason and enforcement point for both allow and deny outcomes.
Human to agent to tool paths change the evidence model
When AI agents sit in the request path, the access model becomes human to agent to tool to resource. That does not reduce the need for authorization evidence. It increases it, because reviewers must know which human delegated the task, which agent acted, which tool was invoked, and whether the action remained within delegated scope. If the agent can amplify privilege beyond the initiating user, the evidence model has already failed even if the login was legitimate.
Practical implication: extend authorization logging to the delegated actor chain, not just the human session.
NHI Mgmt Group analysis
Authorization evidence is now a control requirement, not a logging nice-to-have. Access review programmes fail when they treat identity proof as sufficient proof of access control. The article shows that reviewers need decision provenance because control effectiveness is judged at the point of authorization, not at login. Practitioners should treat application-level decision records as part of the evidence package, not as optional telemetry.
Explainable deny is the stronger audit signal. Mature programmes must be able to show both permitted access and blocked access for the right reason. A deny record proves boundary enforcement, which is often more defensible than a long list of successful logins. The practitioner implication is clear: if the boundary cannot be explained, the control cannot be trusted under review.
Decision logic scattered across code is an audit debt pattern. When permissions live in application code, UI checks, support workarounds, and database filters, the review burden shifts from verification to reconstruction. That makes SOC 2-style evidence expensive and fragile. Teams should recognise this as a governance smell: fragmented authorization is not just hard to maintain, it is hard to prove.
Human-delegated agent actions need the same provenance discipline as direct user actions. Once an AI agent can invoke tools on behalf of a person, the access question expands from authentication to delegation scope. That means authorization evidence must include the human, the agent, the tool, and the resource touched. Practitioners should assume that delegated execution without traceable provenance is a governance gap, not an implementation detail.
Decision provenance is the named concept that best captures this control gap. It defines the chain from requester to policy to outcome, and it is what reviewers actually need when they ask why a tenant action was allowed or denied. The implication for practitioners is to make provenance a first-class governance object, because evidence without provenance is only partial evidence.
From our research library:
- Over 70% of organisations lack automated access risk analysis, user access reviews and provisioning and deprovisioning, according to Pathlock's 2025 Digital Transformation and Access Risk Report.
What this signals
Decision provenance is becoming the auditable unit of authorization. Teams that still centre access reviews on login evidence will keep missing the actual control question, which is why an action was allowed or denied. The programme shift is from identity proofing to evidence of enforcement.
Application authorization has to be reviewable as a lifecycle control. If policy lives only in code paths and exception handling, review, revocation, and investigation all become reconstruction exercises. That is a governance problem for IAM, IGA, and PAM teams, not just an engineering inconvenience.
For practitioners
- Document decision provenance fields Define the minimum authorization record for every sensitive action: subject, action, resource, tenant, policy version, matched rule, enforcement point, timestamp, and result. Keep the schema stable enough that audit sampling can be answered without code archaeology.
- Separate authentication evidence from authorization evidence Map which logs prove login and which logs prove allow or deny decisions. Use that split to identify where your current review pack relies on IdP data that cannot explain application-level access.
- Capture deny decisions as audit evidence Retain denied requests for sensitive actions, including the policy reason and the exact boundary that blocked the request. Reviewers often learn more from a clean deny trail than from a long list of successful access events.
- Trace delegated agent requests end to end For AI-mediated workflows, record the initiating human, the agent identity, the tool used, and the policy decision that constrained the action. Treat delegated scope as part of the access review, not as separate runtime noise.
- Consolidate authorization logic into reviewable policy Reduce hidden decision paths in application code and support exceptions by centralising policy definitions and versioning changes. This makes sampled access decisions easier to explain during SOC 2-style review and internal investigation.
Key takeaways
- Access reviews become difficult when teams can prove authentication but not authorization decisions.
- Decision provenance ties identity, policy, resource, and result together in a form auditors can use.
- Delegated agent actions expand the evidence chain and make traceable authorization logs essential.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | The article contrasts authentication logs with missing authorization evidence. |
| NHI-10 — Human Use of NHI | The article includes human-to-agent-to-tool delegation paths that affect access evidence. | |
| Recommendation — Separate authentication proof from authorization proof in your evidence model. Record delegated human and agent actions as one auditable authorization chain. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The core issue is proving that access permissions were enforced as intended. |
| Recommendation — Validate that access decisions are logged with enough detail to evidence entitlement enforcement. | ||
| NIST SP 800-53 Rev 5 | AU-3 — Content of Audit Records | The article defines the fields needed in decision logs and audit evidence. |
| Recommendation — Capture policy, subject, resource, result, and enforcement context in audit records. | ||
| MITRE ATT&CK | TA0006;TA0040 — Credential Access; Impact | The analysis is about how opaque authorization can conceal access and hinder response. |
| Recommendation — Map hidden access pathways to credential and impact tactics in your detection and review process. | ||
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.
- Authorization Evidence: Authorization evidence is the documented proof that a system meets security and compliance requirements before and during operation. For AI agents, evidence must extend beyond platform certification to show behavioural controls, monitoring coverage and containment for runtime actions.
- Delegated Scope: Delegated scope is the set of actions and resources a receiving agent is allowed to use on behalf of the originating actor. Effective scope should be narrower than the agent's raw capability and must be checked at every handoff, not just at session start.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle 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 or identity governance programme, it is worth exploring.
Published by the NHIMG editorial team on September 16, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org