Require evidence behind the AI conclusion
An AI answer should help an analyst reach a supported decision. Ask it to show the source records and the searches behind its conclusion. The analyst should be able to distinguish an observed fact from an interpretation.
Test an incomplete case as well as a complete one. If identity logs are missing, the answer should say that the sign-in history is unavailable. It should not turn that gap into a claim that no sign-in occurred.
The proof-of-value plan includes a missing-data test so this behavior can be evaluated before production.
Separate reading evidence from changing systems
| Permission level | Example | Required boundary |
|---|---|---|
| Read and investigate | Find related events and prepare a case summary. | Source and tenant scope enforced by the service. |
| Prepare a response | Draft a containment step for analyst review. | Proposed action visible before execution. |
| Execute a response | Disable an account through an approved integration. | Narrow tool permissions and agreed authorization. |
| Review an action | Reconstruct who approved and executed a change. | Persistent evidence and an auditable action record. |
Keep read access within the approved tenant
An AI assistant should not gain broader access merely because it can answer in ordinary language. Test it under the roles your analysts will actually use.
In a service-provider setting, try an authorized negative test with another test tenant. Confirm that evidence and case references stay within the permitted customer. A conversational refusal is useful behavior, but the underlying data and tool access must also enforce the boundary.
Make proposed response steps reviewable
Show the affected account or system and why the action is proposed. Include the evidence that supports it and the expected business impact.
Keep approval tied to the specific action. A general agreement to investigate should not authorize an unrelated account change. If the case changes before execution, the reviewer needs to see the updated facts.
Limit the tools that can execute a response
Define which response tools are available and the scope each can change. Use the smallest supported permission set for the intended job.
A shared IBM i profile or production application account needs business context. Agree on who can authorize containment and how to recover if the decision is wrong. A rollback description should account for work performed while access was interrupted.
Fluency describes permission-aware capabilities for headless access. Verify the offered implementation against your required actions instead of treating the product label as proof of the controls.
Treat log text as evidence rather than instructions
A security event can contain text an attacker controlled. That text must not become permission for an AI tool to disclose data or change a system.
OWASP identifies indirect prompt injection as a risk when AI processes external material. Use a safe test record with misleading instructions during evaluation. Check that it remains event data and that tool permissions still hold.
Document where investigation data goes and whether an external AI provider receives it. Confirm retention and data-use terms for the chosen service configuration.
Keep a reviewable record of AI actions
For an approved change, retain the initiating identity and the approval decision. Record the exact tool action and its result alongside the case evidence.
Have another authorized reviewer reconstruct a test action without relying on the original analyst. If the reviewer cannot tell what was approved and what actually ran, the audit record needs work.
Assign these responsibilities in a managed service when a provider performs investigation or response.
Bring your security question to Midland
Tell us which systems you need to protect and where investigations get stuck. We can review the AI Native SIEM offering against that requirement.
Review our AI Native SIEM and SOC platform or discuss your environment with us.
Sources and technical scope
Checked October 23, 2026. Product capabilities and supported integrations depend on the offered configuration. Planning examples below are evaluation guidance, not measured customer results.