Meow MCP security: human approval and least-privilege scopes

The Meow MCP server gives AI assistants access to financial data and actions. An assistant can read what your role permits and draft payments you must approve. It can’t do anything beyond that.

​

Human-in-the-loop approvals

MCP transfer tools never move money. When an assistant calls create_ach_transfer, create_scheduled_ach_transfer, create_wire_transfer, create_book_transfer, or create_crypto_transaction, Meow records the payment as a draft in a pending-approval state. Funds move only after a person approves the draft on the Meow dashboard. The server enforces this, not the client:

• Every MCP-initiated transfer is forced into pending_approval, no matter which assistant or surface created it.
• The tool returns an approval reference. The assistant can check status with get_approval, but it can’t approve on your behalf.
• Approval happens on the dashboard, by someone with the authority to approve it.

Two independent layers of human control apply. The first is this server-side draft model, built into Meow. The second is client-side: because every action tool is annotated as destructive (see Tool annotations), MCP clients can prompt you to confirm a call before it runs. In Claude, team and enterprise admins can set each connector permission to Always allow, Needs approval, or Blocked.

​

Least privilege

Access is scoped as narrowly as possible at every layer. Scopes are granted per capability. Because meow.read, meow.transfers, meow.cards, and meow.billing are independent, you can connect an assistant for read-only insights and never grant write access at all. See scopes. The scope picker only offers optional write scopes if your role could exercise them somewhere, and role permissions cap every call regardless of what you grant. On the CLI surface, the same idea applies to API keys: give the assistant a key with only the scopes it needs.

​

What’s checked on every tool call

The server re-validates each call independently. A valid token on its own is not enough. It confirms the token’s signature, expiry, and audience (the token must have been issued for this server), your role’s permissions on the target entity, the OAuth scopes you granted at connect time, the entity’s lifecycle, the session’s revocation status, and any multi-factor requirement.

​

Tool annotations

Every tool carries an MCP annotation so clients can render the right warning UI. Read tools are marked readOnlyHint: true and idempotentHint: true; action tools are marked destructiveHint: true. That lets a client confirm before any state-changing tool runs, and it lets directory reviewers and admins see at a glance what each tool does.

​

Prompt-injection awareness

Agentic systems that read untrusted content (web pages, emails, documents) can be steered by malicious instructions hidden in that content. A few things contain the risk here:

• Even a successful injection can’t move money, because transfers are drafts that wait for human approval on the dashboard.
• A read-only connection can’t be coerced into a write, so grant only the scopes the task needs.
• Running the Meow MCP alongside other MCP servers in one session widens the attack surface, so be cautious about it and review the actions an assistant proposes before approving them.

​

Auditability

Every tool invocation is logged with enough context to reconstruct it: the authenticated identity, the tool name, the parameters (with sensitive values redacted), the timestamp, the result status, and the duration. Each response also carries a request ID you can share with support. OAuth sessions are tracked, so you can list the assistants you’ve connected and revoke any of them from the dashboard. Revocation takes effect immediately.

​

Data handling

• The MCP server reaches the same financial data as the REST API, scoped to your permissions.
• Prefer OAuth over long-lived API keys for interactive use, and keep API keys out of any file you commit.

​

Next steps