Overview

AIOpsShield maps attacker-influenced telemetry before deployment by enumerating paths and using canary values to identify variable fields. At runtime it matches regex templates for loose logs or schemas for structured telemetry, then replaces known untrusted parameters with stable abstract names while retaining raw records for controlled human investigation. In the tested SocialNet, HotelReservation, and AstronomyShop configurations, setup generated 84, 12, and 132 templates, and none of the repeated telemetry attacks succeeded. Across 12 fault scenarios, average utility was around 50% with and without the shield. The evidence is bounded by coverage, heuristic matching, task assumptions, input scope, and action authority.

Learning outcomes

Setup-time enumeration and canary taint analysis identify which telemetry fields may carry external values.
AIOpsShield abstracts known untrusted parameters for the agent while retaining raw telemetry for controlled human review.
It blocked the tested attacks and kept utility around 50% in 12 scenarios, but coverage and action controls remain necessary.

Keywords

AIOpsShieldTelemetrySanitizationTaintTemplatesAbstraction

AIOpsShield and the Limits of Sanitization

AIOpsShield is the paper’s attempt to solve the problem identified in the earlier chapters: preserve telemetry for incident investigation while preventing attacker-controlled fields from reaching an AIOps agent as persuasive evidence. This chapter follows the defense from setup-time discovery to runtime sanitization, explains why loose logs and structured metrics or traces need different treatment, and uses the reported results to judge what the mechanism protects. The practical conclusion is bounded: AIOpsShield is a targeted layer for a defined telemetry-injection path, not a universal firewall for every input an autonomous agent can receive.

The design takes advantage of properties that are unusually useful in AIOps. The paper assumes that the application’s telemetry output is fixed and can be enumerated before deployment, that telemetry is structured enough to parse, and that user-provided data has limited utility for legitimate RCA. Those assumptions create an information advantage for the defender. A defender with access to the application and its observability configuration can test the paths in advance, while a low-privilege external attacker has to discover them indirectly.

Setup-time discovery turns an unknown path into a known boundary

The setup phase happens before the agent is deployed. Its purpose is not to inspect every possible future sentence or predict every attack payload. It is to discover where external values can appear in telemetry and to describe the surrounding record well enough to separate stable structure from variable content.

The first task is enumeration. The defender identifies the application interfaces and the telemetry sources within the agent’s reach. This can be informed by application knowledge and white-box access, and the paper also describes an automated crawler and fuzzer that can exercise endpoints. The important output is a map of candidate paths: which application actions may create records, which fields may be populated with external values, and which logs, metrics, or traces can later be retrieved by the agent.

The next task is taint analysis. The defender places a unique canary value into the inputs used during testing, then extracts the resulting telemetry. Any record containing the canary is evidence that information from the tested input reached that telemetry path. The canary is not a permanent marker for production data. It is a probe that reveals which parameters in a record are variable and potentially attacker-controlled.

This is different from searching for malicious language. The setup process does not need to guess whether a future value will say something suspicious. It asks a simpler structural question: which part of this event can change because of an external action? A username field, request path, or exception message may be legitimate in one context and dangerous in another. Once the variable position is known, the defense can treat its future content as untrusted without discarding the rest of the event.

The approach also depends on coverage. If endpoint enumeration misses a route, or if testing does not exercise a path that produces telemetry, the resulting templates will not describe that path. The defense’s information advantage is real only when the defender uses it thoroughly. A canary is evidence of an observed flow, not proof that no unobserved flow exists.

Coverage is also a maintenance problem.

Published by DeepMox

FAQ

How does AIOpsShield find attacker-controlled telemetry fields?

It enumerates reachable paths, injects canary values during setup, and traces which records and parameters contain them; the canary reveals observed flow rather than proving complete coverage.

How does AIOpsShield sanitize telemetry before agent inference?

It matches known records with regex templates or schemas and replaces identified untrusted parameters with stable abstract names, while raw telemetry remains available to controlled operators.

What did AIOpsShield’s utility test show?

Across 12 AIOpsLab fault scenarios, average success was around 50% with and without the shield; one additional run failed with it, a difference the paper called statistically insignificant.

Previous11 minLLM-driven AIOps: Trustworthy Telemetry

Next10 minLLM-driven AIOps: Safe Autonomy

LLM-driven AIOps: AIOpsShield Sanitization

AIOpsShield and the Limits of Sanitization

Setup-time discovery turns an unknown path into a known boundary

FAQ