Osquery AI Analysis: What Happens When an LLM Reads System State

The problem with osquery AI analysis is not whether an LLM can read rows. It is whether the system can keep evidence, inference, and authority separate.

Osquery can describe installed software, running processes, open ports, identities, configuration, and recent events. An LLM can connect those facts and explain why a finding matters on one host but not another. That is useful analysis. It becomes dangerous when model output is treated as proof or allowed to authorize its own remediation.

The right design is a controlled decision pipeline. Collect the minimum endpoint facts, label their source and time, redact unnecessary sensitive data, let the model interpret the evidence, then apply identity, policy, approval, and verification outside the model. The model advises. The system decides what it is allowed to do.

What should osquery AI analysis actually decide?

Ask the model for bounded judgments: summarize conflicting evidence, propose likely explanations, rank the next query, draft a remediation plan, or explain uncertainty. Do not ask it to invent missing endpoint facts. Do not let it turn a confidence score into permission.

Consider a scanner finding for a vulnerable web library. Package inventory proves the version. Process data shows whether the service is running. Listening ports show whether it is accepting traffic. Configuration shows which module is enabled. Asset records identify owner and exposure. One row is weak. The combined record answers the real question: is the vulnerable component present, active, exposed, and owned?

The LLM can explain that chain in plain language and identify contradictions. A deterministic policy should still calculate whether the evidence meets a ticket or action threshold. A human or approved automation identity should authorize the change. Then a second query should prove the state changed.

Give the model a small evidence packet with a fixed shape. Include the question, host role, source rows, collection times, expected state, relevant change record, and allowed response types. Require an answer that separates observed facts, interpretation, missing evidence, proposed next query, and proposed action. A fixed response shape makes unsupported claims easier to reject before they reach a person or tool.

The SQL does not need to be clever. The official osquery SQL documentation describes a selection focused SQLite superset and tables that read live operating system state. Prefer several narrow, explainable queries over one huge join that hides where a fact came from.

Why is endpoint context better than alert text?

Alert text is already an interpretation. It may contain a severity, a package match, and a generic recommendation, but it rarely contains enough host evidence to make a safe decision. Endpoint state can confirm the installed version, active process, loaded configuration, network exposure, recent changes, and user context at the same collection time.

Time matters. A process row collected Tuesday cannot prove exposure on Friday. Every fact sent for analysis needs a source query, host identifier, collection time, agent version, and result status. If the system mixes evidence from different times, the model can produce a persuasive story about a state that never existed.

Missing evidence needs its own state. “Process not found” is different from “process query failed.” “Port closed” is different from “network table unsupported.” Use explicit values for observed, absent, stale, unsupported, denied, and failed. Never collapse all of them into null. The model should ask for a new collection when required evidence is stale or failed, and policy should block action until that collection succeeds.

Context also changes the economics of triage. If 300 scanner findings each require six minutes of manual confirmation, the queue consumes 30 analyst hours. An AI layer earns its cost only if it removes a meaningful share of that confirmation work without increasing false dismissals. Measure hours saved and wrong decisions, not generated summaries.

How can endpoint data attack the model?

Treat every endpoint string as untrusted. A filename can contain instructions. A command line can contain attacker controlled text. A package description, browser extension name, source repository, or log message can tell the model to ignore policy or expose data. To SQL, those are values. To an LLM, they may look like orders.

This is not theoretical hand waving. In March 2026, NIST reported results from a public agent security competition that tested hijacking attacks against 13 frontier models across tool, coding, and computer use scenarios. NIST describes the failure as an agent confusing malicious instructions inside external data with the task it was trusted to perform.

Put a trust label beside every field. Encode values as data, not free prose. Strip control characters where they have no analytical value. Limit which fields reach the model. Never place credentials, full file content, private keys, or unrestricted shell history into a general prompt. Keep the original evidence in a separate store for audit.

Model choice matters, but it is not the boundary. A September 2025 NIST evaluation tested seven models across 19 benchmarks. The agency reported that the most secure evaluated DeepSeek model was 12 times more likely to follow hijacking instructions than the evaluated United States frontier models. That same model answered 94 percent of overtly malicious requests under one jailbreak method, compared with 8 percent for reference models. Stronger models reduce risk. They do not remove the need for isolation and policy.

What control plane should sit around the LLM?

Give collection, analysis, approval, execution, and verification different identities. The collection identity reads a narrow set of tables. The model receives a filtered evidence packet. The approval service evaluates policy. The execution identity can run only named actions against an allowed target. The verification identity reads the result.

Policy should use facts the model cannot rewrite. Asset tier comes from inventory. Maintenance windows come from change management. Action scope comes from the caller identity. Command templates come from a signed catalog. The model may select a candidate and fill validated parameters, but it cannot expand the target list, change the template, or mark its own evidence complete.

That separation limits damage from a bad prompt, a bad model response, or a compromised endpoint. An LLM should never receive a general shell merely because it produced the command. Wrap remediation in typed actions such as “upgrade package,” “stop service,” or “remove extension,” each with input validation, target scope, timeout, rollback, and an audit record.

Approval also needs an expiry. A command approved for one host at noon should not remain valid for a fleet at midnight. Bind the approval to the host identifier, evidence hash, action, parameters, approver, and short execution window. If endpoint state changes before execution, collect again and reevaluate.

Keep a manual stop at the fleet boundary. An operator should be able to revoke pending approvals, disable an action type, and freeze one endpoint cohort without changing a prompt. Safety controls that depend on the model cooperating are not controls.

OWASP made this distinction explicit in December 2025 when more than 100 contributors produced the Top 10 for Agentic Applications. The list highlights behavior hijacking, tool misuse, and identity abuse. An endpoint analysis system touches all three. Its tool permissions must be smaller than its reasoning surface.

How do you test whether the analysis is safe?

Build a review set from resolved cases. Include true exposure, false package matches, stopped services, protected ports, unsupported agents, stale evidence, permission failures, and contradictory rows. Record the decision, evidence, approved action, and reason. Keep a separate attack set with instructions hidden in fields.

Score the whole decision, not prose quality. Did the system cite the right facts? Did it distinguish missing evidence from negative evidence? Did it ask for another query when uncertain? Did it propose an allowed action? Did policy block the wrong target? Did verification detect a failed command?

Run the set whenever the model, prompt, table schema, agent version, or remediation catalog changes. Track false escalation, false dismissal, unsupported claims, attack success, approval overrides, and verification failure. A model update is a control change. Treat it like one.

Set release gates before looking at results. For example, zero unauthorized actions is a hard gate, while a missed low impact recommendation may be reviewed. Sample production decisions by risk tier and preserve the full evidence packet. Twenty reviews at 15 minutes each cost five analyst hours. That is cheap insurance when the system can change thousands of endpoints.

Artemes AI applies this principle with deep endpoint context and AI driven analysis, then returns an exact remediation path tied to the host. The important idea is portable: evidence should be inspectable, authority should be narrow, and every change should have a proof query.

Frequently asked questions

Can an LLM write osquery SQL safely?

It can draft useful selection queries, but the system should validate tables, columns, platform scope, required constraints, and cost before execution. Use a read only identity and a query allowlist.

Should raw osquery results be sent to a hosted model?

Only after data classification, minimization, contract review, access controls, retention rules, and redaction. Command lines, user paths, browser data, and environment values can contain sensitive information.

Can AI automatically remediate an endpoint?

Yes, for bounded approved actions with target checks, rollback, audit, and verification. The model should propose the action. A separate policy and execution layer should authorize and run it.

How do you detect hallucinated security analysis?

Require every claim to cite a source field and collection time. Reject claims that cannot be traced to evidence or an explicitly labeled external source. Then test with known contradictory cases.

The takeaway

Start with one decision, such as confirming whether a vulnerable service is active and exposed. Define the exact queries, data fields, trust labels, policy threshold, allowed action, approver, rollback, and proof query. Add hostile instructions to a test field and confirm they cannot cross the action boundary. Osquery AI analysis is ready when a persuasive model mistake can be caught before it changes a host.

Continue with the definitive osquery handbook, the vulnerability detection workflow, and the practical query guide. The older human approval guide for AI in SecOps covers where automation should stop.