Your customers' agents
Your customers are starting to use AI assistants that act for them: they ask the assistant to find a flight, change a booking or check an order. Gatelion lets those assistants use your services through a Gateway, under your policy, with each customer signed in with your own login and confirming what matters.
What it is
Say you run a flight-booking portal. A customer asks their assistant, such as Claude, to book the cheapest morning flight to Cairo. With customer access set up:
- the assistant connects to your Gateway's MCP address;
- the customer signs in with your login and allows that assistant to act for them;
- your policy decides what the assistant may do: search freely, but book only after the customer confirms;
- when it books, the customer confirms the exact booking on a page that shows every detail;
- your booking API is told which customer each call is for, in a signed header it can check.
Your passwords and customer accounts stay where they are. Gatelion never sees a customer's password.
How it differs from your own agents
Most of Gatelion works the same way for both: tools, policies, approvals, the audit trail. What changes is who the agent works for and how it gets in.
| Your own agents | Your customers' agents | |
|---|---|---|
| Who builds or runs them | Your organization | Your customers, or the companies that make their assistants |
| How they connect | An agent token (agt_…) you issue | The customer signs in with your login and gives consent (OAuth) |
| Who they act for | A staff member named in X-Gatelion-On-Behalf-Of | The customer who signed in; the header is ignored |
| Gateway | Hosted, or in your network | Hosted by Gatelion, set up for customers' agents |
| Who approves | Approvers in your organization | The customer, your approvers, or both, as your policy says |
| Who your API sees | Optionally, the staff member | The customer as your login knows them, in X-Gatelion-Identity |
A Gateway serves one kind or the other. Agent tokens don't work on a Gateway for customers' agents, and customers can't sign in on a Gateway for your own agents.
What you need
- An OpenID Connect login for your customers, such as Auth0, Microsoft Entra ID, Okta, Keycloak or Google, or your own. You register Gatelion with it as a web application.
- Admin access to your Gatelion organization. Customer access is in the console menu for admins.
- Hosted Gateways available to your organization. If they aren't, the Customer access page says so.
- An API reachable from the internet, with its API key or other sign-in. Gatelion builds the tools from its OpenAPI description, or from the operations you describe in the console if it has none. A hosted Gateway can't reach private networks.
The flow, end to end
- You set it up once. On Customer access you enter your login settings. You add a Gateway hosted by Gatelion for customers' agents, connect your API to it, turn on the tools customers' agents may use, and write the policy. See Set up customer access.
- You publish the MCP address. The Gateway's MCP address is shown on Gateways and Customer access. Give it to agent makers, or put it on your website for customers.
- An agent registers. The first time an assistant connects, it registers itself with Gatelion. Depending on your settings it can be used at once, or waits until you approve it on Customer access.
- The customer signs in and allows it. The assistant opens your login in the browser. After signing in, the customer sees a consent page that lists the tools the agent will be able to use, and chooses Allow. That permission stands until it's withdrawn.
- The agent calls tools. Every call is checked against your policy, like any other agent's. Calls the policy allows run at once.
- The customer confirms what matters. For calls your policy marks for the customer's confirmation, the agent gets a link. The customer opens it, signs in again, checks every value and chooses Confirm or Don't do it. Only then does the call run, once. See What your customers see.
- Your API learns who it's for. If you turn it on, every request to your API carries an
X-Gatelion-Identityheader naming the customer as your login knows them. See Verify the identity header. - You stay in control. On Customer access you see every agent that registered and every customer who allowed one. You can block an agent or withdraw a customer's permission at any time. Customers can withdraw their own permissions too, on a page you link to from your site.
Every step is recorded in the same audit trail as your own agents' calls.
Next: Set up customer access
Still stuck? Contact support from the console.