An agent connected to the platform acts as the person who connected it : it holds that person's grants, it is refused wherever that person would be refused, and everything it does is recorded against that person's account. Around that identity the organisation sets the rest — which world an agent may enter, which environments it may reach, which tool families a role puts on the table, which tools a grant hands over and at what risk class, whether a call is held for a human decision, and how far a multi-agent run may go before a ceiling stops it. Every call ends in one of five recorded outcomes, and every command it ran is kept.
No service account with its own reach. An agent runs as the user's own database identity, with that user's grants and nothing more, so the question "what can the agent do" has the same answer as "what can this person do".
Roles open tool families ; an administrator's grant hands over tools, by category, pattern or name, and records why. Every tool carries a risk class. A new capability is absent from every existing role until it is granted.
A tool call can be held for a human decision, planned before it is executed, and bounded by iteration ceilings, timeouts and cancellation. A refusal names what was missing ; a gated call ends with no side effects.
Every call with its outcome, every statement each tool sent to a database engine, and a daily roll-up that stays answerable after the detail has been purged. The user sees their own ; the administrator queries the fleet.
Four decisions, taken by four different people, each recorded. None of them is taken by the agent, and none of them is taken by a prompt.
Which endpoints exist, which protocol versions are accepted, and which environments each world may serve. The development world refuses production and unclassified targets unless a root privilege is held ; the workspace world never serves production ; the administration world is a separate door.
Which families a person's roles put on the table : the developer role opens development, object, quality and test families ; administrator capability opens administration ; the workspace role opens the unscoped endpoint ; the documentation level of a grant, not a role, opens the manual. A role is the door to a family, never the permission to a single tool.
Which tools inside those families a person holds, and at what risk class. Granted by category, by pattern or by single tool ; revoked the same way ; listed for audit. A granted tool pulls in the tools it cannot work without, never at a higher risk class than it was granted at.
On each database : the environment, the write verbs (insert, update, delete — a partial grant hides all three, on purpose), the AI ceiling, the documentation level, and whether the development endpoint opens at all. What a business user's assistant may do on production data is this grant, and nothing else.
For every environment class and every world, the platform answers yes, no or never — computed by the same rules the server applies when it accepts or refuses a session, and shown to the user before the first call.
Open to development and application sessions for a user with the corresponding grants ; closed to the workspace endpoint until the workspace role is held. Where an application is authored, proved and tested.
Never on the workspace endpoint. On the development endpoint only with a root privilege — and then only for a dictionary. On the application endpoint through the user's own grant, because production data is what that endpoint exists for.
Never, anywhere. A missing classification is not a decision, and no privilege lifts it. An organisation that has not classified a database has not authorised an agent on it.
Every tool declares how far one call goes on a dictionary stack : one dictionary, the resolved layer, the whole stack, or across to data. The agent knows before it calls whether a question reads every layer or one.
Between the agent's intention and the runtime's execution sit controls the agent cannot reach around. Nothing runs until a decision is recorded.
Where a deployment enables it, a tool call is suspended at the execution boundary : the pending tool and its parameters are shown to the operator, the proposed change is rendered as a diff or a labelled card by the tool's own schema, and the decision — approve or reject — is returned per call. A rejection returns control with no side effects. Every decision is written to the record.
Before the first action, the agent drafts the steps it intends and waits for the operator's go-ahead. The plan is a checkpoint, not a formality : it persists as a validated file the agent ticks off, downloadable only by users granted the conversation.
The model for a conversation and its iteration ceiling are chosen at the start, within the company's allow-list. A parent agent delegates to sub-agents in parallel with a timeout per call ; cancellation propagates from the parent to every child ; a shared scratchpad lets sub-agents reuse results without a second model call.
Proved before it is written, dry-run by default, journalled with its before-image, restorable from the journal, refused on the wrong environment, refused while a person is editing the same body, and refused when it would widen access or lock an administrator out unless the call states that this is meant.
A call can be turned away at three different places, and the record says which. The distinction is what makes an agent's behaviour auditable rather than merely logged.
The tool ran and returned a result. The statements it sent to the database are recorded beside it.
The endpoint turned the call away before the tool ran — the world, the environment or the grant did not admit it. No side effects ; the reason is named.
The tool validated its arguments and declined : an object that does not exist, a body that fails its proof, a production target without the privilege. A refusal is an agent about to correct itself.
The tool ran and something failed. An error is a defect to look at, separated from refusals so that the two are never confused in a review.
The operator or a timeout stopped the run. Cancellation propagates to sub-agents and is recorded like any other outcome.
Supervision starts with the person whose identity the agent carried, and ends with the auditor who reads the fleet.
Every tool an agent has run on the account, newest first : sequence, outcome, tool, risk class, endpoint, target, duration, request and result sizes, tokens, the commands it ran, the failure kind and the error text, the client and server addresses and the session. Filterable by tool, outcome and date.
Every statement an agent sent to a database engine on the user's behalf, across all calls, in the order it was issued : the tool, the endpoint, the target, the engine, the database, the duration, the statement and its error. Explain plans, DDL, DML — what the agent actually did, in the terms an engineer's work is judged in.
The days the calls add up to, read from a daily roll-up : calls, ok, refused, error, gated, cancelled, fail rate, average call, slowest call, average result size. The roll-up stays answerable after the call detail has been purged.
The same events queried as SQL through the reporting surface and through administration tools that list, read and aggregate MCP calls, logins and raw attempts, and object executions. Purging the audit is the one write in that family and is classed apart.
An agent inherits the same limits as the person : what a query may return, what a session may hold, what a log level records. The limits are the department's, shown to every user.
Maximum rows for a PDF, a spreadsheet, a table, a report and an analytical grid ; rows displayed in a main object and in an item ; rows resolved for a foreign key or a combo ; rows an offset may skip. An agent cannot pull what a person cannot pull.
Cached cursors, concurrently running cursors and the other constraints a session operates under, visible to the user whose session they govern.
JDBC configuration, connection pools and log levels specific to the department. The agent's activity is logged at the level the department chose for its people.
The AI ceiling on each database grant ; the company's monthly spend cap, the user's request quota, the token limit per request and the model allow-list, enforced before a call reaches a provider. A call that would exceed a cap is rejected cleanly, not reported later.
Because every tool carries a class and every grant is a recorded act, an organisation can widen what its agents may do as trust is earned, and narrow it in one act if it is not.
Grant the read categories : data query, dictionary search, the read halves of code and objects, the manual, the security answers. Agents explain, analyse, review and document. Nothing is written, in any world.
Grant the write categories on TEST and DEV. Every write is proved, dry-run, journalled and restorable ; the approval gate can hold each one for a person. Agents author and prove application code where a mistake costs a restore, not an incident.
Grant the security-sensitive tools individually, with the reason recorded : REST contexts, grants, roles. Widening settings still need consent on the call.
Grant destructive tools only where the approval gate holds them. Dry by default, before-image journalled, delete grant required, restore plan available. The audit shows every one.
Screens from the running platform : the reach matrix, the five outcomes, the calls, the commands, the usage roll-up, the grants and the roles.
The question a board asks about AI agents is not whether they are useful ; it is who answers for them. Airtool's answer is that the agent answers as the person who connected it, and the organisation answers through four recorded decisions : the worlds and environments an administrator opens, the families a role puts on the table, the tools a grant hands over and at what risk class, and the verbs and ceilings a keeper sets on each database. None of those decisions is taken by the agent, and none is taken by a prompt. They are rows in the platform, listed, revocable and audited like any other configuration.
Between the agent's intention and the runtime's execution the organisation keeps a hand on the boundary : a call can be held for a person, a plan can be required before the first action, a run is bounded by ceilings and can be cancelled, and every write is proved, previewed, journalled and restorable. These are the rules a mature engineering team applies to itself. The platform applies them to the agent mechanically, on every call, whether the agent is an external assistant, an internal copilot or a batch process running under machine credentials.
The record closes the loop. Five outcomes rather than two, the statements behind each call, and a roll-up that survives the purge of the detail mean that an AI programme can be reviewed the way an operations programme is reviewed : by trend, by exception and by evidence. And the staged path — read everything, then recoverable writes on test, then security-sensitive tools by name, then destructive tools under the gate — gives the organisation a way to widen what its agents may do as trust is earned, and to narrow it in a single act if it is not.
The approval gate is opt-in per deployment ; an operator chooses which deployments hold calls and which run them. The gate covers tools the platform executes ; it does not review the text a model returns to a user, which remains the user's to read. Plans are the agent's stated intent, not a guarantee of the steps it will need. Governance of what a model says is a prompt and review discipline ; governance of what an agent does is what this page describes, and it lives in the runtime every agent passes through.
No. The agent acts as the user, with the user's grants, on the user's database identity. There is no service account underneath with broader reach, and no filtering layer that could be routed around. The reach matrix the user sees before the first call is computed by the same rules the server applies to the session.
A system administrator, by category, by pattern or by single tool, with the reason recorded. Roles open families ; only a grant hands over a tool. Grants are listed, revoked and audited like any other configuration, and a granted tool never pulls in a dependency at a higher risk class than it was granted at.
Three separate refusals, each sufficient on its own : the world (the workspace endpoint never serves production ; the development endpoint requires a root privilege for a production dictionary), the environment (unclassified is never admitted anywhere), and the grant (write verbs are granted per database, and a partial grant hides all three verbs). Tools that reach an engine refuse on the environment before they run.
Where the deployment enables it, every tool call is held at the execution boundary until an operator approves or rejects it, with the proposed change rendered as a diff, and every decision is recorded. Plan mode adds a checkpoint before the first action. Ceilings and timeouts bound a run even without intervention ; cancellation propagates to sub-agents.
It carries the R3 risk class, is granted explicitly, is dry by default, requires the delete grant on the dictionary, keeps the deleted body as the before-image of a journal entry, and can be restored from a plan the journal produces. Under the approval gate it is also held for a person.
Three views of the same events. Calls : every tool call with its outcome, risk class, endpoint, target, duration, tokens and error. Commands : every statement each tool sent to a database engine, in order, with its error. Usage : a daily roll-up by outcome, fail rate and latency that survives the purge of the detail. Administrators query the same events as SQL and through the audit tools ; purging is itself an audited, separately classed act.
Gated means the endpoint turned the call away before the tool ran — the world, the environment or the grant did not admit it ; there were no side effects. Refused means the tool validated its arguments and declined — a missing object, a body that fails its proof, a target without the privilege ; it is usually an agent about to correct itself. Errors are kept apart from both so that a review never mistakes a self-correction for a defect.
Yes. External assistants connect through the MCP server under the same identity, roles, grants, worlds, gates and record. Machine agents connect with client credentials under the same rules. The platform does not distinguish an internal copilot from an external client.
With the read categories, on any environment the grants already open : agents explain, analyse, review and document, and nothing is written. Then recoverable writes on test, then security-sensitive tools by name, then destructive tools under the gate. Each stage is a set of recorded grants ; each can be reversed in one act.