AI Gateway

The AI Gateway

Several platform features use a language model. The gateway is where you say which provider each of them uses, so the choice is configuration rather than something baked into each feature.

Where to find it

Architect Panel → Data:

• AI Builder — one of the features that uses it
• Query Builder — another consumer

Architect Panel → Integration & Connections:

• AI Tool Access (MCP) — a separate thing — letting an AI reach in

This is outbound, and MCP is inbound

Worth separating immediately. The gateway is the platform calling a model. AI Tool Access and Agent Access are an AI calling the platform. Different directions, different risks, different settings.

The features that use it

• The signup wizard, turning a description into a starting blueprint.
• AI Builder, producing change sets against your application.
• Query Builder, turning a question into a query definition.
• The code editor, generating extension source.

Each can name its own provider and model, or inherit a default.

Per-role configuration is the point

The roles differ in what they need. Writing code rewards a strong model; producing a query definition does not need the same. Pointing each role separately means paying for capability where it matters rather than everywhere.

Anything left blank falls back to the default pair, so you can configure one provider and be done, then specialise later.

Provider and model travel together

A model identifier belongs to a provider. Setting a role's provider without its model — or the reverse — is how you end up handing one provider a model name belonging to another, which fails in a way that reads as the provider being broken.

Change them as a pair, or leave the model blank to take that provider's own default.

Query Builder sees field names only

Worth stating plainly, because it is the question people ask first. The Query Builder role is given field names, never a record value, and what comes back is a query definition rather than an answer.

So the model helps construct the question; it does not see the data, and the results are produced by running the query here. That is a meaningfully different privacy position from sending your records to a model, and it is worth understanding before assessing the feature.

Three ways a request can be delivered

• API — the platform calls the provider directly.
• Clipboard — the request is prepared for you to paste elsewhere. Nothing leaves the platform.
• CLI — handed to a locally installed tool.

Clipboard is the option to know about if you are not ready to send anything outbound: the feature remains usable and the platform makes no external call.

These are AI features, not AI decisions

Everything here produces a proposal for a person: a blueprint, a change set, a query, some source. Nothing is applied without somebody accepting it, which is the right arrangement and worth preserving as you configure.

Worked example

An organisation sets one default provider for everything, then points the code editor role at a stronger model because that is where output quality matters most. Query Builder is left on the default, on the basis that it only ever sees field names.

Recommendations

• Keep gateway and MCP separate in your thinking — opposite directions.
• Start with one default and specialise on evidence.
• Change provider and model together.
• Consider clipboard delivery if outbound calls are not yet agreed.

Choosing a Provider

Several providers are supported and each is configured with its own credentials and default model. The choice is less about benchmarks than about terms and location.

Where to find it

Architect Panel → Data:

• AI Builder — the feature most sensitive to model quality

Architect Panel → Security:

• Permissions — who can use the AI features at all

Ask the questions that are hard to reverse

1. Where do requests go? Which country, and does that suit your obligations.
2. What does the provider do with them? Retention, and whether inputs may be used for training.
3. What contract are you under? A consumer plan and a business agreement differ enormously.

Model quality is easy to change later; the answers to these are the ones that matter to whoever signs off the arrangement.

Configure the default first

Because everything falls back to it, the default provider is the one most requests use. Get that decision right and the per-role overrides become tuning rather than a series of separate approvals.

Each provider carries its own credentials

Enabled, a delivery method, an API key and a default model. Use an organisational account, not somebody's personal one — this is a billed service and it should not stop working because a person left.

Keys are credentials with a bill attached

A leaked model API key is somebody else's usage charged to you, and it is not always noticed quickly. Treat them as you would any other credential: not in a repository, not in a ticket, and rotated on a schedule.

A local tool is an option

Where a provider offers a CLI, requests can go through a locally installed tool rather than a direct call. That suits environments where outbound calls from the server are restricted, and it changes who is making the call.

Match the model to the role

Not every feature needs the same capability. Generating extension source rewards a stronger model; assembling a query definition from field names is a smaller task. Per-role configuration exists so you can reflect that rather than paying for the best everywhere.

Review the choice periodically

This area moves quickly — models are superseded and prices change. A configuration set once and never revisited will be paying for something outdated within a year. An annual look is enough.

Have a view before somebody asks

"Which AI are you using and what happens to our data" is now a routine question in procurement and security reviews. Being able to name the provider, the terms and what each feature actually sends is much better than assembling the answer under time pressure.

Worked example

An organisation with public-sector clients chooses a provider on the strength of its business terms and processing location rather than its benchmarks, records the decision, and points the code editor at a stronger model from the same provider. When a client's security questionnaire asks, the answer is already written down.

Recommendations

• Choose on terms and location before capability.
• Get the default right — it carries most of the traffic.
• Organisational accounts and rotated keys.
• Write down the answer to what you use and what it sends.

Using It Safely

The features are useful and they are not judgement. A few habits keep the distinction clear.

Where to find it

Architect Panel → Data:

• AI Builder — change sets, which need review before applying
• Query Builder — the role that sees field names only

Architect Panel → Activity:

• Activity Log — what an accepted change actually did

Know what each feature sends

They differ, and the difference matters more than any general policy:

• Query Builder sends field names only — never a record value — and receives a query definition.
• Blueprint and change-set features send a description of what you want and structural information about the application.
• The code editor sends what you are working on.

None of these is "your database". Be able to say that precisely, because "we use AI" invites a much broader assumption than what is happening.

Everything is a proposal

Nothing is applied on its own. A change set is reviewed before it runs; a query is a definition you look at; generated source is code you read.

Preserve that. The value here is a good first draft quickly, and the risk begins where somebody stops reading the drafts.

Review change sets properly

The temptation is to accept a change set that looks right. Read what it will actually do, particularly anything touching permissions, deletion or existing data — a confidently wrong change set is more dangerous than an obviously wrong one, because it gets accepted.

Do not paste sensitive data into a prompt

The features are careful about what they send; a person typing into a prompt box is not constrained the same way. Real customer records pasted in as an example go wherever prompts go.

Use realistic but invented examples. It costs nothing and removes the question entirely.

Restrict who can use them

These features change your application. Access should sit with the people who would be allowed to make those changes by hand — the AI route should not be a way around a permission somebody does not have.

Generated code is code you own

Once accepted, nobody cares where it came from. It gets the same review, the same testing and the same maintenance as anything hand-written, and the fact that it was generated is not a defence when it misbehaves.

Tell people it is available

Rather than leaving it to be discovered. People who know a feature exists use it deliberately; people who find it by accident use it experimentally on live configuration.

Have an internal position

Which features are enabled, who may use them, what may be pasted into a prompt, and who approves an AI-produced change. A short written answer is worth having before the question arrives from a client rather than after.

Worked example

An organisation enables AI Builder for its two architects only, documents that Query Builder sends field names but never values, and adds one line to its developer guidance: generated changes are reviewed like any other change, and no real customer data goes into a prompt. A client's security questionnaire six months later is answered from that page.

Recommendations

• Know and be able to state what each feature sends.
• Review every change set — especially the plausible ones.
• Restrict access to people who could make the change by hand.
• Never paste real records into a prompt.