Orca Security: Agentic AI Security

What it is

Orca Security's guide to agentic AI security. The summary already carries the plan-as-unit-of-risk framing, the OWASP ASI T1–T17 / CSA MAESTRO taxonomies, the run-level control set, and the RFC 8693 delegation material. What it omits are three things an engineer can act on: a version boundary on the taxonomy, the eight threats mapped to their structural cause, and a testing method for non-deterministic systems.

Version boundary worth checking before you cite

OWASP's Agentic AI – Threats and Mitigations is at v1.1 (December 2025) with 17 threats (T1–T17). Earlier versions listed 15. The page explicitly says to check the taxonomy version before citing it — a numbered threat may not mean the same thing across versions. MAESTRO is CSA's alternative, published by Ken Huang in February 2025: seven layers plus a cross-layer threat category (e.g. goal misalignment starting in a data layer and propagating through agent interactions) that a flat list has no room for.

The eight execution-level threats and what produces each

The page selects 8 of the 17 as arising from autonomous multi-step/multi-agent execution, each tied to a specific structural property:

• T6 Intent Breaking / Goal Manipulation — gradual sub-goal injection; plan drifts while each step looks logical (compounding plan)
• T2 Tool Misuse — agent abuses authorized tools after ingesting manipulated data; nothing misconfigured (runtime trust boundary)
• T1 Memory Poisoning — false data persists short/long-term, outlives the session (compounding plan)
• T5 Cascading Hallucination — plausible falsehood propagates through memory/tools/agents
• T4 Resource Overload — unbounded loop becomes a DoS against its owner
• T10 Overwhelming Human in the Loop — flood of low-priority approvals so the important one gets rubber-stamped
• T12 Agent Communication Poisoning — forged consensus messages defeat inter-agent validation
• T14 Human Attacks on Multi-Agent Systems — loop a request between agents until each grants access "under the assumption of prior validation"

Note T8 (repudiation/untraceability) as the justification for replayable per-step records. Prompt injection is treated only as a delivery mechanism here.

Testing a system that behaves differently every run

The page gives a repeatable method the summary doesn't: test the boundary, not the path. Run the same goal many times, record which tools and destinations the runs actually touch, and compare that set against what policy permits. A path passing once proves nothing; an egress boundary that held across ~200 runs is evidence. Adversarial runs go in the same harness, with the injected instruction arriving through a tool result (not the prompt).

Delegation failure mode to look for

Token forwarding widens authority by default (downstream service can't distinguish the agent's own rights from the delegated user's); RFC 8693 exchange narrows it via scoped downstream tokens. The concrete bug: three hops narrow authority, then one sub-agent inherits a token instead of requesting a narrower one and acts under authority nobody evaluated. Authenticate every agent-to-agent call at the orchestrator; reject any call without a verifiable requester claim.

Caveats

Neither OWASP's nor CSA's artifact is a complete control baseline — both organize threats, leaving you to map to your own framework. Orca's own role is scoped: it does not orchestrate agents or decide whether an action is allowed; it inventories the AI services, keys, data, and reachable paths in your cloud (agentless SideScanning) to size blast radius. The action-class approvals, egress policy, and delegation chain stay with you even on a managed platform.