Claude activity governance exposes the gap in AI identity control

At a glance

What this is: ConductorOne’s C1 integration with Anthropic’s Claude Compliance API connects access governance to activity data so teams can review, audit, and retire Claude access with more context.

Why it matters: It matters because IAM and IGA programmes now need to govern both who can reach AI systems and what those systems actually do once access is granted, across human, NHI, and agentic use cases.

By the numbers:

• 80% of identity breaches involved compromised non-human identities such as service accounts and API keys.
• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures.

👉 Read ConductorOne's post on governing Claude identity and activity in C1

Context

Claude adoption has moved from experimentation into operational use, which makes identity governance a control-plane problem rather than a licence-management problem. Once AI platforms are used across teams and workflows, access reviews have to answer not only who has access, but whether that access is still being used and whether the associated activity is consistent with the approved purpose.

Traditional IAM can provision a seat or an API key, but it cannot by itself prove whether the access is active, dormant, or out of scope. That gap is familiar to teams managing service accounts and other NHIs. It now extends into AI platforms, which is why the same governance patterns need to cover human users, machine credentials, and agent activity together. For the baseline model, see the Ultimate Guide to NHIs.

Key questions

Q: How should security teams govern access to AI platforms that are used by both people and agents?

A: Security teams should govern AI platforms with the same lifecycle discipline they use for NHIs, but add activity evidence to the review process. Access records tell you who may enter, while event data shows whether the entitlement is still active, justified, and within scope. Without both, certification is only partial governance.

Q: Why do AI platform permissions create lifecycle risk for IAM programmes?

A: AI platform permissions create lifecycle risk because access often outlives the task, project, or owner that justified it. That is the same failure pattern seen with dormant service accounts and orphaned credentials. If joiner-mover-leaver workflows do not remove unused access quickly, the organisation inherits standing privilege in a new form.

Q: How do you know if AI access reviews are actually working?

A: They are working only if reviewers can see current usage, revoke stale access, and produce evidence that the activity matched the approved purpose. If the process only confirms that access exists, it is a paper exercise. Effective review should surface dormant access, orphaned keys, and unexplained admin activity.

Q: Who is accountable when AI platform activity cannot be tied to a person or approved scope?

A: Accountability sits with the organisation that failed to maintain the identity chain, approval trail, and activity record. If a Claude action cannot be linked to an owner and a valid scope, the governance gap is in the control model, not in the log file. Frameworks such as the NIST Cybersecurity Framework 2.0 emphasise that accountability must be observable, not assumed.

How it works in practice

Access governance versus activity governance in AI platforms

Access governance answers who should be allowed in, while activity governance answers what they do after entry. In traditional SaaS, that second layer is often weak because activity is limited to login records and basic admin events. AI platforms generate richer event streams, including prompts, conversations, API calls, and agent actions. When those logs are correlated with identity records, reviewers can determine whether a seat, key, or role is actually being used within approved scope. That correlation is what turns a simple entitlement check into evidence-based governance.

Practical implication: security teams should require activity telemetry before they treat AI platform access reviews as complete.

Why lifecycle workflows matter for Claude Enterprise and API access

Lifecycle workflows are the mechanism that closes access when purpose ends. For AI platforms, that includes dormant seats, orphaned API access, and admin permissions that remain after a project closes or a team changes. The control failure is not just overprovisioning. It is access persistence after the business justification has expired. When identity governance ties approval records to observed activity, it can flag the mismatch between granted access and actual use, then route that entitlement for review or removal.

Practical implication: connect joiner-mover-leaver logic to AI platform activity so expired access is removed instead of merely reviewed later.

Audit trails for human users and AI agents

An audit trail becomes stronger when it includes the approval event, the entitlement granted, and the activity that followed. That is especially important when a human owns an API key that is used by an automated workflow or an AI agent inside the platform. Without that linkage, teams can see that something happened, but not who should answer for it or whether the action exceeded the approved context. Good audit design therefore treats identity, usage, and scope as one chain of evidence rather than separate records.

Practical implication: design audit evidence so every Claude action can be traced back to an identity, an approval, and a scope boundary.

NHI Mgmt Group analysis

AI platform governance is now an access-and-activity problem, not just an access problem. The article shows that seat provisioning alone does not tell you whether a user or agent is actually using Claude within approved scope. That is the same structural weakness that has long affected NHI governance, where entitlement exists on paper but usage and purpose drift in practice. Practitioners should treat activity data as part of identity governance, not as an optional logging layer.

Standing access to AI platforms creates the same lifecycle debt that plagues service accounts. The governance gap is not the presence of Claude access. It is the persistence of access after the work item, project, or role change that justified it. That is a classic lifecycle failure in identity governance, and AI systems make it more visible because their use is continuous and collaborative. Teams should expect dormant seats, orphaned keys, and stale admin roles to become the new audit findings.

Human identity and NHI governance are converging inside AI workflows. The article ties the person behind the key to the activity generated by that key, which is exactly the kind of linkage IAM and IGA programmes need across human, machine, and agent identities. When an AI platform action cannot be traced back to an accountable identity and scope, the governance model has not failed in one place. It has failed across the delegation chain.

Activity evidence is becoming the control that separates defensible AI use from unverifiable access. AI platforms produce actions, not just authentications, so governance needs to prove what happened after access was granted. That shifts the burden from static entitlements to evidence-backed oversight. Practitioners should assume that future audit expectations will increasingly ask for activity provenance, not merely permission records.

Access review processes built for periodic certification are too slow for AI platform use. Claude can be used across teams and workflows at a pace that outstrips monthly or quarterly review cycles. That means teams must look for continuous signals, not retrospective clean-up. The practical conclusion is simple: if access and activity cannot be correlated in near real time, the review process is already behind the control problem.

From our research:

• 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, according to Ultimate Guide to NHIs.
• Another finding: 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to Ultimate Guide to NHIs.
• For related guidance: Review Ultimate Guide to NHIs for lifecycle controls that help close dormant access and orphaned credentials.

What this signals

Claude governance will push IAM teams toward continuous evidence rather than periodic entitlement checks. If AI activity data is available, access reviews stop being a snapshot and become a living control. The programme implication is that review design, audit evidence, and lifecycle automation now need to work together, especially where access is shared across humans, keys, and agent workflows.

Identity programmes that cannot correlate entitlement and activity will struggle to defend AI adoption at scale. The control gap is not theoretical. With 96% of organisations storing secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, the broader identity problem is already one of distributed trust, not just permission assignment.

Access without activity context creates an identity blast radius: permissions remain valid, but governance loses sight of whether the entitlement still serves a business purpose. That is why teams should align AI platform governance with lifecycle automation and evidence collection, not treat telemetry as a separate monitoring function.

For practitioners

• Correlate access reviews with actual platform activity Require reviewers to see recent Claude activity alongside entitlement records so they can distinguish active users from dormant ones before recertification closes.
• Link API keys to accountable identities Map every Claude Platform key back to a named person, role, and approval record so usage can be traced when the key is exercised by automation or an AI workflow.
• Remove access when the business purpose ends Automate lifecycle workflows to flag and revoke dormant seats, orphaned API access, and unused admin permissions when project or role ownership changes.
• Treat activity telemetry as audit evidence Store approval, entitlement, and event data in the same audit trail so you can show who had access, what they did, and whether the activity stayed within scope.

Key takeaways

• The article shows that AI platform governance now depends on correlating access with usage, not just assigning entitlements.
• The scale of NHI compromise remains a material warning, because stale access and exposed keys are still central breach mechanisms.
• Practitioners should tighten lifecycle automation and audit evidence now so AI adoption does not create a new class of standing privilege.

Key terms

• AI platform activity governance: AI platform activity governance is the practice of reviewing what users and agents do after access is granted, not just whether they were allowed in. It combines event telemetry, entitlement records, and lifecycle controls so security teams can judge whether use remains approved, traceable, and defensible.
• Identity blast radius: Identity blast radius is the amount of damage a credential, role, or entitlement can cause if it is misused or left active too long. In AI and NHI settings, the concept includes not only access scope but also the speed at which activity can spread before governance catches up.
• 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.
• Activity provenance: Activity provenance is the ability to trace an action back to the identity, approval, and scope that authorised it. For AI platforms, provenance matters because logs alone do not prove accountability unless they connect usage to a named owner and an approved business context.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by ConductorOne: C1 integration with Claude Compliance API for identity governance. Read the original.