Notifications
Clear all
Topic starter
07/09/2026 4:38 pm
TL;DR: AI agents can act within their entitlements and still become incident vehicles, because most environments log prompts before they log tool use, leaving behaviour invisible, according to AiStrike. The real control gap is not intent but observability: if you cannot join retrieval, tool-call, and identity telemetry on one principal, you cannot tell normal agent work from abuse.
NHIMG editorial — based on content published by AiStrike: Agents Watching Agents: AI Agent Security Is a Detection Problem
Questions worth separating out
Q: How can security teams tell normal AI agent activity from misuse?
A: By building per-agent baselines for API frequency, payload size, destination patterns, and process behaviour, then comparing live activity against those baselines.
Q: Why do prompt logs fail to show the full risk of AI agent misuse?
A: Prompt logs show what the model was asked, not what the agent did after deciding to act.
Q: What are the signs that AI agent telemetry is too weak for investigation?
A: If security teams can see prompts but cannot reconstruct tool invocations, retrievals, or data egress on the same principal, telemetry is incomplete.
Practitioner guidance
- Instrument tool-call telemetry at the broker layer Capture every agent tool invocation, argument shape, and calling identity where the agent framework emits actions, not only where the model returns text.
- Baseline behaviour per agent principal Compare each agent's retrieval patterns, tool chains, and timing against a rolling baseline so rare combinations surface as leads rather than noise.
- Join prompts, tools, and retrievals into one schema Normalise all agent telemetry into the same schema used for security operations so one session can be reconstructed across model input, tool use, and data movement.
What's in the full article
AiStrike's full blog covers the operational detail this post intentionally leaves for the source:
- Feed-by-feed telemetry mapping for prompts, tool calls, retrieval events, and identity resolution
- The specific MITRE ATLAS technique set the vendor uses to classify agent misuse
- A worked detection pattern for rare tool chaining such as retrieve then send
- How the vendor instruments agent frameworks, MCP servers, or OpenTelemetry GenAI traces
👉 Read AiStrike's analysis of AI agent security as a detection problem →
AI agent telemetry and detection gaps: what are teams missing?
Explore further
07/09/2026 4:38 pm
AI agent security has crossed from entitlement management into behaviour intelligence. Traditional IAM and NHI controls answer who may access a system, but they do not explain what an agent actually did after access was granted. That matters because AI agents can remain inside scope and still become vehicles for retrieval abuse, data movement, or outbound disclosure. Practitioners should treat runtime behaviour as a first-class governance signal, not a forensic afterthought.
A few things that frame the scale:
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), according to AI Agents: The New Attack Surface report.
- 52% of companies can track and audit the data their AI agents access, which means 48% still have a complete visibility gap for compliance and breach investigation.
A question worth separating out:
Q: How do NHI controls and AI agent detection work together in practice?
A: NHI controls establish ownership, entitlement review, and lifecycle accountability. Detection adds runtime evidence by showing whether the agent used those entitlements in a normal or abnormal way. Together, they let teams govern access before execution and investigate behaviour during execution, which is the only way to handle agent-driven incidents cleanly.
👉 Read our full editorial: AI agent security is a detection problem, not just governance
