How the investigation agent is governed

The agent behind AI Assistant → Investigate decides, one step at a time, which tool to call next. This page describes the rules it runs under — what it can reach, what stops it, and what is recorded — so you can decide how far to rely on it. For what the Investigate page shows, see AI Assistant and Investigate.

​

Every registered tool is read-only

The agent can only call tools from a fixed registry, chosen before the run starts. They read telemetry and configuration your organization already has — service health and dependencies, logs, metrics, traces, SLOs and error budgets, alerts and incidents, recent deployments and changes, infrastructure health, and past incidents and runbooks from your knowledge base. Every registered tool is read-only, and that is enforced by a test in the product’s build: registering a tool in any other class fails it. The agent cannot restart, roll back, scale, delete or change anything in your systems or in aiAxonIQ. The Tools offered panel on each investigation lists exactly which tools that run was allowed to use.

​

What every tool call passes

Before a tool runs, the request the model made goes through these checks, in order. A refusal at any step is returned to the model as a failed call with the reason, so it can correct itself rather than guess.

​

Scoped to your organization

• The organization comes from your session. It is recorded on the run when you start it and passed to every tool by the product — never as an argument the model writes. An argument naming a tenant, organization or account is refused outright.
• The tools write their own queries. A tool does not accept SQL. It builds its query from typed arguments, with your organization’s filter bound into it, and clamps the time window to your organization’s retention.
• Starting, reading and acting on a run requires a signed-in person. Other credential types — license keys, service credentials — are refused by the investigation routes.
• Investigations started automatically — one per incident an alert opens — take the organization from the incident record and are authorised as a Viewer. They cannot ask a question or wait for an approval, because nobody is there to answer.
• A run in another organization does not exist for you. Opening one returns the same “not available” answer as an id that never existed, so the response reveals nothing about which ids exist.

​

Tool classes and approvals

The runtime defines three tool classes: Because no write tool is registered, the approval flow below is not reachable in practice today. It is described so you know how it behaves when one is. Who may approve. A signed-in person in the same organization with the Editor, Admin or Owner role, checked at the moment they decide — not the role of whoever started the run. Auditor cannot approve: it is a read role, not a rung on the ladder. A run cannot approve its own action, and a read-only support-access session cannot approve. See Roles and permissions. What is approved is the call, not a summary of it. The Approval required panel shows the tool and its full arguments, verbatim. To approve, you type the tool’s name, and you can add a note that is recorded with the decision. The approval is bound to those exact arguments: if the pending call changes, the approval no longer applies. If two people decide at once, the first decision recorded wins; a rejection cannot be turned into an approval by a second click.

​

Prompt injection

Telemetry is written by whoever can reach your error paths, so a log line can contain text such as “ignore your instructions”. The product treats every value a tool returns as data, and its defence has two layers. Mitigations — these reduce the chance a model is misled:

• Your question, the conversation so far, tool results and evidence are placed in labelled data sections of the prompt, separate from the instructions.
• Before a prompt leaves for the model provider, values that the product’s capture policy classifies as credentials are redacted from it.
• Suspicious text is not deleted from the evidence. Removing it would destroy evidence about the incident itself, and would teach an attacker which phrasings get filtered.

The boundary — these hold even if the model is misled:

• The model can only name a registered, read-only tool, with arguments that pass the schema.
• The organization is never something the model can influence. A sentence in a log asking to read another organization’s data fails on the organization scope, not on the prompt.
• An answer cannot cite evidence no tool produced. Each piece of evidence gets an identifier derived from its own content. A claim citing an identifier the tools never returned is dropped and counted, and the page says how many claims did not survive validation.
• Confidence is computed from the evidence, not stated by the model. There is no field in which a model could supply one.

​

Limits on every run

Each investigation runs under fixed ceilings, recorded on the run when it starts. Reaching any of them ends the run; the answer then says so and shows what had been concluded by then. A request can lower these limits and can never raise them. The last permitted step is told it must answer, so a normal run concludes inside its budget. A run that stops early — at a limit, on a failure or when cancelled — ends with a list of what the evidence it had already collected established, assembled without another model call. Cost is estimated, never billed. It is computed from token counts and a versioned model price table. A model the table does not know is priced at the table’s most expensive rate, so a new model cannot outspend the ceiling while appearing cheap. Across runs, starting investigations is limited to 20 per minute per organization, and there is a cap on how many of your organization’s investigations run at once, with a deployment-wide queue limit behind it. A refused start says which limit applied and when to retry.

​

What is recorded

In your audit log. The actions a person takes on a run are written to the same audit event stream the Audit log reads, whether or not the evidence ledger is enabled: Each entry carries who (from the signed-in session, with their role), the run and its conversation, the tool and decision where there is one, the note entered with a decision, and the outcome. Deliberately not in the audit log: the text of your question, because it is often customer data and audit entries are exported; and the individual tool calls the agent makes, because the agent — not a person — makes them. Where tool calls are recorded. Every tool call, its status and its result are kept on the run itself and shown on its Investigate page. Where the evidence ledger is enabled, each tool call also has an intent recorded before it runs and an outcome after, and a failure to record either stops the run.

​

Limitations

• Approval policy is per tool, not per organization. You cannot require approval for every tool, or for none.
• Limits are fixed defaults. Per-organization daily spend budgets are not enforced today.
• Prompt-injection handling reduces risk; it does not remove it. What makes a misled model harmless here is that its tools are read-only, scoped to your organization, and its answers are checked against evidence.
• The investigations you read are validated for citations, not for reasoning quality. A model can still draw a wrong conclusion from real evidence.

​

Next