MCP Security and Authorization: OAuth, Permissions, and Approval

MCP security is not one switch. A secure Model Context Protocol integration combines transport security, client authorization, tool permissions, user consent, payload validation, and controls around consequential execution. OAuth can let a client reach an MCP server; it does not automatically mean every requested tool call should run.

The most useful design separates three decisions:

1. Connection authorization: may this client access this MCP resource?
2. Tool authorization: may this identity invoke this tool on this resource?
3. Operation approval: should this exact high-impact call execute now?

MCP authorization and human approval solve different problems

MCP authorization is defined at the transport boundary for HTTP-based servers and is based on OAuth. Human approval belongs closer to the side effect, where the system has the actual tool name, arguments, environment, and risk context.

That distinction prevents two dangerous shortcuts:

• “The token is valid, so every tool call is approved.”
• “A human clicked approve, so the client may exceed its existing permissions.”

Approval must never expand the caller's authorization. Execute with the same scoped machine identity after the decision.

Build the security layers explicitly

The MCP specification warns against token passthrough: an MCP server should not forward a token it received from a client to an unrelated downstream API. Obtain a separate downstream credential with the correct audience and privileges.

Use allow, ask, and deny at the tool boundary

A small policy makes the execution rule visible:

mcp_tools:
  inventory.read: ALLOW
  deployment.promote: ASK
  payment.refund: ASK
  customer.delete_all: DENY

defaults:
  unknown_tool: DENY
  approval_timeout: DENY
  changed_arguments: ASK_AGAIN

This is a conceptual policy, not an Actionbox server configuration. Enforce it in the client, gateway, or local wrapper that controls access to the downstream MCP server.

Actionbox's publicly documented MCP integration gives an MCP-capable agent two human-input tools: ask_human creates a durable Action and get_action retrieves its typed state. The agent can use the returned answer in its workflow, but this is not an automatic security proxy around every other MCP server. If policy must make bypass impossible, enforce allow, ask, and deny in the application or gateway that owns the downstream tool call.

Connect the public Actionbox MCP bridge

Install the public CLI, store a Source key in its protected local configuration, and verify the hosted API connection:

python -m pip install actionbox
actionbox configure
actionbox doctor

Then configure an MCP host to launch the local stdio bridge:

{
  "mcpServers": {
    "actionbox": {
      "command": "actionbox",
      "args": ["mcp"]
    }
  }
}

The bridge connects to Actionbox's hosted MCP service. The Source key remains in the CLI's owner-only configuration instead of being copied into the JSON-RPC stream or a chat. This is the supported public installation path today; shell installers, Homebrew, direct binary downloads, self-hosting, and a universal hosted MCP policy proxy are not public product options.

Test the boundary, not only the connection

Use a disposable Source and a harmless operation first:

1. Ask the agent to call ask_human with a bounded question and two unambiguous choices.
2. Confirm that the Action appears in the hosted inbox and remains open if the client disconnects.
3. Resolve it in the dashboard, then have the agent call get_action for the returned Action ID.
4. Confirm that rejection, expiry, a malformed response, or an unavailable API prevents the side effect.
5. Rotate the disposable Source key and verify that the old bridge can no longer create Actions.

This exercise proves the human-input path. It does not prove that another MCP server is impossible to call directly; that enforcement belongs at the tool boundary you control.

Protect credentials and capability URLs

• Keep Source keys in the runner's protected secret store.
• Do not paste keys into chat, project files, logs, screenshots, or command arguments.
• Prefer a local bridge that reads owner-only configuration when the MCP host can launch a command.
• For remote HTTP, inject the credential through the host's supported secret mechanism.
• Do not include access tokens in URLs or query strings.
• Redact credentials and customer secrets before tool arguments become review context.

A human reviewer needs enough information to judge the operation, not every byte available to the agent. Show the tool, affected resource, environment, impact, reversibility, and a safe summary of the arguments.

Bind approval to the exact tool call

If arguments can change after approval, the approval is not a meaningful control. Use a stable tool-call identity and bind the review to the current operation snapshot.

For an Actionbox-backed review:

1. Build sanitized context from the exact tool call.
2. Create one Action using a stable idempotency identity.
3. Set a bounded server-side expiry.
4. Treat rejection, expiration, API failure, and malformed response as denial.
5. Re-read the authoritative Action when execution is delayed.
6. Refuse a stale version or fingerprint.
7. Execute with the caller's existing downstream permissions.
8. Report the real success or failure afterward.

An Actionbox decision receipt can prove which Action snapshot was resolved. It does not prove the MCP tool succeeded, so keep the execution outcome separate.

MCP security review checklist

• Remote traffic uses HTTPS.
• Tokens are validated for the intended MCP resource.
• Downstream APIs receive separate, correctly scoped credentials.
• Unknown tools default to deny.
• Tool arguments have strict schemas and size limits.
• High-impact operations are classified before execution.
• Review context excludes credentials and unrelated private data.
• Approval is bound to stable tool-call identity and current arguments.
• Rejection and timeout fail closed.
• Retries do not create duplicate reviews or duplicate side effects.
• Execution outcomes and rollback are recorded separately from approval.

When MCP-native consent is enough

Use the MCP host's built-in consent UI when the person using the host is also the authorized reviewer, the operation is immediate, and the host reliably displays the exact call. Add a durable external decision when approval must survive a disconnected client, route to another person, expire on the server, appear in workspace history, or correlate with a later execution outcome.

These controls can complement each other. Avoid forcing every harmless tool call into an external inbox; reserve durable review for operations where policy or organizational responsibility requires it.

Sources and further reading

• MCP Authorization specification — OAuth discovery, resource indicators, audience restriction, token handling, and protected resources.
• Model Context Protocol security best practices — token passthrough, confused-deputy, session, and local-server security guidance.
• Actionbox MCP server guide — the current public CLI bridge and credential boundary.
• AI agent governance — policy classification, human review, and outcome evidence beyond the MCP transport.

Create a free Source · Connect Actionbox through MCP · Read the MCP server guide