As AI agents multiply across the enterprise, the question is no longer whether your AI can answer — it is what governs everything it does. Every agent, internal or external, runs inside the user's own permission perimeter, enforced by the runtime. Multi-provider AI through a unified abstraction — swap OpenAI, Anthropic, Ollama, Google Vertex, IBM Watson or Cohere by configuration, not by code. Built-in RAG over the customer's choice of vector store — Qdrant, Milvus, PostgreSQL pgvector or Redis. Natural-language agents that generate XDBL (the platform's XSD-described query grammar), not raw SQL — the compiler emits the engine-native SQL with row and column security injected automatically. The agent cannot escape the user's permission perimeter; it is a structural property, not a policy. A native MCP server so external assistants can drive the platform without bypassing security. Cost-tracked, audit-logged, role-aware by construction.
Airtool's permission-scoped execution model gives the AI the exact access the human user has — not a broader service account with application-level filtering on top. Agents emit XDBL, the platform's XSD-described query grammar; the compiler emits engine-native SQL with row-level and column-level security injected for the user's runtime context. The AI cannot escape the perimeter because it does not produce the executed query; the compiler does — and the compiler is the platform's, not the agent's.
OpenAI, Anthropic, Ollama, Google Vertex AI, IBM Watson, Cohere — abstracted behind a provider-independent interface. Swap providers per configuration; production code does not change.
A native Model Context Protocol server. External AI assistants connect under user identity, see only tools the user can use, and operate under the same audit trail.
Every AI request is recorded — provider, model, tokens, cost, execution time, status. Per-tenant spend caps, per-user budgets, model allowlists. AI cost is governed, not opaque.
One abstraction; six providers; the customer's choice of model per workload.
GPT-4o, GPT-4, GPT-3.5-turbo. The default for high-quality general-purpose generation when the operational context permits a public API call.
Claude 3.5 Sonnet, Claude 3 Opus, Claude 3 Haiku. Strong on instruction-following, code review and document analysis.
Open-source models running on customer infrastructure. Zero-marginal cost, full data residency, no public-API dependency. Good for classification, summarisation and routing tasks.
Gemini family models, integrated for customers with Google Cloud workloads or Google-specific compliance requirements.
WatsonX API integration for enterprises with established IBM relationships or watsonx-specific data residency.
Generate and Embed APIs for customers preferring Cohere's models — particularly for European data-residency configurations.
The patterns enterprise customers actually need — not toy demonstrations.
Vector embeddings stored in the customer's choice of vector store — Qdrant, Milvus, PostgreSQL pgvector or Redis. Maximum Marginal Relevance retrieval out of the box. Document ingestion, chunking, embedding, retrieval and citation all under the same security perimeter the customer's data lives in. The same multi-engine philosophy that applies to relational databases applies to vector stores.
Ask a business question in plain language; the agent generates XDBL — the platform's XSD-described XML query grammar — not raw SQL; the compiler emits the engine-native SQL with row-level security expressions and column-level visibility rules injected based on the user's runtime context. The agent works one level above SQL; the platform handles the engine and the security. The agent cannot generate a query the user could not write themselves — and it cannot bypass that constraint because the constraint is enforced during compilation, not during agent execution.
AI agents that explain operational records — what changed, who changed it, why the rule fired. The audit trail and the AI explanation share the same data.
Draft customer communications, regulatory submissions and operational summaries from the same data the rest of the platform reads. Output stays inside the perimeter; review is human-in-the-loop by default.
Most AI-on-data systems use a service account with broader permissions than the human user, then rely on filtering to prevent overreach. Airtool's permission-scoped execution model does not — the AI operates under the user's own runtime identity, and the constraint is enforced at compilation, not by filtering.
The platform's XSD-described XML grammar (XDBL) is what the agent emits. The XSD is small, complete and well-documented; an LLM can target it with high accuracy. SQL — with its seven engine dialects, each with its own date functions, string handling and sequence semantics — is never the agent's output.
The query compiler translates XDBL to the engine's native SQL. Date arithmetic, string functions, isolation levels, sequence handling — all resolved automatically against the engine currently bound to the user's request context.
At the same compilation step, the row-level security expressions for the current user's roles, departments and ownership rules are injected into the WHERE clause. Column-level visibility rules are applied to the SELECT list. The generated SQL is the SQL the user is entitled to run — no more.
The agent does not connect to the database. The agent emits XDBL; the platform's runtime calls the compiler; the compiler returns engine-native SQL with the security layer already applied; the runtime executes that SQL. The compilation step is between the agent and the data — and it is the platform's, not the agent's.
MCP is an open standard for AI assistants to drive systems. We are MCP-native, not MCP-wrapped.
A platform endpoint that speaks MCP Streamable HTTP. External AI assistants — Claude, GPT, custom — connect under the user's identity and operate inside that user's perimeter.
The MCP server supports OAuth authorisation, so an external agent connects through the standard flow: the user authorises the agent once, the platform issues a token scoped to that user, and the session runs under that user's identity. No credentials are pasted into the agent's configuration; revoking the grant revokes the access.
Alongside OAuth, a user can generate a personal API token from their preferences. Either path requires an explicit MCP access type grant (admin gate). No way to bypass.
The set of tools the MCP server advertises is filtered by the user's role. Developers see the platform tools; standard users see the application tools; nobody sees what they cannot use.
An AI assistant can do exactly what the user can do — no more and no less. The security model treats it the same as any other client.
The audit log records the AI as the operator. Every MCP tool invocation is captured with the same detail as direct application access — user identity, tool, outcome — in the same audit trail the rest of the platform writes to.
AI cost is the new shadow IT line. The platform brings it under operational control.
Central registration of AI providers and models, with per-model pricing (request and response tokens). Adding a new model is a configuration step; the cost layer reflects it automatically.
Default models configured per company and per user. Standard users get the company default; admin roles can opt into more capable models when the workload warrants it.
Monthly spend caps per company, monthly request quotas per user, max tokens per request, allow-listed models. Costs that would exceed the cap are rejected, not just reported.
Every AI request logged with provider, model, tokens consumed, cost, execution time, user and outcome. AI cost reporting is a query against the platform's standard data, not a separate vendor dashboard.
Agent interactions, tool selection, cost tracking, RAG over the customer's vector store. Placeholder screenshots; real captures land in this same carousel.
The enterprise question about AI is changing. A year ago it was whether a model could answer usefully. Now it is what governs an expanding population of agents — internal copilots, external assistants, autonomous workflows — each able to read and act on operational data. When agents are many and the work they produce is generated rather than reviewed line by line, governance cannot live in prompts or in the discipline of each agent. It has to live in the runtime they all pass through.
Most enterprise AI-on-data systems sit on top of a SQL engine and rely on the LLM to write SQL that respects the user's permissions. The LLM is asked to be careful. The application layer is asked to filter what the LLM sees. Neither is a structural guarantee; both depend on getting every prompt and every filter right, every time. When the LLM hallucinates a column or routes around an ownership rule, there is nothing below it that catches the mistake.
On Airtool the AI does not write SQL. It writes XDBL, the platform's XSD-described XML query grammar. The platform's compiler translates XDBL to native SQL for the engine bound to the user's request context — and at the same step, injects the row-level security expressions and column-level visibility rules that apply to the user's roles, departments and ownership. The agent works at one level above SQL; the platform handles the engine and the security. The agent cannot escape the perimeter because the agent does not produce the executed query — the compiler does, and the compiler is the platform's.
This is not a policy that can be relaxed. It is the architecture. External assistants connecting through MCP inherit the user's permissions exactly because they cannot do otherwise. The AI surface and the data surface share one compilation step; the security model is enforced inside that step; there is nowhere else for the AI to put the query.
The structural advantage exists only because Airtool's applications are metadata, not files. Forms, screens, endpoints, roles, scheduled jobs, stored procedures and audit trails are database records in the Metadata Repository — not scattered across Vue components, config files and Java classes. The compiler owns every path to the data because there is no parallel path. Agents and developers write to the same metadata repository ; the platform's governance applies equally to both. This is the difference between AI bolted onto a codebase and AI native to a runtime.
Airtool's permission-scoped execution model makes the constraint structural rather than behavioural. The AI operates under the user's own runtime identity — not a broader service account — so there is no filtering layer to get wrong and no prompt instruction that could relax the constraint. Agents emit XDBL (the platform's XSD-described query grammar), not raw SQL; the compiler translates XDBL to engine-native SQL and, at the same compilation step, injects the row-level and column-level security expressions for that user's roles, departments and ownership rules. A finance agent for a user with accounts-payable access cannot read payroll data — not because the agent was asked to be careful, but because the compiler does not generate a query the user could not run themselves. External assistants connecting through MCP inherit the same constraint: they authenticate under the user's identity and the MCP server enforces the same XDBL-to-compiler path. This is distinct from the service-account pattern, where the AI holds broader credentials than the human user and the application is expected to filter results — a filtering layer that breaks silently when the LLM routes around it.
Construction, not policy. Agents generate XDBL — the platform's XSD-described query grammar — and the compiler turns XDBL into engine-native SQL with row-level and column-level security injected per the user's runtime context. The agent does not connect to the database. The agent does not produce the executed query. The compiler does, and the compiler is the platform's, not the agent's. Security is a property of compilation, not a discipline the agent has to remember.
Yes. OpenAI, Anthropic, Ollama, Google Vertex AI, IBM Watson and Cohere are exposed behind a provider-independent interface. Provider choice is configuration ; application code is unchanged when switching. Customers commonly start on a public-API provider for the development phase and move workloads to Ollama (local) or a region-resident provider as production rolls out — without re-authoring agents.
As a native, first-class surface. External AI assistants connect under user identity through the MCP protocol — authenticating with OAuth through the standard agent-to-platform flow, or with a personal API token — and see only the tools and resources that user's role permits. The listTools and canAccess SPI hooks gate tool and resource visibility per caller, with the same role and attribute-level security model the rest of the platform uses. The audit trail covers MCP invocations on the same footing as direct application access.
Per-tenant spend caps, per-user budgets and model allowlists, with live dashboards by user, department and model. Every AI request is recorded — provider, model, tokens, cost, execution time, status. Customers can configure budget caps and have invocations refuse cleanly once limits are hit, rather than discover the overrun on the next monthly invoice.
Qdrant, Milvus, PostgreSQL pgvector and Redis as first-class targets. Informix gained an HNSW access method recently — the data tier now supports approximate-nearest-neighbour search on one of the seven supported OLTP engines, so the platform's RAG and embedding-driven workloads can run on the same operational engine the rest of the application uses. The platform's data-access layer routes the query to the chosen store transparently.
Yes. The Ollama provider runs open-source models on customer infrastructure with zero marginal cost and full data residency. Vector stores can run on-prem (PostgreSQL pgvector, Informix HNSW, Redis, self-hosted Qdrant or Milvus). The MCP server runs inside the customer perimeter. Customers who require an on-prem AI surface configure the deployment without giving up the abstraction layer that makes provider choice reversible.
Yes, by construction. Each request runs inside a scoped execution context bound to the authenticated principal, the target tenant database and the tenant identity — a property of the runtime enforced at the JDBC layer, not a policy the AI surface applies separately. Agents generate XDBL; the compiler emits engine-native SQL with the current user's row-level and column-level security expressions injected. The AI assistant for tenant A cannot reach tenant B's data because the query is compiled against tenant A's security model, tenant A's database, tenant A's connection pool — there is no shared data path. There is no shared service account; the AI operates under the individual user's runtime identity, exactly as a human query would. Adding a 201st tenant applies the same scoped-context model by construction — no additional security configuration is required for the new tenant's AI surface.
Yes. RAG runs over the customer's choice of vector store — Qdrant, Milvus, PostgreSQL pgvector, Redis or HNSW on Informix — all within the same security perimeter, without a separate vector store to operate and keep in sync. HNSW on Informix and pgvector on PostgreSQL keep the vector index on the same operational engine the rest of the application reads — under the same access controls, the same backup policy, the same connection pool. Per-customer AI usage quotas — monthly spend caps, per-user request limits, model allow-lists — are configured in Studio and enforced before each request reaches the provider; an invocation that would breach the cap is rejected cleanly, not reported on the next invoice. All three capabilities are native to the runtime. No external SaaS product is stitched in; the platform's AI layer, its data tier and its governance surface share one security model and one audit trail.
Yes, as a structural property. Every AI request is written to the platform's activity audit log with provider name, model name, input token count, output token count, cost, execution time, user identity, tenant context and outcome status. MCP tool invocations are captured on the same footing as direct AI calls. The audit log is a set of SQL tables in the metadata repository; compliance review is a query, not a dashboard request to a separate vendor. The log is INSERT-only by design; entries cannot be modified or deleted by application code. Row-level security scopes each user's view to their own interactions; administrators query the full fleet.
This is the standard configuration on the platform. Six providers — OpenAI, Anthropic, IBM Watson, Google Vertex AI, Ollama (on-premises) and Cohere — are registered in the platform's AI provider registry and abstracted behind a provider-independent interface. Provider selection is per-workload configuration, not code: a conversational agent binds to Anthropic Claude, an embedding pipeline binds to Vertex AI, a governed or data-residency-constrained workload binds to IBM watsonx or to an Ollama model running on customer infrastructure. The same application code drives all workloads; the provider binding is declared in the registry, not hardcoded. Credentials — OpenAI API keys, Anthropic API keys, watsonx project identifiers, Vertex AI service account tokens — are registered per provider, tenant-scoped, and retrieved by the platform's keystore at runtime. Application code never holds raw credential material. Per-tenant quota governance is configured independently per tenant in Studio: monthly spend caps, per-user request limits and model allow-lists for each registered provider. A tenant that runs Anthropic Claude for its primary assistant and Vertex AI for its embedding pipeline has separate credential records and separate quota configurations for each; the platform enforces both through the same cost-governance engine and records every AI request from every provider in the same activity audit trail — one query covers the full AI cost surface, irrespective of how many providers the tenant uses.