AI Agent Security Skill Risks Mapped to Developer Responsibilities

AI agent security risks become manageable when each has a named developer owner, a testable control, and reproducible evidence. This article maps prompt injection, tool abuse, overprivileged access, memory poisoning, trust boundary violations, and supply chain compromise to those responsibilities. Ownership must follow the agent’s full execution path from its input boundary onward.

Why AI agent security requires a different ownership model than traditional application security

Peizhi Niu of UIUC and Dawn Song of UC Berkeley frame an always-on agentic system as analogous to an operating system. The gateway runtime is the kernel, skills are user-installed applications, and plugins are loadable extensions with runtime privileges. The analogy exposes the missing safeguards. These systems do not have the process isolation, permission models, and sandboxing that have supported operating-system security for decades. A skill is therefore not merely another source of text but part of an environment that can act with privileges.

Unlike a REST API or web application, an agent plans multi-step workflows, calls external tools, retains memory across sessions, and delegates to sub-agents. Each capability creates a separate attack surface. Securing ingestion does not define who may write memory, and restricting one agent does not establish what its orchestrator may trust. Because no framework assigns these responsibilities by default, a developer must explicitly own each one or leave a production gap. The resulting map covers six categories, namely prompt injection, tool abuse, overprivileged access, memory poisoning, trust boundary violations, and supply chain and release workflow risks.

Prompt injection as an entry point into autonomous execution chains, and what that means for developer ownership

Prompt injection becomes structurally more dangerous when the recipient can act autonomously. An injected instruction at the first step can corrupt an answer and influence downstream actions, tool calls, and memory writes. The entry point need not be direct. With indirect injection, an agent reads attacker-controlled material in web pages, documents, emails, or tool outputs and treats that material as instruction. The security boundary is crossed when content from the environment gains the power to direct execution.

The Vertex AI “Double Agent” incident of March 31–April 1, 2026 demonstrates how injection and permission scope can combine. Default permission scoping enabled credential exfiltration through combined LLM02, LLM03, and LLM06 risks. Input manipulation enabled privilege abuse because the accessible scope had not been explicitly constrained.

The developer must enforce the input boundary before material from the environment enters model-visible context. Retrieved documents, tool outputs, and inter-agent messages must be untrusted by default, with validation, sanitization, and explicit separation between memory and instructions. Those controls need ongoing tests, even after they have been marked complete. MATRA concludes that existing defenses can reduce the probability of successful injection or detect it, but cannot eliminate it. The ingestion and retrieval engineer should therefore own this boundary, with verification that an indirect injection through each data source fails to propagate to tool execution in reproducible tests.

Tool abuse and overprivileged access as an architecture problem the deploying engineer inherits entirely

Once an agent can call tools, the decisive question is what those calls are permitted to do. Agents often get APIs, shell access, file I/O, and database capabilities that go beyond what their tasks need. That scope is an architectural decision. Least-privilege access is not enforced by a framework on the deploying engineer’s behalf, so accepting the default is itself a decision about authority. Tool abuse and overprivileged access belong together in the ownership map because the tool manifest and how it is enforced set both what is exposed and how far an attack can reach.

CVE-2025-6514, with a CVSS score of 9.6, provides a concrete example of remote code execution through MCP infrastructure. MATRA’s OpenClaw case study shows that network sandboxing and least-privilege access reduce risk by limiting the blast radius of successful injections. These controls constrain what execution can accomplish. A prompt-level defense and an execution-level restriction do different jobs, even when they work against the same attack chain.

The deploying engineer should own tool allowlisting, just-in-time access rather than standing privileges, and pre-execution tool-call auditing. Each can become a discrete engineering ticket with a testable acceptance condition. Allowlisting is the easiest place to start and has the greatest impact because it sets exactly which tools are allowed and ends access that is open by default. Timing is equally important to enforcement. Deterministic controls that deny, redact, minimize, quarantine, or require approval before execution can prevent an action that post-hoc monitoring can only record. Verification should establish that every permitted tool has a task-specific justification and that its scope is enforced before the call runs.

Memory poisoning as a persistent, cross-session attack surface with no framework-level protection

Stateless applications do not have this persistence problem. An agent’s memory can keep a corrupted belief, goal, or trust judgment through future sessions, long after the original hostile input is gone. A single poisoning event can therefore extend the attack through time, while gradual corruption may remain undetected. Memory ownership is distinct from ingestion ownership because the write surface and the later read surface are different systems. Validating an incoming document does not, by itself, govern what becomes durable state.

Lakera AI’s November 2025 research showed that poisoned data sources could corrupt long-term memory and leave it with lasting false beliefs about security policies and vendor relationships. Cisco’s MemoryTrap disclosure in May 2026 showed that a compromise in Claude Code could span more than one session and project. Persistence changes the unit of investigation. Investigation must trace both what the agent read during the current session and which earlier write established the information it now trusts. That history cannot be recovered from the current prompt alone.

The MAESTRO framework identifies memory poisoning through log tampering and poisoned embeddings within Layer 2, Data Operations, which includes vector stores, RAG, and agent memory. PoisonedRAG, presented at USENIX Security 2025, also showed that knowledge base corruption attacks had a high rate of success in experiments. Retrieval is thus an active attack surface. The memory-store engineer should own the rules for write-access governance, the integrity controls, and the structured tagging that keeps memory separate from instructions. Provenance must be fine-grained enough to identify the write that crossed a trust boundary, with verification that corrupted or tampered memory is flagged before it influences decisions.

Trust boundary violations in multi-agent pipelines and the privilege escalation they enable

Multi-agent pipelines add a failure mode that single-agent permissions cannot resolve. A compromised low-privilege sub-agent can pass manipulated output to a higher-privilege orchestrator and sway actions it could not carry out itself. No component needs to appear individually abusive. The escalation happens when one agent’s output becomes another agent’s authority, so the security policy must cover that transition as well as the agents on either side.

The composition problem is concrete in a three-agent pattern. Agent A queries a database, Agent B emails the results externally, and Agent C orchestrates both actions. Each step can look legitimate in isolation. Together, the steps can still do what the attacker wants, which an audit of each component on its own misses. This is why inter-agent communication cannot be treated as trusted internal traffic simply because every participant belongs to the same deployment.

CVE-2025-68144, an argument injection flaw in the MCP Git server, mcp-server-git, demonstrates a related boundary failure at the tool-call interface. HDP, introduced in 2026, addresses human delegation provenance when agents re-delegate to sub-agents, while AgentSpec at IEEE/ACM ICSE 2026 provides customizable runtime enforcement. ToolGate at ACL 2026 addresses contract-grounded and verified tool execution. The architect who defines the topology should own clear contracts that set what sub-agents may pass upward and what orchestrators may accept. Cross-agent audit logging needs that same named owner because the evidence must keep inter-agent messages and show what the components did together as well as on their own.

Supply chain and release workflow risks as the attack surface where developers bear the clearest direct liability

Supply chain attacks shift what developers must own from runtime behavior to the code and configuration admitted into the deployment. MCP packages, framework dependencies, and plugin marketplaces are active targets, with exploitation occurring on timescales measured in hours. Release history and artifact provenance are insufficient assurances. A package can come through a release path that looks legitimate even when the source or signing identity has been compromised.

The October 2026 LiteLLM case illustrates that distinction. Its release workflow built from the lookalike repository Berri-AI/litellm, where ten commits were pushed on the morning of the attack. Backdoored builds were downloaded during the roughly two hours they were available on PyPI. Valid artifact provenance did not prevent the compromise. Tensorlake’s October 8, 2026 incident exposed the same limit through malicious commits pushed directly to tensorlakeai/tensorlake’s main branch under a maintainer identity without a pull request. Its release workflow published version 0.5.144 at 01:12 UTC with valid npm provenance despite the compromised signing identity.

The postmark-mcp package shipped fifteen clean releases before adding email exfiltration code, an attack documented as MITRE ATLAS case study AML.CS0053. CVE-2025-59536, with a CVSS score of 8.7, involved hooks injection in a coding agent, where malicious repository configuration executed when the agent opened the workspace.

The release engineer should own dependency pinning with hash verification, signed workflows that log the build’s source repository, and human review gates before dependency updates affect tool or plugin registries. Each new MCP package should get the same security review as a code change. Source identity requires explicit review as well. The LiteLLM and Tensorlake cases show why checking an artifact hash cannot substitute for checking the repository identity when the signing identity is compromised. The Coalition for Secure AI’s July 2025 principles support this ownership model through dependency pinning, signed release workflows, least-privilege tool scoping, and human gates for irreversible actions.

Converting the threat map into assigned, verifiable developer responsibilities

A threat category becomes an owned responsibility only when three conditions hold. A specific engineer or role is named, the control is precise enough to test, and someone other than the implementer can reproduce the result. A policy document alone does not qualify. MATRA connects attack-tree-driven threat modeling to architectural controls, providing a method for moving from a claimed defense to evidence that it interrupts a defined attack path. The test must check how the deployment’s boundaries work, beyond checking that a security feature is in place.

For ingestion, the owner is the engineer building the retrieval and input pipeline, and the evidence is an indirect-injection test against each source that the agent reads. For tools, the owner is the engineer defining the manifest, and the evidence combines a task-specific justification for every tool with demonstrated pre-execution scope enforcement. These are separate acceptance conditions. A pipeline can reject hostile instructions while its tools are still overprivileged, just as a tightly scoped tool can still get manipulated arguments. Neither control should be accepted as proof of the other.

For memory, the engineer who owns the store and write-policy owns tagged writes, provenance tracking, and checks for tampering before memory goes back into model-visible context. For orchestration, the topology architect owns explicit contracts at each trust-tier transition and readable cross-agent audit logs. Release ownership has a different review structure. The release engineer owns hash-verified dependency pinning, source repository identity checks at build time, and human gates for plugin registry changes, with review by the security lead. These five assignments cover the six risk categories without separating tool abuse from the privilege design that enables it.

The Five Eyes joint guidance issued in May 2026 by CISA, NSA, and counterparts in the UK, Canada, Australia, and New Zealand places agentic security within intergovernmental security guidance. It remains advisory. Engineering acceptance still needs its own evidence. Risk discussions should end with a named owner, a verified control, and a reproducible test result rather than an opinion about how likely an attack seems.