TL;DR: AI platforms are no longer just being evaluated, they are being used at operational scale, and governance designed for traditional SaaS does not fully capture conversational activity patterns, according to ConductorOne, as Claude activity data from Claude Enterprise and the Claude Platform can now flow into the same governance layer as identity records, giving teams access, activity, approvals, and audit evidence in one place.
NHIMG editorial — what this means for NHI practitioners
By the numbers:
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
- 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage.
- 92% of organisations expose NHIs to third parties, raising concerns about supply chain security.
Questions worth separating out
Q: How should security teams govern AI platform access when activity matters as much as entitlement?
A: Treat access records and activity data as one governance problem.
Q: Why do AI platforms complicate traditional access review processes?
A: Because access reviews were designed to confirm who can enter a system, not whether platform behaviour still fits the approved business case.
Q: What breaks when API keys and admin access are not tied to lifecycle events?
A: Stale access persists after the project, role, or vendor relationship has changed, which leaves permissions in place after the original justification is gone.
Practitioner guidance
- Unify access and activity records Bring Claude access events, approval data, and activity logs into the same review workflow so reviewers can see entitlement and behaviour together.
- Rebuild access reviews around actual usage Target the review queue to users and agents with recent activity, then investigate stale seats, dormant keys, and unusually active admin accounts.
- Attach role context to API key events Link platform key activity to the owning role, group membership, and broader access scope so unusual volume is evaluated in context.
What's in the full announcement
ConductorOne's full blog covers the operational detail this post intentionally leaves for the source:
- How Claude Compliance API activity events are mapped into the governance layer alongside identity records
- The specific review flows for users and agents that were active in the last thirty days
- How access, approval, and activity evidence are tied together for audit support
- Lifecycle workflow examples for closing seats, API access, and admin permissions when they outlive purpose
👉 Read ConductorOne's post on Claude Compliance API governance and activity logging →
Claude activity logs in identity governance: what changes for IAM teams?
Explore further
AI platform governance is now an identity problem, not a separate observability problem. ConductorOne’s integration shows that access records alone are no longer enough when the platform’s most important actions are expressed as activity. The governance stack has to connect entitlements, approvals, and usage in the same record set. Practitioners should treat this as an extension of identity governance into AI operating data, not as a logging feature.
A few things that frame the scale:
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to Ultimate Guide to NHIs.
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
A question worth separating out:
Q: Who should be accountable for AI platform activity in identity governance?
A: Accountability should follow the identity that was approved, the role that granted the access, and the business owner who justified it. If those links are missing, auditors cannot prove why the access existed or whether the subsequent activity was acceptable.
👉 Read our full editorial: Claude compliance data now sits inside identity governance workflows