A Map of Where Attacks Happen

Several frameworks already cover pieces of this problem: OWASP's Top 10 for LLM and Agentic Applications, Google's Secure AI Framework, MITRE ATLAS, and the NIST AI Risk Management Framework. Each is valuable. None maps an agent's architecture to its deployment context, which is where attacks actually happen.

The Straiker STAR Framework answers that on two axes at once. The first is agent architecture: every agent, regardless of vendor, runs on the same four layers. The second is deployment context: every enterprise agent lands in one of three roles, each with its own trust posture and blast radius. Their intersection is where attacks happen, and where this report's data lives.

The STAR Framework: four architectural layers (rows) across three agent types (columns). Tools & MCP is the surface shared by all three.

Layer	Coding AgentsEndpoint · local shell	Productivity AgentsStraddle · OAuth scope	First-Party AgentsRemote · operator trust
ApplicationOrchestration, state, approval gates	No gate Agent-generated shell commands auto-execute	No gate Irreversible actions fire unprompted (Drive wipe / send)	No gate Outputs act on internal APIs with operator trust
ModelReasoning & instruction hierarchy	Injection Poisoned code / README reframes intent	Injection Indirect injection from email & documents	Injection Operator-trust instruction override
Tools & MCPConnectors, servers, APIs — shared surface	Supply chain Local MCP binary poisoning, rug pulls	Scope abuse OAuth over-scope, tool-result injection	Registry Weak per-tool auth, rogue registration
▶ One malicious MCP server compromises all three agent types at once // 4,242 cataloged servers carry ≥1 vulnerability
DataRAG, memory, docs, uploads	Poisoning Poisoned README / dependency → laptop RCE	Poisoning Poisoned invite / email → PII exfiltration	Poisoning Poisoned RAG / connector → enterprise breach
Dominant outcome	RCE on the developer endpoint	91% end in silent data exfiltration	Enterprise-wide blast radius

AiPT and LAVA: naming what's new

Two named categories describe the agentic threat landscape. AiPTs are the new adversary; LAVA is the vulnerability class they exploit.

AiPT

AI-Powered Persistent Threats: adversaries operating with agentic offensive toolkits. They automate reconnaissance, generate exploits for the specific target, persist in the semantic layer traditional defenses cannot read, and operate as agents themselves. Cyberspike Villager is a documented example.

LAVA

Language-Augmented Vulnerabilities in Applications: the exploit lives in the language an agent reasons over. The payload is content the agent reads and then follows, like a poisoned README driving an SSRF, or attacker input passed straight into a SQL-injectable MCP tool. No scanner sees the agent decide to deliver it.

The four architectural layers

Every agent runs on the same four layers: application, model, tools and MCP, and data. Attacks rarely stay in one. A poisoned document in the data layer is a form of indirect prompt injection: the instruction hides in content the agent reads, not in what the user types. It is read as instruction by the model, executed by the tools and MCP layer, and surfaced as real-world action by the application layer when no approval gate stops it. The same mechanism now rides Skills, the packaged instruction files agents load as trusted context. Knowing which layer is exercised tells defenders which control breaks the chain. STAR Labs found that 75% of tested agentic applications are vulnerable to injection at the model layer.

Application interface · orchestration · approval gates

Missing approval gates · unchecked output → action

Break it

Approval gates on every irreversible action.

Tools & MCP tools · MCP servers · connectors · APIs

Tool poisoning · tool-result injection · rug pulls · spoofing · rogue registration · binary supply chain

Break it

Sign & pin servers; per-tool authorization.

Model LLM reasoning · instruction hierarchy

Prompt injection (direct / indirect) · jailbreak · instruction-hierarchy attacks

75% of tested agentic apps are injectable here

Break it

Instruction-hierarchy enforcement & injection guardrails (runtime, not just model guardrails).

Data RAG · memory · documents · uploads

RAG poisoning · cross-session memory poisoning · context-window stuffing · malicious upload

Attack enters here: poisoned README, malicious invite, tainted RAG doc. Most LAVAs land here first.

Break it

Treat all input as untrusted; check provenance.

One attack, four layers. It enters at Data, is read as instruction by the Model, executed by Tools & MCP, and surfaced as real-world impact by the Application layer. Stop it at any layer and the chain breaks.

Common Questions

What is the Straiker STAR Framework for AI agent security?

The Straiker STAR Framework is a model for securing AI agents across four architectural layers (application, model, tools & MCP, and data) and three deployment types (coding, productivity, and first-party agents). Built by Straiker's STAR Labs (STAR = Straiker AI Security Research), it maps where agentic attacks actually happen so defenders know which control breaks each step of the chain. It is distinct from the STAR interview method.

What is indirect prompt injection, and how is it different from a jailbreak?

Indirect prompt injection is when an attacker hides instructions inside content an agent reads — a document, email, README, web page, or Skill — rather than typing them into the chat. The agent treats that buried text as a command. Unlike a jailbreak, the user is not adversarial and the model is not misbehaving; the context has been weaponized. It is the most common entry point for agentic attacks.

Are AI agent Skills, like Claude Skills or Vercel Skills, a security risk?

Yes. A Skill is a packaged instruction file an agent loads as trusted context, so a poisoned or malicious Skill is indirect prompt injection with a distribution channel — the same risk as an untrusted README or rules file, shared at scale. Independent audits of public Skill directories have found prompt-injection payloads and credential-stealing code in a meaningful share of packages. Treat every Skill like third-party code: review its instructions, pin versions, and install only from sources you trust.