Teams should require explicit runtime approval before new tools or MCP servers are added to an agent’s effective capability set. That approval should be tied to the live session, not just the original deployment, because the security risk appears when the agent can expand reach without interruption. Governance must follow the point of capability change.
Why approval has to happen at the moment capability changes
Approval should be treated as a runtime control, not a one-time onboarding formality. For an agent, the meaningful security boundary is the moment a new tool or MCP server becomes reachable, because that is when the effective authority set changes and new data paths, actions, and trust relationships become possible. If approval is detached from that moment, governance becomes stale.
That timing matters most in agent workflows where tool access is dynamic. A session can start safely and still become risky later if the agent discovers a new server, inherits a new connector, or is pointed at a different environment. The governance question is therefore not “was this ever approved?” but “is this capability approved right now, in this live context?”
For MCP specifically, the approval point should reflect the exact server and transport characteristics in use. A server that only exposes read-only context is not the same as one that can accept delegated actions, and a local development server is not the same as a remote service with broader reach. The MCP authorization specification is useful here because it frames servers as resources that should be explicitly authorized rather than implicitly trusted.
What a useful approval workflow should actually control
Good governance separates discovery, authorization, and execution. The agent can detect that a new tool or MCP server is available, but it should not be allowed to use it until the session-level approval gate has been satisfied. That gate needs to be tied to the live transaction, so the decision applies to the specific tool, the specific server, and the specific request context, not to a vague class of “approved integrations.”
Teams should also define whether approval is per tool, per server, per action, or per scope. The narrower the approval, the easier it is to reason about blast radius. In practice, a broad approval like “allow all MCP servers from this workspace” is much weaker than approving one server for one purpose with bounded permissions and observable activity.
This is why capability governance and authorization should be aligned. The agentic security question is not only whether a tool exists, but whether the tool can expand what the agent can do in a way the operator would not expect. OWASP Agentic AI Top 10 is relevant because it highlights identity and privilege abuse, tool misuse, and other failure modes that arise when agent authority grows without tight control.
That same logic applies to MCP servers. An approved tool that becomes overbroad later, or a newly attached server that inherits too much trust, changes the security posture even if the original deployment was clean. Governance must therefore follow the effective capability set, not just the deployment record.
How teams should make the approval decision operationally
Practitioners should approve new tools and mcp servers only after they can answer three questions: what the tool can do, what data or systems it can reach, and whether the current session should be allowed to exercise that reach. If any of those answers is unclear, the safe default is to block until the capability is understood and explicitly authorised.
What to verify: Confirm that approval is bound to the session and not cached across unrelated runs, environments, or users. Confirm that the server identity, requested scope, and available actions match what the operator expected at the moment of approval.
Decision rule: If adding the tool or MCP server increases the agent’s reachable systems, writable actions, or data visibility, require a fresh approval decision before first use. If the change is only cosmetic or administrative, you may not need a new gate, but you still need traceable evidence that no new authority was introduced.
Common mistake: Treating installation, registration, or pre-approval as sufficient. That pattern breaks down when the actual risk appears only after the agent can invoke the capability in a live session, especially in environments where tools can be added dynamically.
Practitioner takeaway: The approval control should protect the point where authority expands, not the point where the software was deployed.
Risk and Threat Considerations
When approval is not tied to the live capability change, agents can silently accumulate reach and create a larger blast radius than the operator intended. That turns a routine tool addition into a trust-boundary problem, especially when a new server can read context, trigger actions, or relay credentials and tokens through the session.
Failure mechanism: The environment assumes a prior approval still covers a newly reachable tool or server, so the agent is allowed to act before anyone reassesses whether the new capability should be trusted. That can expose data, expand permissions, or create an unexpected action path.
Impact: A single session can move from limited assistance to high-impact access, with consequences ranging from data leakage to unauthorized system actions and harder incident containment.
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 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 | Live approval controls agent authority expansion and privilege growth. |
| ASI02 — Tool Misuse | New tools and MCP servers are a direct tool-access governance issue. | |
| Recommendation — Require a fresh approval gate whenever an agent's effective authority expands. Approve each new tool and server before the agent can invoke it. | ||
| OWASP API Security Top 10 | API5 — Broken Function Level Authorization | Approval must prevent functions from becoming callable without explicit permission. |
| API8 — Security Misconfiguration | MCP server trust can fail when capability exposure is configured too broadly. | |
| Recommendation — Enforce function-level authorization for newly added capabilities. Tighten server configuration so new capability exposure requires explicit approval. | ||
| NIST SP 800-53 Rev 5 | AC-3 — Access Enforcement | Runtime approval is an access-enforcement decision for newly reachable tools. |
| Recommendation — Enforce access decisions at the moment a tool or server becomes reachable. | ||
Practitioner Guidance
What to prioritise: Bind approval to the live session and the exact capability delta. For MCP in particular, treat each newly reachable server as a distinct trust decision unless you can prove it is functionally equivalent to an already approved scope.
What good looks like: Operators can see which tools and servers were approved, for how long, and for what bounded purpose. The agent cannot silently widen its authority without a fresh, visible decision point.
What to measure: Track how often new tools or servers are introduced mid-session, how often approval is refreshed, and how often requests are blocked because the capability change was not explicitly accepted. Those signals tell you whether governance is actually attached to runtime authority.
Practitioner takeaway: If you cannot show exactly when the agent gained a new capability, you cannot claim the capability was governed.