AI inventory alone cannot govern Claude Code access and scope

Editorial analysis by NHI Mgmt Group, based on content published by Identra.ai: “What an AI inventory can't tell you”.

At a glance

What this is: This analysis says an AI inventory is necessary but insufficient because approved tools do not reveal the live identity, scope, or revocation path behind an agent run.

Why it matters: IAM, PAM and NHI teams need to govern the credential and action boundary behind each AI workflow, not just the application name in a register.

Context

An AI inventory is a starting point, not a control plane. The security problem is not whether an AI application is on the approved list, but which identity it actually runs under, what data it can reach, and which actions it can take at runtime.

For IAM and NHI programmes, the weak point is the gap between approval at the tool level and authorisation at the credential level. That gap widens when one vendor row hides multiple accounts, scopes, plugins, connectors, and response owners.

The article uses Claude Code as the example, but the governance issue applies across AI assistants, coding agents, and connected workflows. A register can show presence; it cannot by itself prove boundary, ownership, or revocation authority.

Key questions

Q: How should security teams govern AI workflows when an inventory only shows the tool name?

A: Govern the acting identity, not the label in the register. The inventory should be a discovery layer that feeds decisions about account, scope, target data, and revocation path. If teams cannot identify the credential that actually reaches the resource, they do not have an access model, only a catalogue of approved apps.

Q: Why do approved AI agents still create security risk in enterprise environments?

A: Because approval is not the same as authorisation for every action. An agent may be allowed to run, yet still be able to read files, invoke tools, or alter systems beyond its task. Risk rises when teams trust the application but fail to constrain the behaviour of the session.

Q: What breaks when AI agents can reach data through multiple connectors and tokens?

A: The control boundary becomes fragmented. One workflow can inherit access from the app, the agent, the connector, and a local configuration file, so no single approval describes what can actually happen. That makes least privilege, review, and revocation harder unless teams govern each link in the chain separately.

Q: How do teams know who should revoke access when an AI workflow misbehaves?

A: They need a preassigned response owner for the specific identity in use, whether that is a user session, OAuth grant, service account, or local token. If the team has to debate who owns revocation during an incident, the governance design was incomplete before the problem started.

Technical breakdown

Why AI inventory is not the control boundary

An AI inventory records that a tool exists and may record an owner, but it rarely captures the live authentication context. In practice, one assistant can be reached through a company workspace, a personal login, an OAuth grant, a service account, or a local token, each with different reach. That makes the inventory a discovery layer, not an access decision. The article’s chain view matters because the risk emerges from the acting identity, the connected systems, and the allowed action, not from the product name alone.

Practical implication: Treat the inventory as a discovery input and move governance to the credential, scope, and action level.

How the human-to-agent chain expands privilege

The chain described in the article is Human → AI application → Agent → MCP server → skill or plugin → tool → data → action. Each link can add authority without changing the label on the original approval. A coding agent may inherit a ticketing token, a repository token, and a local file path in one task, while also being able to invoke connectors directly. The technical issue is not only whether the agent is allowed to act, but whether each downstream component can widen scope beyond the intended task.

Practical implication: Map every downstream grant in the chain and remove authority that is not required by the specific workflow.

Why observed behaviour and granted authority are different facts

The article separates access, capability, behaviour, and exposure. Access is what the identity can reach. Capability is what it can do there. Behaviour is what happened in a given run. Exposure is the harm those first two make possible if the workflow is misused. That distinction matters because a blocked attempt is not evidence of compromise, and a quiet log does not make unused permission safe. Governance fails when teams collapse these facts into a single score or a single approval row.

Practical implication: Evaluate requested action, target, authorisation, and result as separate evidence objects in review and incident handling.

NHI Mgmt Group analysis

Approval attached to a vendor row is not a usable governance model for AI workflows. The article shows that a tool can be approved while the acting account, connector scope, and response path drift underneath it. That is an inventory problem only at the surface. The deeper issue is that governance was attached to the application name instead of the credential and action boundary, which is where control actually exists.

Runtime AI governance now depends on identity traceability, not application visibility. Security teams can name the tool, but that does not answer which account reached the data or who can revoke it. The operational unit of control is the combination of actor, token, workspace, and target system. Practitioners need auditability that connects request, identity, tool call, and outcome, or the review is only documentary.

AI inventory without scope control creates false confidence in NHI and IAM programmes. A row in the register can look mature while the underlying token is over-scoped, long-lived, or shared across contexts. Runtime identity boundary: the real control object is the smallest set of credentials and permissions that can complete one authorised task. Teams should recognise that the boundary lives below the register.

Response authority must be assigned before the workflow is allowed to scale. The article’s question of who pulls access when something goes wrong is not an afterthought. If the team cannot immediately identify who revokes the app grant, session, or local token, then the access model is already too loose. That makes response ownership part of design, not incident cleanup.

AI governance and service account governance are converging. The same failure pattern appears whether the subject is a human-driven assistant, a coding agent, or a backend NHI: approval sits too far from execution. NHI governance disciplines such as lifecycle ownership, scope minimisation, and revocation planning now apply directly to AI-assisted workflows. Practitioners should govern the credential, not the logo.

From our research library:

• Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security, according to the 2026 Infrastructure Identity Survey.
• Read next: NHI Lifecycle Management Guide

What this signals

AI governance programmes are moving from application inventories toward runtime identity control, because an approved assistant can still operate through a broader credential than the listed use case suggests. That shift means boundary definition, revocation ownership, and connector scope now matter more than tool approval alone.

Runtime identity boundary: the practical unit of control is the smallest credential and permission set that can complete one authorised task. If the boundary is not explicit, a safe-looking inventory row can conceal over-scoped access, shared tokens, and unclear response authority.

Service-account visibility remains a useful proxy for the broader problem: only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs. That same visibility gap now shows up in AI workflows, where the acting identity is often more important than the application name.

For practitioners

• Define the acting identity for every AI workflow Record the exact account, token, service principal, or workspace the workflow runs under, not just the approved tool name. Reconcile each one to a human owner and a revocation path.
• Break the workflow into scoped control points Map the human, application, agent, connector, skill, tool, data, and action as separate control points, then remove any link that widens authority beyond the task.
• Test prohibited actions in a live run Watch an operator attempt one allowed action and one prohibited action, then verify that the denied action truly fails and leaves a traceable record.
• Tie response authority to the identity used Pre-assign who can revoke the local token, remove the OAuth grant, or terminate the session so the right control is available when the workflow misbehaves.
• Re-certify AI approvals after any scope change Re-open review whenever a connector, permission set, skill, or workspace changes, because the original approval only covered the earlier boundary.

Key takeaways

• AI inventories help teams discover what exists, but they do not by themselves define who is acting, what the actor can reach, or who can revoke it.
• The governance gap appears at runtime, where credentials, connectors, and workspace scopes can differ sharply from the original approval.
• Practitioners need identity-level traceability and preassigned response authority if they want AI approvals to reflect real control rather than administrative recordkeeping.

Key terms

• AI Inventory: An AI inventory is a governed record of all AI-related assets, enriched with owner, purpose, access, and risk context. It turns discovery into something security, compliance, and IAM teams can use to make approval, review, and revocation decisions.
• Runtime Identity Boundary: A runtime identity boundary is the point where a system’s authorised access stops and another actor’s access begins. For autonomous workflows, that boundary must be explicit, because the agent may call tools, reuse memory, and chain actions inside a single session.
• Per-Actor Identity: Per-actor identity means each workload, agent, or system has its own distinct credentials and audit trail. It is a governance baseline for AI and NHI environments because shared identities erase attribution, blur accountability, and make incident reconstruction much harder.
• Response Authority: Response authority is the delegated permission to take containment and recovery actions during an incident without waiting for ad hoc approval. It matters because incident response often fails when people know the right action but cannot execute it fast enough to prevent escalation.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security 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.