Authentication
Identify the customer an AI agent is acting for using a customer key or your existing OAuth sign-in flow.
MCP tools can be public or require an identified customer. When customer authentication is required, Mitu needs to know which customer the AI agent is acting for before the operation can be used.
You can identify customers using a Mitu customer key or your existing OAuth identity provider. Both approaches establish customer context for the connection, but they differ in how the customer receives and proves that identity.
Authentication methods
You can support the method that fits your product, and protected endpoint definitions use requires_auth to indicate that customer identity is required.
Customer keys
When you create a customer through the Customer API, Mitu can return an mcpk_... customer key associated with that customer. The customer provides this credential to a compatible AI client when connecting to your MCP endpoint.
Where supported, the credential can also be supplied as a bearer token.
A customer key authenticates one customer to the MCP connection. It is different from the merchant API key your backend uses to call the Mitu API and does not give the customer access to your Mitu account or administrative wallet operations.
sk_test_... and sk_live_... are server-side credentials for your business. mcpk_... identifies an individual customer connecting through MCP. Never provide a merchant API key to a customer or place it in an AI client.
See Customer keys for the customer credential lifecycle.
OAuth
OAuth lets customers connect through the identity system your product already uses. Instead of receiving a separate customer credential, the customer adds your MCP endpoint to a compatible AI client and signs in using their existing account.
Mitu participates in the OAuth flow required by the AI client and associates the authenticated identity with the corresponding customer record. Once the customer is signed in, protected tools become available in the context of that customer.
When Mitu forwards a protected operation to your API, the signed-in customer’s access token can also be forwarded so your existing backend continues applying its normal authentication, authorisation and entitlement rules.
OAuth therefore identifies the customer without replacing your application’s own access-control model. Your backend remains responsible for deciding what the authenticated customer is allowed to do.
See OAuth for customer identity and Customers for the customer model.
Public and protected tools
Use requires_auth on an endpoint to determine whether customer identity is required.
Public operations are useful for capabilities that do not depend on a customer account, such as retrieving publicly available information. Protected operations should be used when your API needs to know which customer is making the request or when the operation depends on account-specific data or permissions.
Authentication should reflect the requirements your product already has rather than making every MCP tool protected by default.
Authentication and request verification
Customer authentication and request verification solve different problems. Customer authentication tells your application who the AI agent is acting for, while request verification tells your backend whether the request actually came through Mitu.
When your API receives a customer-aware request, verify the Mitu request before trusting Mitu-specific customer context. If OAuth is used, continue validating and authorising the forwarded customer access token according to the same rules your backend already applies.
See Request verification for the request verification contract.
Choosing an authentication method
Customer keys are useful when your business explicitly provisions AI access and wants to issue a credential directly to a customer. OAuth is usually a better fit when customers already have accounts and should connect through the same sign-in experience they use elsewhere in your product.
Both methods ultimately provide customer identity to protected tools. The choice does not require you to rewrite the underlying API operations you make available through MCP.