Notifications
Clear all
Topic starter
19/08/2026 3:51 pm
TL;DR: AI agents expand attack surface beyond prompt injection because they can call tools, persist memory, and chain decisions, according to Fiddler’s analysis of agentic security risks. That makes continuous observability, least-privilege access, and sequence-level monitoring the controls that matter most, not static guardrails alone.
NHIMG editorial — based on content published by Fiddler: AI Agent Security Risks: Why Autonomous Systems Demand a New Threat Model
By the numbers:
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials.
Questions worth separating out
Q: How should security teams enforce least privilege for AI agent identities?
A: Start by treating every agent as an NHI with a dedicated identity, a tight permission boundary, and a named owner.
Q: Why do AI agents create more identity risk than traditional LLM applications?
A: AI agents create more identity risk because they can persist state, choose tools, and carry out actions over time.
Q: What do security teams get wrong about memory in agent systems?
A: Security teams often treat memory as if a vector store were enough.
Practitioner guidance
- Limit each agent to task-scoped tools Define the minimum callable tool set for every agent, then remove broad API, file, and database permissions that are not required for the specific workflow.
- Monitor memory writes and retrieval paths Log memory updates, retrieval hits, and corpus changes as security events so poisoned context can be detected before it persists across sessions.
- Trace every agent handoff end to end Deploy continuous telemetry across agent steps, sub-agent delegations, and tool calls so anomalous sequences can be identified before the workflow completes.
What's in the full article
Fiddler's full blog covers the operational detail this post intentionally leaves for the source:
- Step-by-step observability patterns for tracing every agent action across tool calls, memory access, and sub-agent handoffs
- Examples of security signals teams can watch for in production agent telemetry, including drift, anomalous tool use, and output divergence
- Expanded discussion of the AI Trust Tax and why inline evaluation changes the economics of agent governance
- Regulated-industry considerations for audit trails, explainability, and policy enforcement in autonomous decision systems
👉 Read Fiddler's analysis of AI agent security risks and observability controls →
AI agent security risks: are your observability controls keeping up?
Explore further
19/08/2026 4:26 pm
Autonomy changes the security unit of analysis from prompt to execution path. Traditional LLM controls focus on input and output boundaries, but agents create chained decisions, memory persistence, and tool execution. That means the real risk surface is the execution path itself, where one injected instruction can become a sequence of authorised-looking actions. Practitioners should treat agent workflows as governed systems, not chat interfaces.
A question worth separating out:
Q: How do security teams know if agent observability is actually working?
A: Observability is working only when teams can tie together token activity, tool calls, and latency for a specific agent session. If those signals are disconnected, the logs may show traffic but not governance. The test is whether investigators can reconstruct the path of a meaningful agent action from start to finish.
👉 Read our full editorial: AI agent security risks demand observability beyond prompt injection
