How do tool discovery and skills affect access review for AI agents?

How runtime discovery changes what an access review must cover

tool discovery and skills change the unit of review from “what was assigned” to “what the agent can reach at runtime.” That matters because an AI agent may only expose a tool, connector, or skill when a task, policy, or context makes it available. Access review therefore has to validate the discovery path, not just the baseline entitlement.

This is especially important when teams treat the agent like a static user account. If discovery can expand capability on demand, a clean entitlement list can still hide meaningful exposure. Reviewers need to ask what the agent can discover, under what conditions, and whether that path is bounded by policy, approval, or environment controls.

That distinction is covered well in AI Agent Authorisation Guide, which frames least privilege as task-scoped and per-action rather than static. It is also reinforced by Agentic AI Identity Guide, because runtime authority only makes sense if the agent’s identity, delegation, and lifecycle are understood together.

Why skills and discovery create a wider review surface

Skills are often packaged capability blocks, but they are not just software inventory. A skill can inherit permissions, load external resources, call tools, or change the agent’s effective authority when invoked. Discovery mechanisms make that change harder to spot because the capability may not be present until the triggering task appears.

That creates a review problem at two levels. First, the organisation must know which skills exist and who can introduce them. Second, it must know whether a discovered skill changes the agent’s effective access profile, such as by reaching new data sources, privileged operations, or external services. Static entitlement review will miss that if it ignores activation logic.

The practical implication is that access review should cover the control plane and the runtime plane together. A correct review asks whether the agent can discover new tools, whether those tools are trusted, and whether any skill chain can amplify privilege beyond the baseline account. For a broader view of how identity, access, and risk shift across agent autonomy, AI Agents vs Agentic AI is a useful navigation point.

What good review evidence looks like for AI agents

Good evidence is not just a list of assigned permissions. Reviewers need an inventory of discoverable tools and skills, the conditions under which they become available, and the policy path that authorises them. If the organisation cannot produce that evidence, it cannot confidently say the agent’s access is fully reviewed.

For higher-risk agents, the review should also show which capabilities are task-scoped, which are persistent, and which are inherited from a parent workflow, platform, or connector. The most important question is whether an agent can take a benign starting state and reach a more powerful action path without a corresponding review record. If yes, the review process is incomplete.

That is why Agentic AI Security Guide and Zero Trust for AI Agents are relevant companions here. They reinforce the need to verify the request, the principal, and the action each time capability is exercised, rather than assuming the agent’s starting entitlements tell the full story.

Risk and Threat Considerations

Discovery-driven capability expansion creates a blind spot for entitlement-centric review. An attacker, malicious prompt, or misconfigured workflow may not need permanent access if it can trigger discovery of a more powerful tool or skill at runtime. That makes the agent’s effective exposure larger than its static assignment list suggests.

Failure mechanism: The review process validates provisioned access but not the discovery path, so a tool, skill, or connector becomes usable without being visible in the entitlement record or review evidence.

Impact: The agent can reach sensitive tools, data, or actions that were never consciously approved in review, increasing the chance of over-privilege, unauthorized action, and difficult-to-attribute misuse.

Practitioner Guidance

What to verify: Confirm that every runtime-discoverable capability has an owner, an approval path, and a policy condition that explains when it can appear. If a skill registry, tool catalog, or plugin source exists, review it as part of the access control surface, not as separate documentation.

Decision rule: If a capability can change the agent’s reachable actions after initial provisioning, treat it as in-scope for access review even when no static entitlement changed. If you cannot prove the discovery boundary, assume the review is incomplete.

Practitioner takeaway: For AI agents, access review is only trustworthy when it covers how authority is discovered and activated at runtime, not just what was granted upfront.

Related resources from NHI Mgmt Group

• How should organizations approach the governance of AI agents?
• How should security teams govern API keys used for generative AI access?
• When should organizations review access controls?
• When should organizations consider adopting advanced tool discovery for AI agents?