Discovery becomes an access event, not just a convenience feature. If a host can enumerate tools before the platform checks entitlement, the agent may expose workflows, data sets, or prompts the user should never learn exist. That expands the attack surface and makes policy dependent on what the agent can see, not only what it can execute.
When discovery happens before entitlement, what actually changes?
The main break is that discovery is no longer a passive catalog function. Once an agent can enumerate capabilities before the platform checks entitlement, visibility itself becomes privileged information, because knowing a workflow exists can reveal sensitive data paths, hidden actions, or prompts that were meant to stay undisclosed.
That changes the control objective from “can the agent execute this action?” to “can the agent learn that the action exists at all?” In practice, the policy boundary moves earlier in the request flow, and the discovery layer must be treated as part of authorization design, not just product ergonomics.
How discovery-before-entitlement expands the attack surface
Discovery first creates a larger and more informative attack surface. An unauthorised agent may not be able to launch a sensitive action, but it can still map the environment, infer higher-value targets, and learn which tools, datasets, or agent prompts exist behind the curtain. That information can be enough to steer later abuse, social engineering, or prompt-driven exploitation.
It also weakens least-privilege assumptions. If the platform leaks capability names, descriptions, or metadata before access checks, users may gain indirect knowledge of systems they should never see, and that knowledge can become an abuse path even when execution remains blocked.
For agent ecosystems, discovery is especially sensitive because tool catalogs often reveal privilege boundaries, downstream integrations, and operational dependencies. A visible capability list can also expose what kinds of secrets, APIs, or external systems the agent may touch, which raises the value of reconnaissance for both insiders and external attackers.
What needs to be gated, and where the design usually fails
Good designs apply entitlement before capability enumeration, not after. The platform should validate who is asking, what context they are in, and which scopes they hold before returning tool names, workflow summaries, connection targets, or any other metadata that would disclose protected functions.
Common failure modes are subtle: a UI or API may hide the “execute” button but still return a full capability manifest; a host may enforce access at run time while allowing prefetch or autocomplete to leak the catalog; or the agent may expose metadata from cached discovery results even after the user context changes. Those are authorization failures, not just presentation bugs.
A useful reference point is the broader entitlement and access-governance model in the IAM and IGA Basics guide, which treats entitlements as something to govern up front rather than discover casually. For agent-specific permissioning, the AI Agent Authorisation Guide shows why per-action checks and delegated authority need to precede tool exposure.
Risk and Threat Considerations
When capability discovery happens before entitlement checks, the risk is not only unauthorized execution, but unauthorized knowledge. That can expose internal workflows, sensitive datasets, and high-value integration points, giving attackers a map of what to target next even if the first request is denied.
Failure mechanism: The platform discloses protected capability metadata before it verifies scope, role, or delegation, so the access decision arrives too late to protect the discovery surface.
Impact: Attackers and untrusted users can enumerate hidden functions, infer trust relationships, and use that intelligence to plan privilege escalation, prompt abuse, or targeted data access attempts.
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 API Security Top 10 address the attack surface, NIST SP 800-53 Rev 5 sets 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 | Covers agent exposure to privileged capabilities before access checks. |
| Recommendation — Enforce entitlement before exposing tool or capability metadata to an agent. | ||
| OWASP API Security Top 10 | API5 — Broken Function Level Authorization | Discovery-before-entitlement is a function-level authorization failure pattern. |
| Recommendation — Gate function discovery on authorization before returning capability details. | ||
| NIST SP 800-53 Rev 5 | AC-3 — Access Enforcement | Requires access decisions before protected functions or information are released. |
| AC-6 — Least Privilege | Limits what an agent can learn by restricting exposure to only approved capabilities. | |
| Recommendation — Enforce access decisions before revealing protected capability information. Limit each principal to the minimum capabilities and metadata needed for its task. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Access control should govern both use and visibility of protected functions. |
| Recommendation — Apply access control before disclosing sensitive capabilities or workflows. | ||
Practitioner Guidance
What to verify: Confirm that entitlement is enforced before any capability list, schema, workflow description, or tool registry is returned. If the interface can still be browsed after a denied execution check, the control is not early enough.
What good looks like: The agent only learns what it is allowed to use in the current context, and a denied principal sees no more capability detail than is necessary for a safe rejection message. The discovery layer should degrade gracefully, not reveal a richer catalog and then block action.
Common mistake: Teams often protect execution while leaving discovery open, assuming “read-only metadata” is harmless. For agents, metadata is often enough to create a targeting advantage, so disclosure must be judged as part of authorization design, not as a UX detail.
Practitioner takeaway: If the agent can see the capability, assume the control boundary has already been weakened unless entitlement was checked first.