Claude compliance data now sits inside identity governance workflows

At a glance

What this is: This is a C1.ai integration post about bringing Claude activity logs into identity governance so access, approvals, and usage evidence sit together.

Why it matters: It matters because IAM teams now need governance models that can certify and revoke AI usage based on actual activity, not just entitlement state.

👉 Read C1.ai's analysis of Claude activity logs in identity governance workflows

Context

Traditional identity governance assumes entitlements are the primary object of control, with activity treated as something you inspect elsewhere after the fact. That model breaks down when an AI platform is used in day-to-day work and produces a conversational activity trail that is part of the governance record.

In this post, C1.ai argues that Claude Enterprise and the Claude Platform need both an identity layer and an activity layer. The operational question is no longer only who can access Claude, but what the user or agent did with that access and whether the resulting evidence belongs inside the same governance workflow.

Key questions

Q: How should teams govern AI-agent access during an identity platform move?

A: Treat AI agents as governed identities with named owners, explicit permission scope, and lifecycle checks before they are used in discovery, testing, or rollout. Their access should be validated like any other non-human identity, with clear boundaries for what they can inspect or change. If that governance is missing, the migration toolchain itself becomes part of the risk.

Q: When should organisations revoke AI project access?

A: Organisations should revoke AI project access when a contractor leaves, a pilot ends, a role changes, or an identity is no longer needed to operate the workflow. Waiting for periodic cleanup leaves stale access active and makes least privilege mostly theoretical.

Q: Why do user access reviews miss the real risk from AI agents?

A: They only test the user’s direct entitlements, not the broader actions the user can trigger through an agent. If the agent holds wider privileges in finance, ERP, or operations, the effective access is much larger than the review shows. That is why auditors need to examine delegated execution paths, not just the human account.

Q: Why do AI governance workflows need both identity records and activity logs?

A: Because permission alone does not prove accountable use. Identity records tell you who was authorised, while activity logs tell you what happened after access was granted. Bringing both together closes the gap between entitlement and evidence, which is where AI governance failures often start.

How it works in practice

Why identity records alone are not enough for Claude governance

Identity governance platforms traditionally model joiner, mover, leaver state, group membership, role assignment, and access approval. That is sufficient when the main control question is whether a person or service account should still hold a permission. Claude usage introduces an activity stream that includes logins, admin actions, configuration changes, and other evidence that explains how access is being used in practice. Without that activity context, reviews tend to assess entitlement state in isolation, which is useful but incomplete when the system itself is part of the workflow.

Practical implication: govern AI access with activity evidence attached to the identity record, not with entitlement reviews alone.

How activity logs change access reviews and audit evidence

Once Claude activity data is available in the same governance layer as identity records, access reviews can be based on actual usage rather than simple seat counts or static membership lists. That matters because review cycles become more defensible when they show who accessed the platform, what they did, and whether that activity matched the stated business purpose. For auditors, the evidence chain now spans request, approval, and use. For governance teams, that reduces the gap between authorization and demonstrated need.

Practical implication: redesign review workflows so unused AI access and unexplained activity are both visible before certification closes.

What changes when AI access behaves like an identity governance problem

The article treats Claude access as an identity governance issue because the platform includes human users, API keys, and agent activity that all need lifecycle treatment. That means access assignment, revocation, and evidence collection are no longer separate disciplines. The governing control surface becomes the full lifecycle of access plus the observable activity that follows it. In practice, this is closer to IAM and lifecycle governance than to a standalone application dashboard, because the risk comes from stale access, unreviewed activity, and inconsistent offboarding.

Practical implication: treat AI platform access as governed lifecycle state with revocation and evidence capture built into the same process.

NHI Mgmt Group analysis

AI governance fails when usage evidence lives outside the identity record: C1.ai's core point is that Claude activity cannot be governed safely as a separate telemetry problem. Identity records answer who was entitled, but they do not explain what was done with that entitlement. The implication is that identity governance for AI platforms now has to absorb activity evidence as a first-class control input.

The named concept here is activity-backed identity governance: access decisions for AI platforms are only defensible when the entitlement and the usage trail are joined. That is a structural shift from traditional SaaS governance, where the access record often carries most of the weight. Practitioners should expect review quality to improve only when the activity layer is fed into the same certification and offboarding workflow.

Claude is a reminder that AI platforms create mixed governance pressure across human and non-human identities: the same control plane must handle human users, API keys, and agent-like usage patterns without fragmenting evidence. That makes lifecycle consistency more important than the label attached to the identity. Teams should re-evaluate whether their IAM and IGA processes can trace access, use, and revocation across all three.

Audit readiness for AI now depends on proving purpose, not just permission: regulators and internal auditors increasingly want to know what happened after access was granted. If the governance workflow cannot tie approval to the activity that followed, the organization is left with a partial story. The practical conclusion is that AI access review must be built as an evidence chain, not a seat inventory.

This is less about monitoring volume and more about closing the gap between authorization and accountability: unusual usage only matters if it can be tied back to the identity that owns it and the role that justified it. C1.ai is pointing to a governance model where lifecycle actions and activity logs reinforce each other. Practitioners should treat that as the baseline for AI-era access governance.

What this signals

Activity-backed identity governance: AI platforms force IAM teams to move beyond seat-based control and into evidence-based certification. When the system used for work also generates the usage trail, governance has to join entitlement, approval, and activity before review decisions can be trusted.

The practical shift is from managing access lists to managing accountability chains. That change affects human users, service-style API keys, and agent-like usage patterns in the same control plane, which is why AI platform governance belongs inside identity operations rather than beside them.

For practitioners

• Align AI access reviews to actual usage Separate active Claude users and agents from dormant ones, then certify only the access that still maps to a current business purpose. Use activity evidence alongside group membership and role assignment so review decisions reflect real use, not just entitlement existence.
• Tie AI activity back to the owning identity Require every Claude Platform API key and admin action to resolve to an accountable identity, role, and approval trail. When usage spikes or looks unusual, the reviewer should see who owns it, what it can do, and whether the access still matches the task.
• Fold AI offboarding into the same lifecycle workflow Remove Claude seats, API access, and admin permissions as part of standard leaver and project-end handling, not as a separate cleanup step. The goal is to prevent access from surviving after the project, role, or business need has ended.
• Build audit trails that include approval and use Preserve the access request, the approval decision, and the subsequent activity record in one evidence chain. That gives auditors a complete view of who received access, why it was granted, and what was done with it.

Key takeaways

• Claude governance is changing because identity data alone no longer explains AI platform use, and activity logs now matter as much as access state.
• The article's core operational point is that access reviews, audit trails, and offboarding become more defensible when approval and usage are evaluated together.
• For practitioners, the control gap is not visibility in general but the absence of a single workflow that ties entitlement, activity, and lifecycle removal together.

Key terms

• Activity-Backed Identity Governance: A governance model that evaluates access using both entitlement state and observed activity. For AI platforms, this means the identity record, approval trail, and usage evidence must be reviewed together so teams can justify why access exists and what happened after it was granted.
• AI Access Certification: A periodic review process that decides whether AI platform access should remain in place. In practice, it should combine who is entitled, what they did, and whether the access still matches a current business purpose, rather than relying on static seat counts alone.
• Lifecycle Offboarding: Lifecycle offboarding is the process of removing an identity when it is no longer needed or no longer under the original owner’s control. In NHI programmes, it applies to service accounts and integrations as well as people, and it is essential for preventing stale access from surviving ownership changes.
• Usage Evidence: Data that shows whether a user or group is actively using a subscription often enough to justify keeping it. It can include login frequency, feature adoption, or recent activity. In governance workflows, usage evidence helps distinguish legitimate need from legacy entitlement drift.

What's in the full announcement

C1.ai's full post covers the operational detail this post intentionally leaves for the source:

• How the Claude Compliance API data lands alongside identity records in C1 settings
• The exact workflow for surfacing active versus inactive Claude users and agents during reviews
• How unusual Claude Platform API key activity is tied back to the owning identity and role
• The lifecycle handling used to remove Claude seats, API access, and admin permissions when purpose ends

👉 The full C1.ai post covers how Claude activity data supports reviews, audit trails, and lifecycle removal.

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 programme, it is worth exploring.