Give your team's AI clients access to an internal API

An internal API, such as a back office or an admin service, can be published to the AI clients your team already uses. Each person signs in as themselves, writes wait for their approval, and every call is recorded.

For the steps on a sample API, see Publish your API as an MCP server.

Describe the API

Analyze the API from its code, then read what the analysis wrote before anyone can call it.

1. Create an API and run the analysis.
2. In the Operations tab, check the kind of each operation and which ones require confirmation. The analysis flags the destructive ones. Add the flag to any write your team should see before it runs. See Mark an operation as requiring confirmation.

Give Faustine its own account

A connection holds where the API runs and the credentials Faustine uses to call it. Create a dedicated account for Faustine in your API, with the permissions you want the gateway to have at most. Do not use a person's account: logins protected by a second factor are not supported, and every call would appear in your API's own audit trail as that person.

1. Add a connection for a staging deployment first, and test it.
2. Add a second connection for production and turn on Production connection. Tests never run against it.

Every person who connects through the gateway reaches the API with this one account. What each person can do is decided in the gateway, in the next two sections.

Serve a part of the API

Create a gateway for the API and expose only what the team needs. An operation that is not exposed does not exist for a client.

1. Create a gateway.
2. Choose which operations are exposed. Starting with the read operations and adding writes later is a safe order.

One user for each person

Create a gateway user for each person, not one shared user. Logs then show who made each call, and you can remove one person without touching the others.

1. Create a gateway user for each person and send them their username and password.
2. Scope the user if some people should reach fewer operations than the gateway serves.
3. Use an API key only for automations and scripts. See Create an API key.

Decide how writes are confirmed

A user created in the New Gateway wizard is set to Ask the person: an operation that requires confirmation waits until the person approves it in their client. A user created later in the Access tab starts on Refuse.

Whether a person can approve depends on their client. claude.ai, Claude Desktop and ChatGPT show a confirmation card, and Claude Code asks in a dialog. Cursor and VS Code cannot ask, and for a user set to Ask the person the gateway refuses the operation in those clients.

See Confirmation and Set how a credential confirms writes.

Connect the clients

Each person adds the gateway's MCP URL to their client and signs in with their gateway user. The Connect tab has the steps for each client with your URL filled in. See Connect clients.

Keep the record clean

Every request is in the gateway's Logs tab with who made it, what it called and what your API answered.

• If requests or responses carry personal or secret values, add redaction rules before the team starts. See Redact sensitive fields.
• Set how long requests are kept. See Set recording and retention.
• If the API should be reachable from your office or VPN only, see Restrict access by IP address.

Checklist

Next steps

• Limits and quotas: cap what a user or key can do in an hour or a day.
• Environments: serve staging and production from the same gateway.
• Faustine Chat: give the team a chat app that is already connected to the gateway.