Because the agent’s effective capability set is no longer fixed at session start. Discovery mechanisms decide which tools are surfaced, so authorisation now depends on ranking logic, context triggers, and loading rules as well as access grants. That means teams have to govern tool selection as part of the control model, not treat it as a harmless optimisation.
How deferred discovery changes the agent control boundary
Deferred tool discovery shifts the control boundary from a fixed startup inventory to a runtime decision process. The agent is not simply “allowed” or “not allowed” to use a tool, because the tool may not even be surfaced until context, ranking, policy, or retrieval logic decides it should appear. That turns discovery into part of the authorization surface, not just a convenience layer.
In practice, this means governance has to cover the whole path from candidate tool set to surfaced tool list to executed action. If discovery logic can prefer, hide, or delay tools, then the organisation is governing a living capability set, not a static permission list. That is a different operating model from ordinary app configuration, because the effective access boundary can change from one prompt, task, or session to the next.
Discovery also introduces ambiguity about who or what is making the effective access decision. A human reviewer may approve the agent, but the real question becomes which tools are eligible, in what order, under which context, and with what loading rules. That is why deferred discovery must be treated as an access-control and policy-design problem, not a UI or search optimisation feature.
Why ranking, context, and loading rules become governance controls
Once discovery is deferred, ranking logic can act like a policy filter. A tool that is technically available may never be exposed if it ranks too low, while a risky tool may be surfaced because the context matched a trigger too broadly. The governance model therefore has to define what “eligible” means, what data can influence ranking, and which decisions are deterministic versus heuristic.
Loading rules matter because they determine when a tool becomes callable and what prerequisites must be satisfied first. If a tool loads on partial context, stale state, or weak confidence, the agent can gain access too early. That creates a control issue similar to partial authorisation: the system is not only deciding whether the agent may act, but whether the agent should even be shown an action path at that moment.
The AI Agent Authorisation Guide is a useful companion here because it frames least privilege as per-action policy, not one-time session approval. Deferred discovery extends that same logic upstream into tool selection.
This is also where zero standing privilege thinking becomes relevant. If a tool is only surfaced when the task justifies it, the control objective is no longer broad standing access plus after-the-fact restraint. It is on-demand exposure, with the discovery layer acting as part of the privilege boundary.
The Zero Trust for AI Agents guide aligns with that model because it treats each request as something to verify, rather than assuming an initial allow decision covers the rest of the session.
What governance needs to cover once tools appear at runtime
Deferred discovery changes governance because teams must now manage both tool inventory and tool surfacing behaviour. It is no longer enough to approve a connector, register it, and rely on a static allowlist. Governance has to answer which tools exist, which contexts can reveal them, who can influence discovery, and how the surfaced set is reviewed when it changes.
That creates a need for lifecycle discipline around registration, ownership, and offboarding. A tool that is never discovered is still part of the control environment if it can be surfaced later by a new rule or a different context source. Conversely, a retired tool can remain a latent risk if discovery still points to it or caches its metadata.
The Agentic AI Identity Guide helps anchor this as an identity and delegation problem, because discovery is only safe when the agent’s authority, scope, and retirement path are explicit. The Agentic AI Identity Maturity Model is also relevant for organisations trying to move from ad hoc tool exposure to a governed operating model with defined maturity stages.
Discovery governance should also preserve evidence. Teams need to know which tools were surfaced for a given task, why they were surfaced, and what policy or ranking signal caused that choice. Without that trace, it becomes difficult to review incidents, justify approvals, or prove that a high-impact action was exposed under the right conditions.
The AI Agent Observability, Audit and Incident Response Guide is useful because deferred discovery makes auditability part of the control model, not a post-incident nice-to-have.
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 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Deferred discovery changes who gets effective tool access at runtime. |
| ASI02 — Tool Misuse | Discovery logic can expose the wrong tool at the wrong moment. | |
| ASI10 — Rogue Agents | Runtime tool exposure can let agents act beyond intended governance. | |
| Recommendation — Bind tool surfacing to per-action privilege checks and approved context signals. Constrain tool selection to approved tasks and block unsafe tool combinations. Detect and suppress agents that discover or invoke unapproved tools. | ||
| NIST SP 800-53 Rev 5 | AC-3 — Access Enforcement | Tool discovery functions as part of runtime access enforcement. |
| AU-2 — Event Logging | Discovery decisions need auditability to explain surfaced tools. | |
| Recommendation — Enforce policy at tool-surfacing and tool-execution time. Log tool ranking, surfacing, and invocation decisions for review. | ||
Practitioner Guidance
What to verify: Confirm that discovery outputs are deterministic enough to explain, replay, and audit for the same inputs. If two identical tasks can surface materially different tool sets without an approved reason, the governance model is too loose for production.
Decision rule: If a tool can trigger external side effects, access sensitive data, or change downstream permissions, govern its surfacing as if it were an access grant. Treat “not yet surfaced” as a control state that still needs policy, ownership, and review.
What good looks like: Tool discovery is logged, explainable, bounded by policy, and tied to task context that the organisation can defend. The best signal is not that every tool is visible, but that only the right tools become visible for the right reason.
Practitioner takeaway: Deferred discovery is a shift from static permission management to runtime capability governance, so the control question becomes not just “can the agent use this tool?” but “what logic is allowed to make that tool visible in the first place?”