Why do agent permissions and user consent need to be checked at tool invocation time rather than only at connection time?

Why the check has to happen at tool invocation, not just at connection

Connection-time approval answers a different question from invocation-time approval. A connection only says the agent is allowed to connect, not that every future tool call is still intended, scoped, or safe. Invocation-time checks make the authorization decision against the exact action being attempted, which is what keeps delegated access tied to the real request rather than a stale earlier consent.

That distinction matters because agents often discover tools dynamically, chain actions across systems, and reuse the same session long after the user has forgotten the original approval. If the control point sits only at connection time, a valid session can become a wide operating envelope. Per-action authorization is the practical way to keep agent behavior inside the boundaries of least privilege and current user intent, especially for workflows that resemble agent authorisation rather than simple login.

Invocation checks also handle the real-world shape of consent. Consent can be narrow, time-bound, or revoked by context change, and the right decision may depend on the specific tool, the data touched, the environment, or the downstream side effect. That is why agent governance patterns such as zero trust for AI agents and OAuth 2.0 token exchange are designed around the request being evaluated, not just the session being opened.

What goes wrong when connection approval is treated as enough

Connection-only enforcement creates a gap between trust establishment and action execution. During that gap, the agent may encounter higher-risk tools, new scopes, or more sensitive data than the user intended when they first approved the connection. It also makes it harder to distinguish intended delegation from overreach when the agent chains several small actions into one materially larger outcome.

That gap becomes especially dangerous when a tool can modify records, move money, send external messages, or access secrets. A user may have approved the agent to “work with this app,” but not to perform every tool that the app later exposes. In practice, stale consent can turn a helpful integration into an overprivileged path, which is why governance for OAuth app governance and agent permissioning need revocation and scope review as part of normal operation.

Invocation-time checks also reduce the impact of tool discovery drift. An agent can be connected to one capability set in the morning and encounter a different one after a plugin update, workspace change, or cross-tenant reach later in the day. If policy is not re-evaluated at the moment of use, the control plane cannot distinguish a permissible call from a newly exposed one that the user never reviewed.

How to think about consent, delegation, and least privilege in practice

The clean model is: connection establishes trust, invocation enforces authorization. The user does not need to re-consent to every mouse click, but the agent should still be checked against the action it is about to perform. That is the only point where you can reliably compare the requested tool, the current context, and the current policy state.

This is also where the identity boundary matters most. A human may approve a task once, but the agent executes many discrete calls on the user’s behalf, often across systems and time. The control should therefore be anchored to the action, not to the session alone, and it should be easy to express limits such as task scope, time scope, environment scope, and approval gates. That is the same design logic that underpins human versus non-human identity when people and agents share delegated access.

Good implementations also separate “can connect” from “can act.” A tool list should not be treated as a blanket permission set. Instead, each invocation should be checked against the effective policy for that exact tool, that exact identity, and that exact request. If the system cannot explain which call was approved and why, the delegation model is too coarse for safe agent use.

Practitioner Guidance

What to prioritise: Treat per-invocation authorization as the default for any agent action that can read, modify, transmit, or delete data. Connection approval is only the onboarding step; it is not sufficient evidence that later tool use is still within user intent.

What to verify: Confirm that the policy decision point is evaluated at the moment of tool use, that scopes are narrow enough to map to individual actions, and that revocation or policy change takes effect without waiting for a new connection.

Common mistake: Teams often secure the connector and assume the workflow is safe. The weak point is usually not the initial connection, but the unchecked tool call that happens later under the cover of an already-valid session.

What good looks like: Each tool invocation can be explained, authorised, and audited as a discrete decision, with the user’s approval reflected in the exact action being attempted rather than in a broad standing allowance.

Practitioner takeaway: If the agent can decide which tool to call later, authorization must be decided later too, otherwise you are governing access by memory instead of by the real request.

Related resources from NHI Mgmt Group

• What is the difference between filtering MCP tool listings and checking permissions at invocation time?
• What is the difference between human identity governance and AI agent governance?
• When does just-in-time access reduce risk for agentic AI, and when does it fall short?
• When does AI agent access create more risk than it reduces?