Claude activity governance exposes the gap in AI identity control

At a glance

What this is: This is a governance integration for Claude that combines access data with activity telemetry so teams can review who has access and what they do inside the platform.

Why it matters: It matters because IAM and IGA teams need evidence that access is being used as intended, not just provisioned, across both human users and AI agents.

👉 Read C1.ai's analysis of Claude activity governance and AI identity control

Context

Claude activity governance is a response to a basic identity control gap: provisioning a seat does not tell you whether access is still justified or whether a key is still active. In AI platforms, the governed object is not just the account, but the activity generated through conversations, API calls, and agent actions.

C1 describes the integration as bringing Claude Enterprise and Claude Platform activity into the same identity record, review workflow, and audit trail used elsewhere in the enterprise. That matters for NHI, human IAM, and agentic AI governance because access reviews that ignore usage are blind to dormant seats, orphaned API keys, and permissions that have outlived their purpose.

Key questions

Q: What breaks when Claude access is reviewed without activity telemetry?

A: Teams end up certifying accounts that are still entitled but no longer justified by use. In practice, that means dormant seats, stale API keys, and unused admin permissions stay open because the review process sees status, not behaviour.

Q: What does AI change in identity and access governance reviews?

A: AI changes the speed and volume of review, not the accountability model. Teams can use analytics to prioritise exceptions, but they still need owners, approvers, and evidence for every sensitive access decision. The practical shift is from periodic spreadsheet review toward continuous, data-driven oversight of who can do what.

Q: How do security teams spot orphaned Claude access before it becomes an audit finding?

A: Look for accounts, keys, or admin grants with no recent activity but no formal offboarding event. The strongest signal is a mismatch between active entitlement and inactive use, especially when the original project or role has already changed.

Q: How should organisations govern human, NHI, and AI agent access in one programme?

A: Use one identity governance model with different control treatments by actor type. Human access still needs joiner-mover-leaver discipline and certification. NHIs need ownership, rotation, and revocation. AI agents need runtime scope control, explicit action boundaries, and visibility into the identities they use to reach tools and data.

How it works in practice

Why access records alone are insufficient for Claude governance

Traditional IAM and IGA models assume that if a user or service account is provisioned correctly, later access reviews can confirm whether it still needs access. That assumption breaks down when the platform produces meaningful activity outside the identity system, such as conversations, API calls, and agent actions. Claude activity data is therefore not just telemetry; it is the evidence layer that tells governance teams whether the account, key, or agent is still acting within scope. Without that linkage, the identity record becomes a static entitlement list detached from runtime use.

Practical implication: review access and activity together, or you will certify accounts that are technically valid but operationally stale.

How activity telemetry changes lifecycle workflows for human users and AI agents

Lifecycle workflows usually treat joiner-mover-leaver events as changes in entitlement status. In Claude, activity telemetry adds a second signal that can confirm whether a human user or AI agent is still active, whether an API key is still being exercised, and whether access should be removed before the next review cycle. This is especially relevant where access was granted for a temporary project, because the identity layer alone cannot tell you whether the work ended last week or whether the account has become functionally orphaned.

Practical implication: use activity to trigger offboarding, access recertification, and exception handling instead of waiting for scheduled review dates.

What audit evidence looks like when identity and activity are joined

Audit evidence becomes stronger when it connects request, approval, and post-approval use in one record. For Claude governance, that means the platform can show who requested access, who approved it, what role or scope was assigned, and what happened afterward. That is a different control model from simple access logging, because it supports questions about justification, not just presence. For AI agents, the same evidence chain is what lets auditors distinguish a permitted workflow from an uncontrolled or stale one.

Practical implication: preserve approval-to-activity linkage so auditors can test whether access was both authorised and actually used for the intended purpose.

NHI Mgmt Group analysis

Claude governance exposes an activity gap, not just an access gap: identity programmes built only around provisioning and recertification cannot explain what a user, key, or agent is doing after access is granted. That is a structural weakness when AI platforms generate their own operational history through prompts, calls, and automated actions. The practitioner conclusion is clear: activity must become part of the governed identity record.

Access reviews assume there is something durable to review: that premise fits human seats and long-lived service access, but it becomes brittle when AI usage is volatile and task-driven. If an AI account can be meaningful one day and idle the next, the value of a periodic certification window drops sharply. The implication is that identity governance must move closer to usage-aware control points.

Orphaned API access is a governance state, not just a hygiene issue: when access outlives the project, the account remains valid while the business justification disappears. That is exactly the kind of drift that standard IAM often misses because the entitlement still looks approved. The field needs to treat orphaned access as evidence of lifecycle failure, not merely poor housekeeping.

AI platforms force identity governance to span human, NHI, and agent activity in one model: Claude activity events can belong to a person behind the key, a human user, or an AI agent acting inside a workflow. This is where cross-actor governance becomes real, because the same review and audit logic must explain all three. Practitioners should expect identity teams to own that convergence, not delegate it to platform telemetry alone.

Identity and activity convergence is becoming the new baseline for defensible AI adoption: once AI platforms operate inside enterprise workflows, the control question is no longer whether access was granted, but whether the resulting behaviour stayed within scope. That changes audit expectations, lifecycle design, and accountability across the stack. The practitioner implication is to treat runtime activity as part of identity governance, not as a separate observability layer.

From our research library:

• Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.

What this signals

Access review cycles will need a usage-aware layer: when AI platforms produce both identity events and runtime activity, the certification question changes from whether access exists to whether it is still being exercised for the right purpose. That shifts governance from entitlement confirmation to evidence-based lifecycle control.

Orphaned access becomes easier to prove when activity is attached to identity: a seat, API key, or agent can look legitimate in the directory while being functionally dead or misused in practice. Organisations that cannot join those signals will struggle to distinguish a valid exception from a silent governance failure.

For practitioners

• Tie access reviews to actual usage Require review workflows to include recent activity, not only assigned roles or group membership, so dormant Claude access is visible before recertification closes.
• Reconcile API keys to a named owner Map every Claude Platform API key back to the person or team responsible for it, then flag keys that show activity but lack an accountable owner.
• Flag dormant seats and orphaned permissions Treat thirty-day inactivity as a governance signal, not a helpdesk metric, and remove seats or admin rights that no longer match the current business purpose.
• Join approval records to post-approval activity Preserve the request, approval, and subsequent usage record together so audit evidence can prove that access was both authorised and exercised as intended.
• Extend lifecycle workflows to agent actions Apply the same offboarding and recertification logic to AI agents that you already apply to users and service accounts, because their activity can also drift out of scope.

Key takeaways

• Claude governance is exposing a familiar failure mode in a new setting: access approval without usage evidence.
• The core control problem is not provisioning alone, but proving that access, keys, and agent actions still match current purpose.
• Joining identity records to activity telemetry gives IAM and IGA teams the evidence needed to retire dormant access before it becomes an audit issue.

Key terms

• Usage Telemetry: Usage telemetry is activity data that shows whether a user or organisation is actually using a SaaS application or licence. It helps teams distinguish active business value from dormant entitlement, and it is most useful when combined with ownership and lifecycle records.
• Dormant access: Dormant access is an entitlement that remains technically valid even though the subject no longer uses it for its intended purpose. In identity governance, dormant access is dangerous because it preserves privilege, complicates review, and often survives well past the business need that created it.
• Orphaned API Access: Orphaned API access is a key or token that still works but no longer has a clear owner, current justification, or active project. It is a lifecycle failure as much as a security issue, because accountability and revocation both depend on knowing who is responsible for the credential.
• Usage-Aware Recertification: Usage-aware recertification is an access review process that weighs recent activity alongside assigned roles and approvals. It is especially useful where AI systems, service accounts, or shared keys can remain technically valid while their real-world use has dropped to zero.

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 maps activity events into identity records
• The exact lifecycle workflow changes for dormant seats and unused admin permissions
• What audit evidence becomes available when request, approval, and activity are joined
• How existing C1 customers can enable the connector in settings

👉 The full C1.ai post covers the Claude activity model, lifecycle workflow changes, and audit evidence flow.

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.