Resource hub · Compliance and GRC
Authorization evidence for compliance and GRC teams
Auditors no longer settle for a screenshot of the identity provider. They want to know who could reach which record, why a request was allowed, and whether that is still true today. AI agents add a new question: what did the agent do, and on whose behalf?
These are the Permit resources we point GRC teams to when they need to turn application access into evidence. Permit is SOC 2 Type II attested. Tooling does not make an organization compliant, but good decision logs make the evidence much easier to produce.
Problems this page helps with
- Producing access review evidence at the application level, not just at login
- Explaining why a specific access was allowed or denied
- Mapping AI agent activity to SOC 2, ISO 27001, ISO 42001 and the EU AI Act
The short version
Auditors want application level evidence: who could access which record, which policy allowed it, and whether that still holds today. Decision logs that tie identity, policy and resource together make that evidence easy to produce.
Key concepts
Decision logs
A record of every allow and deny, with the user, the action, the resource and the policy that decided it.
Explainable deny
Being able to say why a request was blocked, not just that it was. Auditors often ask for this.
Access reviews
Periodic proof that each role and relationship is still needed. Role, attribute and relationship models each prove something different.
Agent accountability
For AI agents: which human delegated the task, what the agent did, and whether policy allowed it.
From access decision to audit evidence
- 1
Request
a user or agent asks to act on a record
- 2
Policy decision
evaluated against the current policy
- 3
Decision log
identity, policy, resource, outcome
- 4
Evidence
SOC 2, HIPAA, GDPR, ISO 27001
What auditors see
Login level evidence only
- IdP screenshots and group exports
- No trace of what happened inside the app
- Agent actions blend in with the user who started them
Application level decision trail
- Every allow and deny tied to a named policy
- Filterable logs for a specific user, record or period
- Agent actions attributed to the agent and the delegating human
How Permit handles it
- 01
Log every decision
As shared in our docs, Permit records each permission check with the user, resource, action, decision and the policy behind it, and lets you filter the log for an investigation.
- 02
Let business owners manage access
Access requests and approvals happen inside the product, so the approval trail is part of the record instead of an email thread.
- 03
Govern AI agents
Permit MCP Gateway gives each agent its own identity, checks every tool call against policy and records consent and outcome.
- 04
A vendor that passes review
Permit is SOC 2 Type II attested. Tooling does not make you compliant, but it makes the evidence far easier to produce.
“Permit gives us the power and flexibility we need to manage complex permissions configuration across hundreds of projects, while maintaining the high level of security needed by our clients at the US Department of Energy. I highly recommend this technology for anyone who doesn't want to waste time reinventing the wheel on authorization.”
Go deeper
Audit trails that answer "why"
- BlogBest practices for authorization audit logsWhat an authorization audit log should capture and how it supports security reviews.
- BlogWhy was this allowed?How to build an audit trail that records the policy and data behind each allow or deny decision.
- BlogAI agent audit logs: 12 fieldsA field-by-field checklist for logging AI agent tool calls so they hold up in a review.
- DocsAudit log types and filteringWhat Permit records for every decision and how to filter it for an investigation.
Access reviews and audit frameworks
- BlogExplainable deny for SOC 2-style access reviewsWhy decision logs that trace identity to policy to resource make application access controls concrete for auditors.
- BlogLeast privilege evidence by modelHow role assignments, attribute conditions and relationship tuples each prove something different in an access review.
- GuideSOC 2 CC6 and ISO 27001 checklist for AI agentsWhich access control assumptions AI agents break, and the evidence to produce for each control.
- BlogNIST NCCoE focus areas mapped to authorization controlsA cheat sheet that maps identification, authorization, delegation and logging to concrete controls.
AI governance
- BlogEU AI Act logging requirementsArticle 12 logging, the six-month retention rule for deployers, and how ISO 42001 lines up with both.
- GuideISO 42001 certification guideWhat the AI management system standard asks for, how the audit stages work, and where agent evidence fits.
- BlogAI agent audit trailHow to bind identity, delegation, policy and outcome into one record that a reviewer can follow.
- ProductAI compliance explorerA browsable map of AI regulations and the access control obligations they create.
Healthcare and regulated industries
- BlogReviewing an MCP gateway for SOC 2 and HIPAAA review guide for security, privacy and procurement teams, with concrete examples from Permit MCP Gateway.
- Case studyHow HippHealth secures patient dataA healthcare team that externalized fine-grained authorization to protect patient records.
- ProductPermit for healthcareHow Permit protects patient data in healthcare apps.
- ProductPermit trust centerSecurity documentation, including our SOC 2 Type II attestation.