Who should decide whether an agent, MCP server, or tool is approved, under review, or blocked?

Security should own the policy, but the process should be operational enough for developers to keep working. A good model lets security define approval criteria, review queues, and block conditions, while users can temporarily allow with monitoring, restrict to read-only, or hold pending review. Accountability sits with security, governance, and the owning team together.

Why This Matters for Security Teams

Approval decisions for agents, mcp server, and tools are really decisions about who can create new execution paths in the environment. That makes the question less about procurement and more about runtime risk, blast radius, and revocation. When governance is vague, developers will connect the fastest available tool, while security only learns about it after secrets move, data is exposed, or an agent chains actions into a higher-impact workflow.

The risk is especially clear in MCP. NHIMG’s The State of MCP Server Security 2025 found that 53% of MCP servers expose credentials through hard-coded values in configuration files, which turns “temporary” integrations into durable compromise paths. For agentic systems, the concern is not just access, but autonomous use of access. That is why guidance from OWASP Agentic AI Top 10 and the NIST AI Risk Management Framework both point toward explicit governance, traceability, and risk-based controls rather than informal developer discretion. In practice, many security teams encounter unsafe tool approvals only after an agent has already used them in production.

How It Works in Practice

The cleanest operating model is a three-way split: security defines the approval policy, the owning team explains the business need and technical design, and platform or governance workflows enforce the decision. Approval should not mean a human manually rubber-stamps every request. It should mean the request is evaluated against predefined criteria such as data sensitivity, tool scope, authentication method, logging coverage, revocation support, and whether the integration can run with least privilege.

For agents and MCP servers, the decision usually needs to happen at two levels. First, a registration or intake review decides whether the agent, server, or tool is allowed into the ecosystem at all. Second, runtime policy decides whether a specific action is approved, read-only, temporarily allowed with monitoring, or blocked. That is where context matters: the same tool might be acceptable for read operations but not for writes, credential access, or lateral movement. This approach aligns with current guidance in the CSA MAESTRO agentic AI threat modeling framework and with NHIMG’s analysis in OWASP Agentic Applications Top 10, which both emphasize runtime control and explicit trust boundaries.

• Security owns the policy: approval criteria, block conditions, and escalation paths.
• The owning team documents the tool’s purpose, data access, and failure modes.
• Runtime enforcement should record who approved, what was allowed, and for how long.
• Temporary allowances should be monitored, time-bound, and revocable.

For deeper examples of what goes wrong when control is deferred, NHIMG’s CoPhish OAuth Token Theft via Copilot Studio shows how weak governance can turn an integration choice into a token theft path. These controls tend to break down when tool approvals are handled as ticket comments or ad hoc chat approvals because there is no reliable enforcement trail.

Common Variations and Edge Cases

Tighter approval controls often increase delivery overhead, requiring organisations to balance speed against exposure. That tradeoff becomes sharper when teams are experimenting with many short-lived agents, MCP connectors, or internal tools that change weekly. Current guidance suggests that low-risk read-only tools may deserve a lighter review path, while any tool that can write data, invoke external systems, or handle secrets should face stricter approval and continuous monitoring.

There is no universal standard for this yet, especially for research sandboxes, developer preview environments, and delegated approval by non-security owners. Some organisations let platform teams pre-approve safe tool patterns, while security only reviews exceptions. Others use a tiered model where the request is “approved,” “approved with restrictions,” “under review,” or “blocked,” based on data class and execution scope. The important point is consistency: the label must map to a real enforcement outcome, not just a badge in a portal.

For broader context on why blind trust is no longer acceptable, NHIMG’s AI Agents: The New Attack Surface report shows how often agent behavior already exceeds intended scope, and the NIST AI Risk Management Framework reinforces that governance needs accountability, monitoring, and ongoing evaluation rather than one-time approval. In highly dynamic environments, the policy still belongs to security, but the operational decision often needs a shared workflow with the owning team and platform controls.

Related resources from NHI Mgmt Group

• What breaks when MCP tools are approved at the server level but not at the tool level?
• How do security teams decide whether an MCP agent has too much access?
• How do teams decide who is accountable for MCP server access and tool use?
• How should organisations decide whether to keep an MCP tool or remove it?