How to expose your APIs to AI agents without handing over the keys

You have an orders, billing or inventory API, well documented and in production. Now you want an AI agent to use it. The quick route is to give it a service token and let it call away. The problem is that the token cannot tell reading an order from deleting it: the agent can do anything the token allows, and it will if someone manages to slip it the right instruction.

With Ploybot the API is not handed over whole. You publish specific operations, each with its own policy, and the agent sees them as tools over MCP. The credential never leaves the gateway.

1. Connect the destination

First, tell Ploybot where the API lives and how it authenticates: base URL and credential. It can be a token, a username and password, an API key in a header or query string, or a delegated OAuth login if the API requires one. The credential is stored encrypted and only the gateway resolves it, at call time.

When you add it, Ploybot checks the connection. A destination that does not answer shows up right then, not when the agent is halfway through a task.

2. Import its contract

You do not need to describe the operations by hand. Ploybot reads the contract you already have:

• OpenAPI 3, in YAML or JSON, pasted or downloaded from the destination itself.
• The WSDL of a SOAP 1.1 service.
• The FileDescriptorSet of a gRPC service.
• The tools of a third-party MCP server.

Importing proposes; it does not create anything. You will see each operation with the arguments it will ask for and the policy that would apply, and who decided it: the API owner, or Ploybot by default.

ploybot alta openapi --conexion=conn_orders --url=https://api.yourcompany.com/openapi.json --prefijo=orders

3. Review and publish, one by one

Publishing happens by name. There is no “publish all”, because that step is the review: someone in your organisation chooses what an agent may touch.

If the API maintainer wants to get ahead, they can mark it in the OpenAPI itself with the x-agent extension:

x-agent:
  expose: true
  capability: {name: payments.execute}
  constraints: {maxAmount: 500}
  approval: {requiredAbove: 100, parameter: amount}

That reads: propose publishing it, deny any amount above 500, and let a person decide anything above 100. Without x-agent, the default is conservative: reads (GET) are allowed and everything else requires approval. Always in that direction, never the other way round.

The capability writes the request, not the agent

This is the key point. The agent does not compose HTTP: it does not choose the method, the path or which fields go in the body. That was fixed at publishing time. The agent only fills in the blanks, and Ploybot validates them against the schema and escapes them according to where they go: a value in the path cannot escape its segment, and a number has to be a number.

A published operation is therefore far narrower than “access to the API”: it is POST /orders/{order_id}/refunds with an amount up to a limit, and a person in front of it above a threshold.

4. Try it before handing it to anyone

From the console (Try) or with ploybot invocar, you can call the published operation and see the destination’s real response, without going through an agent. That way you check the setup is right before anyone uses it.

5. Assign it to an agent

When you assign the capability to an agent, it appears in its tools/list the next time it asks. Each tool says which connection it belongs to, so the model does not mix identifiers from one API with another’s. And every call leaves its record: what was asked, which policy applied, who approved it, what reached the destination and what it answered.

What if the API lives inside your network?

For APIs that cannot be exposed to the Internet, the gateway runs inside your network or cloud account. It calls the control plane, never the other way round, so you do not have to open any inbound port. It executes HTTP, SOAP, gRPC and MCP, and resolves credentials where it lives: the control plane only stores references.

Start with one

The best way to see it is with a read operation from an API you already have. The Ploybot trial lasts 14 days and needs no card. If you would like to do it together, write to us through the contact form.