Overview

Slash API keys let external systems, developers, automation tools, and MCP-compatible AI clients access your Slash account through the Slash API. Depending on the scopes assigned to a key, that access may include reading balances and transactions, managing cards, moving funds, or taking other actions available through the API.

Because API keys can grant access to sensitive financial data and workflows, you should manage them like passwords or other production secrets. This guide explains how to keep API and MCP access secure over time: rotating keys, revoking old access, applying least-privilege permissions, monitoring usage, and responding quickly if a key is leaked.

API keys and MCP access

Slash hosts an MCP server at https://mcp.slash.com that lets compatible AI clients connect to Slash using the Model Context Protocol. MCP access uses a Slash API key for authentication.

This means an AI client connected through MCP can only do what its API key allows. If a key can only read balances, the MCP client can only read balances. If a key can create cards or move funds, the MCP client may be able to take those actions when asked.

For that reason, every MCP client should use a dedicated API key with only the scopes it needs.

Use least-privilege access

Least privilege means giving each key the minimum permissions required for its purpose.

Instead of creating one broad API key for every tool, create separate keys for separate use cases. For example:

A reporting tool may only need read-only access to balances and transactions.
An accounting sync may need transaction, account, and export-related scopes.
A card automation tool may need card-management scopes, but not transfer scopes.
An MCP client used for analysis may only need read access.
An MCP client used for operations may need broader access, but should still be limited to the actions users actually intend to perform.

Avoid granting write, transfer, card-creation, or administrative scopes unless the integration truly requires them.

Create separate keys for separate tools

Do not reuse the same API key across multiple systems. A separate key for each tool makes it easier to understand what each integration is doing and revoke access safely if something changes.

Use descriptive names when creating keys, such as:

QuickBooks sync
Internal reporting dashboard
Claude Desktop MCP
Cursor MCP - read only
Vendor payout automation
Production app server
Staging test environment

Avoid vague names like test, new key, or API key, especially in production accounts.

Store API keys securely

API keys should only be stored in secure systems designed for secrets.

Do

Store keys in a secrets manager, encrypted environment variable store, or secure production configuration system.
Restrict access to the people and systems that actually need the key.
Use different keys for development, staging, and production.
Keep keys out of screenshots, tickets, Slack messages, shared docs, and public logs.

Do not

Commit keys to GitHub or any other code repository.
Hardcode keys in frontend code, mobile apps, browser extensions, or public websites.
Share keys over chat, email, or support tickets.
Put keys in URLs unless your MCP client has no other authentication option.

When using MCP, header-based authentication is preferred when your client supports it. Passing keys in a URL query parameter can cause the key to appear in browser history, proxy logs, or application logs.

When to rotate an API key

Rotating a key means replacing an existing key with a new one, updating the integration to use the new key, and then disabling or deleting the old key.

Rotate a key when:

A team member, contractor, or vendor with access leaves.
A key may have been exposed in a repository, log, screenshot, message, or support ticket.
You are changing the scopes or purpose of an integration.
A tool is moving from testing to production.
A vendor no longer needs the same level of access.
Your internal security policy requires periodic key rotation.

You should also rotate keys for any MCP client that is no longer actively used or is installed on a device you no longer control.

How to rotate an API key safely

To avoid downtime, rotate keys in this order:

Create a new API key with the same or narrower scopes than the old key.
Update the integration or MCP client to use the new key.
Test the connection by confirming the tool can still perform the expected actions.
Monitor for errors in the integration after the change.
Revoke the old key once the new key is working.

If possible, reduce scopes during rotation. For example, if an old key had broad access but the integration only reads transactions, create the replacement key with read-only transaction access.

Revoke access you no longer need

Revoking a key removes that key’s access to Slash. Revoke keys that are unused, unnecessary, too broad, or potentially exposed.

You should revoke a key when:

The integration is retired.
A vendor or contractor no longer needs access.
An employee who used or managed the key leaves the company.
A test project is complete.
A key was accidentally shared or committed.
You cannot identify what a key is used for.

Before revoking a key, check whether any production system still depends on it. If you are not sure, rotate first: create a replacement key, update the integration, confirm it works, then revoke the old one.

Review API and MCP access regularly

Set a regular schedule to review API keys and MCP connections. For many teams, a monthly or quarterly review is a good starting point.

During the review, check:

Which API keys exist.
What each key is named and used for.
Which scopes each key has.
Whether each key is still needed.
Whether any key has broader permissions than necessary.
Which vendors, tools, AI clients, or internal systems rely on each key.
Whether any key belongs to a former employee, contractor, or retired system.

If you cannot explain what a key is used for, revoke it or rotate it into a clearly named replacement.

Monitor usage and unexpected activity

Monitoring helps you catch misconfigured tools, unused keys, and possible abuse.

Depending on the visibility available in your Slash dashboard and internal systems, watch for:

API requests at unusual times.
Unexpected spikes in API usage.
Requests from systems, vendors, or IPs you do not recognize.
Failed authentication attempts.
Permission errors that suggest a tool is trying to do more than expected.
Unexpected card, transfer, account, or webhook activity.
MCP clients making calls unrelated to the user’s request.

For critical integrations, you should also log activity in your own system. Record which internal service made the request, what it attempted to do, whether it succeeded, and which user or workflow triggered it.

What to do if an API key is leaked

If you believe an API key was exposed, act quickly.

Revoke the exposed key immediately. Do not wait to confirm whether it was used. Once a key is public or shared with the wrong person, treat it as compromised.
Create a replacement key if the integration still needs access. Use the minimum required scopes. Do not simply recreate a broad key with the same permissions unless those scopes are truly necessary.
Update the affected integration or MCP client. Replace the old key with the new key in your secrets manager, server config, or MCP client settings.
Review recent activity. Look for unexpected API calls, card changes, transfers, account changes, webhook changes, or other actions that may have occurred while the key was exposed.
Check where the key leaked. Remove it from code, logs, chat messages, documentation, screenshots, CI output, or config files. If it was committed to a repository, remove it from the current code and follow your internal process for handling secrets in Git history.
Notify your internal team and contact Slash support if needed. If the key had access to move funds, issue cards, view sensitive financial data, or perform other high-risk actions, contact Slash support so we can help review the situation.

Special considerations for MCP clients

MCP clients can make API calls on your behalf through an AI interface. This is powerful, but it also means access should be tightly controlled.

When connecting Slash to an AI client through MCP:

Create a dedicated key for each client.
Use the narrowest scopes that support your intended use case.
Prefer read-only access for analysis and reporting workflows.
Avoid giving broad write or money-movement access to general-purpose AI clients unless you have a clear operational need.
Remove MCP connections from devices you no longer use.
Revoke the key if you uninstall the client, lose the device, or stop using the workflow.
Be careful when pasting sensitive financial data into any third-party AI client.

If multiple team members use MCP, each person or device should use its own key where possible. Shared keys make it harder to understand who performed an action and harder to revoke access cleanly.

Best practices checklist

Use this checklist to keep API and MCP access safe:

Create one API key per tool, client, environment, or vendor.
Name keys clearly so their purpose is obvious.
Grant only the scopes each integration needs.
Store keys in a secure secrets manager or protected configuration system.
Never commit keys to code or share them in chat.
Prefer MCP header authentication over URL-based authentication.
Rotate keys when people leave, vendors change, or exposure is suspected.
Revoke unused, unknown, or retired keys.
Review API keys on a regular schedule.
Monitor for unusual activity and unexpected permission errors.
Treat leaked keys as compromised and revoke them immediately.

Need help?

If you are unsure whether a key is safe to revoke, whether a key was exposed, or whether recent activity looks suspicious, contact Slash support. Include the key name, the affected integration, the approximate time of the issue, and any activity you want reviewed. Do not send the API key value itself.

Managing API Keys and MCP Access in Slash