What should organisations check first when they start inventorying AI assistants and autonomous agents?

Start with a simple inventory of what is running, what each system can touch, and who owns it. For assistants, map the employee, the assistant, and the connected systems. For autonomous agents, confirm the owner, trigger, permissions, and shutdown process. If you cannot quickly answer who can turn it off, the identity and governance model is not ready.

What to inventory before you go deeper

Start with three facts for every assistant or agent: what is running, what it can reach, and who owns the decision to change or stop it. That first pass should capture the system name, environment, connected data and tools, and whether the item is human-prompted, event-driven, or autonomous. If any of those fields are missing, the inventory is still too shallow to trust.

For assistants, map the employee, the assistant, and the connected systems so you can see where the tool can act on behalf of a person. For autonomous agents, the critical checkpoint is whether the owner can explain the trigger, the permissions, and the shutdown path without hunting across teams. The inventory should make hidden control paths visible, not just count assets.

When organisations inventory AI assistants, the same discipline used for NHI governance and lifecycle management helps expose where runtime access is broader than the business expects.

Why ownership and blast radius matter first

Ownership is the fastest way to separate a manageable pilot from an unmanaged operational risk. If no one can name the accountable business owner, the technical owner, and the approver for access changes, the organisation cannot reliably answer who is allowed to expand, pause, or retire the assistant or agent. That is especially important once the system can touch production data, tickets, code, or customer records.

Scope matters just as much. A small assistant with read-only access may be acceptable, while an agent with write access, automated triggers, or external connectors can create a much larger blast radius than the label suggests. In practice, the inventory should reveal whether the system is informational, advisory, or action-taking, because that distinction determines how much governance and containment it needs.

AI assistants and agents often arrive with more access than teams initially realise, so it helps to compare the inventory against the patterns in Top 10 NHI Issues and the broader guidance in NHI lifecycle management.

What good looks like in the first inventory pass

A useful first inventory does not wait for perfect taxonomy. It gives you enough structure to decide whether the system can be trusted, constrained, or paused. Good inventory records usually include the intended purpose, data categories, integrations, privilege level, logs, and a tested way to disable the assistant or agent without breaking unrelated services.

Record the system’s purpose and whether it acts only on prompts or also on triggers.
List every system, API, dataset, workspace, or admin console it can reach.
Name the business owner, technical owner, and emergency shutdown owner.
Capture the approval path for permission changes and new integrations.
Confirm whether the assistant or agent can be disabled quickly without losing control of other workflows.

For teams managing agentic features, the failure mode to watch is not complexity alone, but ambiguity about who can intervene when behaviour changes. That is where a breach, misfire, or over-permissioned workflow becomes hard to contain, especially if the system has persistent credentials or broad tool access.

Risk and Threat Considerations

Inventory gaps create hidden exposure because an assistant or agent can keep acting with privileges long after the team assumes it is benign. The main risks are overbroad access, unclear ownership, and weak shutdown controls, which together can turn a productivity tool into a durable pathway for data exposure or misuse.

Failure mechanism: The organisation records the tool but not its real permissions, trigger conditions, or revocation path, so no one can confidently reduce access when the system misbehaves, changes scope, or is compromised.

Impact: Excessive access, delayed containment, and unclear accountability can allow unintended data access, destructive actions, or prolonged abuse before the problem is noticed.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Non-Human Identity Top 10 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST AI RMF and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
OWASP Non-Human Identity Top 10	NHI-01 — Visibility and Discovery	Inventorying assistants and agents starts with finding what exists and what it can reach.
	NHI-02 — Ownership and Accountability	The question centers on who owns the system and who can shut it down.
	NHI-03 — Privileges and Access Control	Checking what each system can touch is an access-scope and least-privilege issue.
Recommendation — Discover every assistant, agent, connector, and credential path before granting broader access. Assign a named owner and approver for each assistant or autonomous agent. Restrict each system to the minimum data, tools, and actions it needs.
OWASP Agentic AI Top 10	A2 — Agent Authority and Access Boundaries	Autonomous agents require explicit trigger, permission, and shutdown boundaries.
Recommendation — Define agent triggers, authorize tool use narrowly, and test rapid disablement.
NIST AI RMF	GOVERN — GOVERN	The inventory question is fundamentally about AI governance, ownership, and accountability.
Recommendation — Establish accountable governance for AI systems before expanding deployment.
NIST Zero Trust (SP 800-207)	PL-4 — Dynamic Policy Enforcement	AI assistants and agents should be constrained by policy that limits what they can access.
Recommendation — Enforce runtime policy checks before allowing tool or data access.

Practitioner Guidance

What to verify: Before trusting the inventory, verify that each item has a named owner, a current connector list, and a tested off switch. If any autonomous agent cannot be disabled by a designated owner within a reasonable operational window, treat that as a governance defect rather than a documentation gap.

Decision rule: If the system can take action outside a live human conversation, classify it as requiring tighter change control than a passive assistant. If it can only recommend or draft, you still need ownership and data mapping, but the shutdown requirement is less operationally urgent than for an agent with active execution rights.

Practitioner takeaway: The first inventory is not about naming every AI feature, it is about proving that each one is bounded, attributable, and stoppable before it is allowed to expand in scope.