Agentic AI Security Platforms: What Agent Logs Miss

An agent’s logs are written by the agent. Every framework log, trace span and tool-call record that an agentic AI security platform ingests comes from the process being watched, or from a gateway that sees only what that process routes through it. When a trusted prompt coerces an agent into misusing a permission it already holds, the record shows a normal tool call, because from inside the process it was one. Running more analysis on that record returns the same answer faster.

This article follows one coerced sequence twice: through the log pipeline, then in runtime context. It then names what the log view cannot contain, where logs stay the right answer, and why evidence has to come from somewhere the agent cannot write.

What agentic AI security platforms analyze

Agentic AI security platforms work from records of what an agent did. They ingest framework logs, which the agent’s orchestration library writes when the model plans a step or calls a tool. They ingest traces, which follow one request through model calls, retrievals and tool invocations as a tree of timed spans, often in the format set by the OpenTelemetry semantic conventions for generative AI. They ingest gateway records, which an inline proxy writes for each model or tool request that passes through it. Then they run detection over the whole corpus, using rules, anomaly scores or a model that reads the records for signs of misuse.

Each of those records answers a narrow question. A framework log says which tool the agent chose and with which arguments. A trace says how long each step took and what it returned. A gateway record says which request crossed the proxy and whether policy allowed it. Together they make up the prompt and tool call records a team queries during debugging, cost reviews and investigations.

Who writes an agent’s logs

Agent logs start inside the agent’s own process. The agent runs as a process inside a container in a pod. That process loads an agent framework, and the framework exposes callbacks that fire when the model responds, when a tool is invoked and when the tool returns. Each callback formats a log line or a span and passes it to an exporter running in the same process. The exporter ships the line to your pipeline, and the pipeline turns it into the record your analysts query.

So framework logs and traces are self-reported telemetry. They describe the run as the process understood it: the tool name the framework dispatched, the arguments the model produced, the status the tool returned. Anything the process did outside a callback leaves no line at all. Anything the process did because trusted input asked for it is logged as a request it served.

Inline gateways share that limit from a different position. A gateway sits in the request path and writes its record independently of the agent, which makes it a real control point. It still sees only the requests the agent routes through it. A connection the process opens directly bypasses the proxy, and a file read or a credential picked up from a mounted volume never touches the network at all. Moving the analysis inline changes when a record gets checked. The agent’s own traffic still decides what gets recorded.

Why a coerced agent logs a normal tool call

Coercion is trusted input redirecting capability the agent is already authorized to use, so every step is permitted and the sequence is the attack.

The trusted input arrives through a channel the agent was built to read: a support ticket, a retrieved document, a message from another agent. That input asks for something that sounds like the agent’s job, phrased so the model plans a sequence its operators never intended. The plan calls a tool the agent is allowed to use. The tool runs under the permissions the agent’s service account and cloud role already grant, and it succeeds. The success returns to the framework, and the framework’s callback writes the entry.

That entry is correct. It names a registered tool, carries well-formed arguments and records a success. A rule keyed on failed calls, unregistered tools or denied permissions has nothing to match, because none of those happened. An anomaly model trained on the log corpus sees a tool this agent calls every day. That is why, after a coerced run, every symptom looks normal: the symptoms come from records the coerced process wrote about itself.

Sequence analysis over tool calls can flag an unusual order of calls, and it is worth running. It still reads only what the callbacks wrote, so the steps that never produced a line stay out of its reach.

The OWASP entry on excessive agency describes this condition from the design side: an agent whose functionality and permissions let manipulated input produce damaging actions. At runtime, the same condition produces clean logs.

One incident, seen through the log pipeline

Take a support agent running as a Kubernetes Deployment. It answers order questions for customers. It has three tools: a query tool scoped to the orders database, a code tool that runs short Python scripts for data reconciliation, and a reply tool that posts to the ticketing system through the team’s gateway. Its cloud role can read the bucket where order exports are stored, and reconciliation scripts read that bucket every day. The namespace allows direct egress.

A ticket arrives asking the agent to reconcile an order history and includes a short script “from finance” to run. The model treats the script as part of the task. The agent calls the code tool, the script runs, and the agent posts a reply saying the reconciliation found no discrepancies.

Three systems write a record of that run.

The agent’s own callback writes the framework log: a call to the code tool with the script as its argument, a success status and the output text. The code tool is registered, the arguments are well formed and the call succeeded.

The cloud provider writes the cloud audit log, which records what the agent’s credential asked for: a series of object reads against the exports bucket by the agent’s role. The role reads that bucket every day, and these reads were authorized too.

The gateway writes the last record, covering what the agent routed through it: one reply to the ticketing API, allowed by policy, with a normal payload size.

The run left three normal lines. One was written by the agent itself. The other two were written by independent systems, and both record requests the agent chose to make. None of them names the process that made the storage reads, and none records where the data went next.

Correlating agent signals in a SIEM has limits of its own. The problem here sits one step earlier: every line in the set is accurate, and the step that carried the data out was never written down.

The same incident in runtime context

Runtime context records the same run from outside the agent’s process. A sensor built on eBPF observes the workload at the Linux kernel, so it sees what the process does whether or not a framework callback fired. The run now reads as a chain.

The chain starts with a process. The code tool starts a Python interpreter as a child of the agent’s process, which is how the tool always runs scripts. That interpreter reads a file: the cloud credential mounted into the pod. The credential read is followed by connections to the storage endpoint, and the cloud events for those object reads carry the same role. The interpreter then opens an outbound connection straight to an external host, outside the gateway, and sends data out. The identity on every step is the agent’s service account and the cloud role bound to it.

ARMO’s attack story joins those events across process, file, network and identity into one chain attributed to the Deployment. The chain is then compared against the agent’s Application Profile DNA (APD™), the behavioral baseline ARMO keeps per agent at Deployment level. This agent’s reconciliation scripts have run many times, reading the same credential and the same bucket. None has opened a connection to a destination outside the gateway. The chain leaves the baseline at that connection, and the story carries the earlier steps with it: the process that opened it, the file it read first and the identity that fetched the data.

This view is what runtime behavioral security for AI workloads is built on. ARMO CADR assembles it across its detection layers, from the application and container up through Kubernetes and the cloud, so an analyst opens one story for the incident.

Runtime context is judged against what this agent has done before, so a coerced run that repeats only familiar actions in a familiar order is the hard case for it too. The log view has no reference for that comparison at all.

What the log view cannot contain

Set side by side, the two views differ in three things the log view cannot contain: actions below the application, the join, and independence.

Actions below the application

Actions below the application pass through no framework callback, and through a gateway only when network policy forces them to. The credential read and the direct connection in the incident above are both actions of this kind. A framework log records the tool call that caused them, and the cloud audit log records the storage requests they enabled. Neither records the actions themselves. The Kubernetes audit log has the same boundary inside the cluster: it records requests to the API server, and nothing a container does between those requests.

The join

The join is what turns separate events into one incident, and it can only link events that were captured. In the log view, the credential read and the outbound connection were never recorded, so the lines that do exist sit around a gap. No query over those records recovers a file read or a connection that nobody logged. In runtime context, every link is captured against the same workload at the moment it happens, so the chain arrives already whole.

Independence

Independence is the property that the record of an action comes from something the actor cannot influence. Framework logs fail it by construction. Gateway records and cloud audit logs meet it, but only for the requests the agent chooses to send through them. Where egress is open, a coerced agent can be told to route around the proxy, and in any setup it can be told what to report. Runtime telemetry captured at the kernel sits outside the agent’s reach, which makes it evidence the agent cannot fabricate.

Where logs stay the right answer

Agent logs remain the record of what the model saw and decided. With content capture enabled, they hold the prompt, the retrieved context, the plan and the tool arguments, which is the part of an incident that explains why the process acted. An attack story tells you the script read the credential. The framework log tells you which ticket carried the script.

Logs also remain the record for audit and reconstruction. They are retained, searchable and familiar to auditors, and they document that a given agent ran a given tool at a given time. The design choices about fields, retention and integrity belong to what to log for an agent audit trail. Reading that record at audit time, control by control, is its own job.

So keep the logs and read them for intent. Take detection from somewhere else.

Evidence has to come from somewhere the agent cannot write

A coerced agent does not break any control, so the only trace of the attack is in what it did. Records the agent writes, and records of requests the agent chooses to send, describe that activity as normal because each step was.

Detection has to rest on telemetry captured outside the agent’s process, attributed to the agent’s workload and compared with its own history. The framework log then explains the story that runtime context found. ARMO builds that record for agents on Kubernetes through security for AI workloads that runs in Audit first, so each agent’s baseline forms before anything is enforced. Put it on one agent, hand that agent a script it has never been asked to run, and see which step leaves the baseline.

FAQ

Do we still need agent logs if we have runtime detection? Yes. Runtime detection shows what the workload did, and agent logs show what the model was asked and what it planned, which is how you find the ticket, document or message that carried the coercion. Investigations need both halves. Keep logging prompts, retrieved context and tool arguments, and treat them as the explanation for incidents that runtime context detects.

Can a SIEM rule catch a coerced agent? A SIEM rule can only fire on records it receives. If those records are agent logs, cloud audit logs and gateway records, a coerced run produces successful, authorized entries that match no failure or denial condition. A rule gets something to fire on once the SIEM also receives runtime events from outside the agent, such as a credential read or a connection to a new destination attributed to that agent’s workload.

What does an agent’s framework log capture that runtime does not? It captures the application’s meaning: the prompt, the retrieved context, the model’s plan, the tool chosen and the exact arguments. Kernel-level process, file and network telemetry records the activity those decisions cause, and the reasoning behind them lives at the application layer. A tool-call record captured outside the agent’s process can cover the calls themselves, while the full triggering input still comes from the framework log when content capture is enabled.

How long should agent tool-call records be retained? Set retention by the longest of three windows: your regulatory or contractual obligation, the time it typically takes you to detect an incident, and the time an investigation needs afterward. Tool-call records are what reconstruct the triggering input, so they need to outlive the gap between a coerced run and its discovery. Keep runtime detections for the same period, so the two can be read together.

What is the first signal to add if we only have logs today? Add process and network activity for each agent workload, captured at the node and attributed to the Deployment. Two events carry most of the value early on: an agent’s process reading credential or token files, and an agent opening connections that bypass its gateway. Run in observation mode first so you learn what each agent normally does before anything alerts.