They make review harder if the organisation only tracks static entitlements. An agent may discover tools or load skills only when a task requires them, so the reviewable state shifts from provisioned access to runtime exposure. Security teams should therefore validate both the baseline entitlement and the discovery path that makes additional capability available.
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.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and OWASP Non-Human Identity Top 10 address the attack surface, NIST SP 800-53 Rev 5 and OWASP ASVS set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Tool discovery can expand an agent's effective privilege at runtime. |
| ASI02 — Tool Misuse | Discovered tools and skills can be invoked in unsafe or unintended ways. | |
| Recommendation — Review and constrain runtime tool discovery so agent privilege cannot expand beyond approved scope. Validate discovered tools for misuse paths before allowing agent access. | ||
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Static entitlement review can miss excessive effective access in agents. |
| NHI-09 — NHI Reuse | Shared or reloaded skills can blur who/what is actually authorized at runtime. | |
| NHI-08 — Environment Isolation | Discovery can expose capabilities from other environments or contexts. | |
| Recommendation — Compare baseline entitlements with runtime capability to remove excess privilege. Separate reusable skills from distinct access scopes and review each authorization path. Isolate environments so agent-discoverable capabilities do not cross trust boundaries. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Runtime discovery can create excess effective access beyond assigned roles. |
| AC-2 — Account Management | Access review must account for how agent capabilities are provisioned and changed. | |
| Recommendation — Limit agents to the minimum reachable capability set needed for the task. Track capability changes and reviews as lifecycle events, not one-time setup. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Review must cover the effective access path, not only assigned permissions. |
| Recommendation — Document and enforce access rules for runtime-discoverable agent capabilities. | ||
| OWASP ASVS | V8 — Authorization | Runtime capability changes are an authorization problem, not only an inventory problem. |
| V10 — OAuth and OIDC | Agent tool discovery often relies on delegated OAuth-based access paths. | |
| Recommendation — Verify that each tool or skill activation is authorised at the point of use. Review delegated token and consent flows that enable agent-discovered tools. | ||
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.