Anyone who has tried to operationalize a published agentic AI risk framework against a live environment runs into the same wall.
OWASP, NIST, and SANS have all done careful work naming the risk classes, and the categories are correct.
But the moment a security team tries to translate "watch for goal hijacking" or "detect memory poisoning" into an actual detection rule, the gap shows up. The telemetry that would let you observe the behavior the framework describes isn't in your log store, or it's there but never parsed into anything queryable.
The frameworks assume a monitoring foundation that most environments haven't built, and they say very little about what to do when that foundation is missing.
This guide covers both halves of the problem: the risk categories that matter most, and the underlying condition that makes them exploitable and harder to see in the first place.
Agents execute. That’s the difference.
A copilot suggests a query and waits for a human to run it, but an agent takes actions across systems with elevated permissions, which means a compromised agent is an active intruder operating with credentials you granted it.
Every deployed agent is also a non-human identity that accrues permissions over time, usually without the behavioral signals human-centric monitoring is calibrated to catch, and only about 10% of organizations have a well-developed strategy for managing those identities (Okta).
On top of that, Agent2Agent communication introduces implicit trust chains: one agent consumes another's output and acts on it, and traditional security architecture was never designed to evaluate whether that handoff is trustworthy.
The surface is expanding faster than the controls. Gartner predicts that 40% of enterprise apps will embed task-specific agents by the end of 2026, up from less than 5% in 2025.
The OWASP Top 10 for Agentic Applications, published in December 2025 with input from over 100 industry experts, is the current authoritative taxonomy for this surface. And the SANS Agentic AI Threat Map makes an observation worth holding on to: eight of the ten OWASP risks reduce to identity and authorization failures, not zero-days, which means most of them are, in principle, detectable with sufficient telemetry.
The useful question for a SOC team is which categories will succeed in your environment without generating a single alert, and why. These four are the ones where the attack and the blind spot that hides it are the same gap.
Multi-turn attacks across extended sessions achieved up to 92% success rates against open-weight models (Cisco State of AI Security 2026, via Help Net Security). Single-turn defenses, which most environments currently deploy, give no meaningful protection to an agent that maintains context across a session.
The detection gap is observability: if session-level traffic isn't in your log store, or the session log isn't parsed at ingestion, you cannot tell a hijacked agent from a functioning one based on behavior alone. The attack succeeds partly because the telemetry that would expose it was never collected.
Research cited in the same Cisco report confirmed that injecting 250 poisoned documents into an agent's knowledge store can implant a persistent backdoor that activates only when triggered by a specific phrase, while overall performance remains unchanged. This is a data provenance failure rather than a model quality failure, and it's invisible to any tool that evaluates the correctness of agent outputs. Catching it requires inspecting the knowledge store itself, a log source most SIEMs never receive.
A compromised upstream agent injects hidden instructions into the output that a downstream agent consumes and acts on. The documented case from the Cisco report involved a malicious GitHub issue carrying hidden instructions that hijacked an agent and triggered data exfiltration from private repositories.
The detection gap is that Agent2Agent handoffs typically don't generate individual log events in traditional SIEM infrastructure, so reconstructing what happened requires the full session trace across the entire workflow chain, which is a log source most environments have never connected.
When agents act without producing verifiable records of what they did and why, an investigation into suspected compromise loses its forensic foundation before it begins. This one is a forensics failure mode rather than an attack failure mode: the chain of custody breaks, and the compliance and governance audiences who depend on that evidentiary record have nothing to work from.
SANS is right that these are identity and authorization problems. But identity and authorization controls only work if you can observe the identity making the request, which returns the entire problem to monitoring coverage.
Start with the scale of the blindness.
48.9% of organizations cannot monitor machine-to-machine traffic at all (Salt Security 1H 2026 State of AI and API Security Report, based on surveys of over 300 security leaders). That is the attack surface going uninvestigated while agentic deployments expand.
The readiness gap compounds it: 87% of security teams prioritize agentic AI adoption, and 77% are comfortable letting it act without human review, but only 29% were prepared to secure those deployments when they launched (Ivanti 2026 State of Cybersecurity Report, 1,200+ respondents). This describes the median enterprise deploying agents today, not an edge case.
Strike48's own 2026 survey of 100 security leaders found that 84% report tools that cannot access all their log data for investigations, and 65% have had at least one investigation stall because data was trapped in a system their tools couldn't reach.
An investigation that stalls on missing data is exactly what an ASI05 or ASI08 attacker is counting on, and a well-designed Zero Trust architecture still misses a compromised agent operating in the 30% of the environment it can't see, where lateral movement leaves no trace. Parse-at-ingestion pricing forces teams to make coverage tradeoffs because storing and parsing every source is cost-prohibitive.
Strike48's architecture stores logs in raw form and parses them only when a query runs, which removes the constraint that engineers' blind spots are in the SOC in the first place. The full architecture discussion lives in the agentic security post.
When defenders and agents can see the complete log record, the attack classes above lose their cover.
Session traces across Agent2Agent handoffs become queryable data, so the same telemetry ASI05 exploitation that depends on going unlogged is now part of the investigation record. Knowledge store modification events appear in the audit trail, making memory poisoning detectable from the modification log itself rather than inferred from outputs that look fine.
Strike48's micro-agent architecture handles the agent design side at the same time: agents, given a narrow scope with GraphRAG persona graphs and MCP tool constraints, don't hallucinate to please you, and that constrained tool access limits the blast radius if a micro-agent is compromised.
The design detail is in the hallucination architecture piece. The third layer is human-in-the-loop approval for high-consequence actions like endpoint isolation and account lockout, and that oversight is only as good as the data reaching the escalating agent. Complete visibility, constrained agent design, and human judgment at the right points form one coherent architecture rather than three separate controls.
If the coverage gap in your current setup is the starting problem, see what Strike48's architecture looks like in practice.
What percentage of your log sources are currently monitored, and how was that number determined?
If the answer is "whatever fits the SIEM storage budget," the number reflects economics, not risk. Strike48's 2026 survey found 80% of security leaders cite the cost of keeping data live and searchable as painful or a major budget concern, which means most coverage numbers are budget-driven rather than risk-driven.
Can you observe the instructions your agents received and the actions they took throughout a complete session?
This is the ASI01/ASI02 detection requirement. If session-level telemetry isn't in your log store, multi-turn prompt injection leaves no trace. The real question is whether you have session-level agent logging, not just general logging.
What happens when an investigation requires log data from a system that your SIEM doesn't currently collect?
65% of security leaders have had at least one investigation stall on exactly this question. If the honest answer is "we manually export and re-ingest," that gap is a forensics liability and an ASI08 risk already running in production.
The attack that gets past you is the one your logs never recorded. That is the throughline across every risk class above. The framework names the threat. The detection rule still fails if the telemetry behind it was never collected. A hijacked agent and a healthy one look identical right up until you can see the session that turned one into the other.
Strike48 closes the cost-driven blind spot that hides these attacks. In early deployments, the mean time to detection dropped below eight minutes. The agents surfaced active phishing campaigns that legacy SIEMs had walked past, then wrote validated detection rules before a real attacker could run the same play. That does not happen on partial coverage. It happens because defenders and agents reason over the complete log record rather than the fraction of the storage budget left visible.
Your agents are deploying with or without that coverage. You can close the blind spot now, on your own schedule, or you can find its edges later, during the investigation that stalls on data your tools cannot reach. Adversaries already know which environments run blind.
See what complete coverage and purpose-built agents do in your own environment.
Request a demo.