The AI control loop

Airbrx exposes its admin surface to AI clients over MCP. An agent can see what your cache is doing, propose a rule change, preview exactly what that change would replace, write it, and check whether the hit rate moved. The Gateway then enforces that policy deterministically, the same way it enforces a rule a human wrote.

State the boundary first

The most important fact about this surface is what it does not touch.

The MCP server is a control-plane surface. It is not a data path. An agent connected to Airbrx can read and rewrite the policy that governs data access, change who has access, flush cache, and read the Gateway's own telemetry about what ran. It cannot read a row of your data, and it cannot execute a query against your warehouse. Your warehouse is reachable only through the Gateway's wire protocols, on a separate network path, which MCP does not connect to.

One tool carries SQL: a log-query tool. It runs against the Gateway's own request-log store, not your warehouse — SELECT only, single statement, restricted to one view, row-capped, and scoped to your tenant by a role the server derives itself rather than accepting from the caller. Your statement text appears there as telemetry, describing queries that already ran. It is not a submission channel.

The honest counterweight, in the same breath: this is still a high-authority admin surface. An agent with sufficient scope can rewrite cache policy, grant a person access to a tenant, and flush a tenant's entire cache — which sends its whole read load back to your warehouse at once. Scope it the way you would scope a contractor, not the way you would scope a dashboard.

The loop

The tools are arranged around a cycle, and each leg exists:

• Observe. Summaries by year, month, day, and user; per-rule effectiveness; a ranked list of caching opportunities; ad-hoc SQL over the request logs.
• Propose. This is the connected model itself, reasoning over what it just read. There is no second model behind an endpoint doing the proposing.
• Preview. Validate the candidate rule set, and diff it against what is actually stored — writing nothing.
• Write. Replace the tenant's rule set.
• Verify. Re-read rule effectiveness and ask whether the hit rate actually moved.

The observe leg matters more than it sounds. An agent that can write rules but cannot see traffic is authoring blind, and blind authoring against a cache is how you get a confidently wrong rule that quietly halves your hit rate. An agent connected to Airbrx today can see the traffic it is tuning for.

Why preview exists

Writing rules is a full replace. A candidate rule set composed from partial knowledge silently deletes every rule it omits, and the API returns success either way. That is the single sharpest edge on this surface.

The preview tool exists specifically for it. It reads your stored rules, diffs the candidate against them, and reports what would be removed and whether the change is destructive — before anything is written. Ask your agent to run it, and read the removal list, before approving a rule write.

Be clear about the limit: the preview is advisory. Nothing forces an agent to run it first. It is a tool the model is told to use, not a gate the server enforces. Treat an unpreviewed rule write the way you would treat an unreviewed migration.

Cache invalidation has the same shape. A preview tool estimates the blast radius — which rules a flush would target, which markers are active, and the last week of traffic against those rules, which is the load a flush would send back to your warehouse. Every invalidation tool's description tells the model to run it first.

Permissions are the ones you already have

The MCP server verifies nothing and signs nothing. It attaches the caller's token, forwards the request to the API, and surfaces the answer. Every permission decision is made by the API, using the same four-axis scope model, the same tenant fences, and the same audit trail as the App or a script you wrote yourself. An agent is not a special kind of caller.

Authentication is OAuth 2.1 with mandatory PKCE, and the authorization server is the Airbrx API rather than the MCP server. The credential behind an agent's session is a scoped personal access token minted at consent time; the client never sees its raw secret. Everything in Scope a token applies directly.

Because tools carry read-only and destructive annotations, a well-behaved client can decide when to ask you for confirmation instead of guessing from the tool's name. Seven of the tools write; six of those are marked destructive. None of them reach anything outside Airbrx's own API.

Where to go next

• Connect an AI agent — the practical setup, the full tool list, and the two guided workflows.
• The Gateway, App, and API — where an agent sits in the model.
• Security posture — the scope model an agent inherits.