Where Untrusted Input Enters the Picture
This chapter follows one specific problem in LLM-driven AIOps: how a value that begins at a public application interface can become part of the telemetry an agent later uses for diagnosis. The focus is not on assuming that every log is hostile or every public endpoint is exploitable. It is on identifying the conditions that let external influence cross trust boundaries, especially through error records, and on giving readers a field-level way to distinguish useful context from unverified authority.
The mechanism is indirect. An external party does not need access to the log store, the observability platform, or the language model. They need a public action that causes the application to produce a telemetry record containing some of the action’s information. If the AIOps agent can later retrieve that record, the value has traveled from an external interface into the agent’s decision context through an ordinary operating path.
A value can cross several boundaries without changing its appearance
A useful way to understand telemetry injection is to follow the value’s lifecycle rather than looking for one dramatic breach. The value begins as information supplied through a public interface. The application receives it and performs some operation. If the operation fails or produces an event worth recording, the application may include relevant context in the resulting log, metric, or trace. A collector stores or forwards that telemetry. Later, an alert, ticket, or scheduled scan activates the AIOps agent, which queries the observability system and receives the record as part of its working context.
At each transition, the value can be transformed, constrained, delayed, or dropped. But it can also remain recognizable enough to influence what the agent sees. The attack model studied in the research requires three basic conditions: the target exposes a public interface; at least one telemetry instance incorporates information that can flow from that interface; and an AIOps solution consumes the resulting telemetry. The attacker does not need privileged access to the target’s internal data. They induce a new record through a legitimate interaction and rely on the application and observability path to carry the influence forward.
The important state change is not necessarily syntactic. The record may remain valid JSON, a recognizable log line, or a normal trace entry. What changes is its role. Before retrieval, the value is part of application output. After retrieval, it is evidence inside a process that can determine what the system does next. A field can therefore be structurally valid while still carrying an origin that should limit how much authority the agent gives it.
This is also why the attack surface is a property of the whole pipeline. The application determines which request information is preserved. The logging or instrumentation layer determines how it is represented. The collection system determines where it is stored and how it can be queried. The agent determines which records it retrieves and how they enter its context. Removing any one link may block this particular path, but the presence of a different link can create another.
The condition is not “the system has a web interface.” The condition is “the web interface can influence telemetry that the agent later consumes.” A public endpoint whose inputs are discarded before logging may not provide the relevant path. A record that contains the value but is never retrieved by the agent may not influence its decision. Conversely, a narrow field—such as a request URL, user-agent value, or username preserved in an error—can be enough if it reaches the agent in a context where the agent treats it as meaningful evidence.
Why error records become useful carriers
Applications log errors because failures are often the most informative moments in an incident. A successful request may confirm that a service worked, but a failed request can reveal which operation was attempted, which object was missing, which validation rule rejected the input, or which dependency returned an unexpected result. Context that helps an engineer reproduce and diagnose the failure is therefore likely to be included in the event.
The research focuses on this ordinary behavior. Error events commonly preserve user-generated data that contributed to the error. A request for a nonexistent resource may leave the requested path in a server record. A failed operation involving a user may preserve the relevant username. An HTTP failure may retain request metadata such as a referrer or user-agent value. These fields are useful precisely because they connect the error to the interaction that produced it.
That usefulness creates a tension rather than a reason to suppress errors. If an application removed every request-related value, an investigator would lose important context. If it recorded every value without classification, the log would become a channel through which untrusted content can travel. The engineering question is which context is necessary for the intended purpose, which parts are controlled by the application, and which parts originated in a request or another trust zone.
OWASP’s logging guidance starts from a similar premise: application code often knows more about the user, roles, permissions, target, action, and outcome than infrastructure logging does. It recommends recording security-relevant events such as validation failures, authentication and authorization failures, application errors, and suspicious business-logic activity. It also warns that data arriving from another trust zone may be missing, modified, forged, replayed, or malicious. The two recommendations belong together. Rich event context is valuable, but its origin must remain visible.
A useful event can be organized around “when, where, who, and what.” Time includes both when the event occurred and, when relevant, when it was logged. Location can include the application or service identity and the point where the event was observed. “Who” can be a human or machine identity, an account, or a source address. “What” includes the event type, severity, description, action, object, result, and reason. Those fields create a strong basis for correlation and investigation, but they do not all have the same trust status.
For example, an application may generate the event type and result status itself, while the username or source address may be known only through data supplied by a client or another system. A field can be constrained to a valid format and still represent an untrusted claim. A source address may be useful for detecting patterns without proving who was responsible. A user-provided description may help explain intent without being evidence that the described cause is true. Treating these distinctions explicitly is more useful than labeling the entire record simply “trusted” or “untrusted.”
Four controls that solve different problems
The phrase “secure the logs” hides several separate controls. Validation checks whether incoming event data has the expected format, type, or allowed values. It helps prevent malformed content from being accepted as a legitimate field, and it can identify activity that should itself generate an alert. Validation does not prove that a correctly formatted value is truthful.
Sanitization removes or neutralizes content that could alter the structure or interpretation of a log. OWASP specifically calls for sanitizing event data to prevent log-injection attacks, including characters such as carriage returns, line feeds, and delimiters when those characters can create forged or truncated entries. Sanitization protects the record’s structure. It does not necessarily remove a semantically plausible sentence that is perfectly valid inside a field.
Encoding ensures that data is represented correctly for the output format. Without it, a value can be interpreted as control syntax by a downstream parser or viewer. Encoding preserves the boundary between data and format, but, like validation, it cannot establish that the data deserves decision-making authority.
Masking, hashing, encryption, or exclusion address confidentiality and data minimization. Logs may contain passwords, tokens, secrets, sensitive personal data, or information that the logging system is not allowed to store. Removing or transforming such values limits the damage of unauthorized access and reduces unnecessary exposure. It can also change the information available to an agent, which makes the purpose of each field and the resulting loss of detail worth documenting.
These controls should not be treated as interchangeable. A record can be well encoded but reveal a secret. It can be sanitized against delimiter abuse but still contain a misleading explanation in a normal field. It can be validated as a string but lack trustworthy provenance. The AIOps-specific concern begins where traditional parser safety ends: a well-formed value may still influence a semantic judgment.
That distinction also explains why data minimization must be purposeful. Removing all user-influenced context might block one injection path, but it can impair incident response and obscure the sequence of events. Keeping all context raw may preserve forensic value but expose the agent to content it should not interpret as authoritative. A stronger design can retain a detailed record for controlled human investigation while supplying the agent with a representation that marks or abstracts untrusted fields.
The classification has to survive the trip through the pipeline. It is not enough for an application developer to know that a request field was user supplied if the collector later flattens it into an undifferentiated message. It is not enough for a storage system to preserve a raw record if the agent’s retrieval interface hides the record’s origin. The boundary should remain legible in the event model, the collection process, and the agent-facing representation. That may mean preserving a field’s source, recording an interaction identifier that connects related events, or attaching an indication of analytical confidence. These measures do not make the value true; they make the conditions of interpretation visible.
Suppose an event contains an application-generated result, a service identity, and a username copied from a request. The first two may be useful for locating the event and comparing it with other service records. The username may be essential for investigating repeated failures, but it is still an externally influenced value. An operator can use it as a lead. An agent can use it to correlate related events. Neither should silently treat it as proof of identity, intent, or cause. The distinction is small at the field level but significant at the decision level.
There is also a failure-handling trade-off. Rejecting malformed event data may protect the log’s structure, but a logging failure should not prevent the underlying application from running or create a new information leak. That means the system needs an explicit choice about what to discard, what to flag, and what to retain in a safe form when validation fails. A pipeline that quietly drops every difficult record may look clean to the agent while depriving operators of evidence. A pipeline that accepts everything may preserve evidence at the cost of making the agent’s context easier to manipulate. The right behavior is purpose- and risk-dependent, but it should be observable rather than accidental.
Testing the boundary without overgeneralizing it
A deployment assessment should begin with a map of information flow, not with the assumption that a particular model or logging product is the decisive factor. Identify public interfaces and the event types they can generate. For each relevant event, ask which fields come from the application, which come from external requests, and which are copied from other systems. Then determine where the records are stored, how long they remain queryable, and whether the AIOps agent can retrieve them during activation.
The result should be a set of conditional paths, not a claim that every endpoint is dangerous. Some interfaces may not produce telemetry. Some telemetry may be transformed so heavily that the external value no longer survives in a useful form. Some records may be visible to operators but outside the agent’s query scope. Some agents may only recommend changes, while others can pass solutions to execution tools. Each missing link changes the consequence.
The paper’s threat model also limits what can be inferred. It demonstrates a low-privilege path under conditions where user-influenced information reaches agent-consumed telemetry. It does not establish that all public applications have that path, nor that every telemetry source can carry the same content. Its examples center on application errors and web-facing interactions; other systems may preserve different fields or use different encodings.
The practical lesson is precise: logging an event does not make every field trustworthy, and treating a field as untrusted does not make the event useless. AIOps needs the event for diagnosis, but the agent needs to know which parts are descriptive evidence, which parts are derived by controlled components, and which parts may have been supplied by an external party. Once that classification is explicit, the next question is whether all the necessary links can align into a complete failure chain—from public action, to telemetry, to agent ingestion, to remediation.