Runtime monitoring for an AI agent estate

Context

A financial services provider had moved faster than most into production AI. By early 2025 they were running a small estate of agents across operations, client communications, and internal decisioning workflows. The development team was experienced and the build-time controls were reasonable. The monitoring was not.

When the security team asked “how would we know if one of these agents was doing something it should not?”, the honest answer was: we would probably find out from a consequence rather than from a signal. There were application logs, but no agent-action schema, no anomalous tool-call detection, and no integration with the existing SIEM. The board had started asking questions about AI operational resilience. This engagement was the answer to those questions.

Risk

• Undetectable injection and tool abuse. The agents ingested content from external feeds and user-supplied documents. If an indirect injection landed and steered an agent to call a tool it should not, the existing logs would record the tool call but nothing about the context that caused it. The investigation window was effectively zero.
• Blind spots between agent decisions and SOC alerts. Agent telemetry was not feeding the SIEM. An anomalous tool-call pattern on an AI agent would never generate the correlated alert that would surface it to an analyst. The AI estate was invisible to the security operations team during live operation.
• No behavioural baseline, so no deviation signal. Without a baseline of normal per-agent behaviour covering typical tool sequences, call rates, and data volumes, there was no way to detect drift caused by a poisoned model or corpus, or an agent gradually being walked off-task by a low-and-slow injection.

Engagement

We structured the work across three areas, sequencing logging before detection before integration.

• Agent-action logging schema. We defined the structured, correlated logging schema covering prompts and context provenance, intermediate decisions and plans, every tool call with its arguments and authorisation result, connector responses, and final outcomes. Every record carried a trace identifier so a full agent task, across multiple model calls and tool invocations, reconstructed as one causal chain. The log store was then brought inside the existing data-protection control set, because a verbose agent log containing customer data is itself a regulated-data asset.
• Layered runtime detection. We layered three complementary signals over the agent-action stream: injection and jailbreak signature detection seeded from the OWASP Top 10 for LLM Applications and the team’s own incident history; anomalous tool-call detection alerting on invocations with arguments outside their normal distribution or tools called with scope they had never used; and behavioural baselining per agent and per workflow, with change-controlled baseline updates so a legitimate change to an agent’s prompts or connectors did not silently reset the detector.
• SOC and SIEM integration. We treated AI telemetry as a new source for the existing SOC, not a parallel console. Agent alerts correlated with identity and network events in the SIEM, so an anomalous tool call alongside an unusual session identity was a far stronger signal than either alone. Each AI alert class got a named triage owner and a playbook, with a defined false-positive tuning loop to bring the alert volume down over the first 60 days.

Outcome

Detection narrows the window between compromise and discovery, but it is paired with containment, which bounds the damage regardless of whether detection fires. For the full picture of how agentic AI estates are monitored, contained, and governed in regulated environments, read Agentic AI and MCP security.