Defense-in-Depth for Agent Tool Use: Mitigating Indirect Prompt Injection, OAuth Token Escalation, and Plugin Supply-Chain Poisoning

When Untrusted Retrieval Meets Broad Credentials

Consider a plausible engineering scenario: an internal operations or legal team connects an assistant agent to a document-fetching plugin and an internal workspace connector. To avoid repeated authorization prompts, the team configures the agent with a shared OAuth token that holds read-and-write permissions across team folders and messaging channels. When a staff member asks the agent to summarize an external vendor brief or web page, hidden text inside the retrieved file instructs the model to query internal draft notes in the same directory and transmit them through an outbound API call. Without triggering a syntax error or authentication failure, a summarization helper becomes an automated exfiltration path.

This scenario highlights the core security boundary of tool-using agents. Once an agent can read external content, indirect prompt injection becomes a primary operational threat. Because prompt wording alone cannot reliably separate untrusted data from legitimate instructions, defenses must be built in depth: scanning plugin signatures and licenses before installation, enforcing least-privilege identities per agent, and routing high-risk calls through policy gateways and mandatory human confirmation.

Blurred Instruction Boundaries, Memorization Leakage, and the Confused Deputy

Why does combining language models with external tools alter the threat model so sharply? Security research across machine learning and operating systems explains how three mechanisms interact.

First is the collapse of the boundary between data and instructions. Greshake et al. (2023) note that prior work assumed the user was directly prompting the language model; however, applications integrated with large language models blur the line between data and instructions^[1]. By strategically injecting prompts into data likely to be retrieved at inference time, adversaries can use Indirect Prompt Injection to remotely exploit these applications without a direct interface^[1]. Deriving a taxonomy from a computer security perspective, the authors examine impacts including data theft, worming, and information ecosystem contamination, and demonstrate practical viability against real-world systems—such as web-connected chat systems and code-completion engines—and synthetic applications^[1]. They show that processing retrieved prompts can act as arbitrary code execution, manipulate application functionality, and control whether and how other APIs are called, while effective mitigations remain lacking^[1].

Second is the risk of training data extraction from the model itself. Carlini et al. (2021) showed that an adversary can perform a training data extraction attack to recover individual training examples by querying a large language model^[2]. On a publicly available model trained on public internet data, they extracted hundreds of verbatim text sequences from the training data, including personally identifiable information (names, phone numbers, email addresses), code, and identifiers, finding that larger models were more vulnerable than smaller ones^[2]. When injected prompts steer how an agent queries a model and where it sends the output, extraction risks and tool channels reinforce each other.

Third is a classic operating systems vulnerability. Hardy (1988) described a compiler service given authority to write to a billing file; when a user asked the compiler to write its output to the billing file’s name, the compiler acted with its own authority on the user’s behalf and overwrote it^[3]. Hardy called the program a “confused deputy” because it held two authorities and could not tell which one it was exercising for whom^[3]. He argued that capabilities—which bundle the designation of an object with the authority to use it—avoid this problem^[3]. An agent holding broad OAuth tokens or desktop control while acting on instructions parsed from untrusted documents is a modern confused deputy.

Engineering Defense-in-Depth: Provenance Checks, Policy Gateways, and Human Gates

Countering these compounded threats requires moving controls out of natural-language prompts and into deterministic runtime gates. Within the Agent OS and AI Gateway modules on rlab.works, this architecture is expressed through four skill packs and scoped runtime components.

The first layer governs tool supply-chain intake. In Install and manage tools (S04), the input contract specifies the tool packages and requested access scopes. The workflow checks packages and licenses—backed by Signed plugin registry and trusted installation—to verify signatures and produce a signature and license checklist. Execution then pauses at a human review gate (Approve account scopes), where a designated reviewer or requesting user approves the connection and scope; rejected outputs return for revision and do not advance. After installation and registration, a second human gate (Check calls and rollback) verifies invocation behavior and records a rollback plan.

The second layer enforces least-privilege identity and policy routing. Under AI Gateway, Set access rules (S14) takes team roles, the service catalog, and access requirements to draft role and request rules. After a human reviewer validates diffs and approves the rule version, the policy-controlled MCP gateway and Scoped agent identity and authorization bind operations to accounts, enforce tool permission scopes, and apply endpoint and namespace policies before a final human review inspects request evidence.

The third layer gates high-risk local actions and releases. When an agent interacts with desktop interfaces or files, Approve computer actions (S03) requires the action goal, account, and permitted materials upfront. It checks readiness to create a restricted context, pauses for human approval of the action list, executes while retaining screenshots, file diffs, and receipts, and finishes with a human check of all changes. For software updates, “Release and restore apps” (S05) pairs release manifests and isolated recovery readiness checks with human approval of release conditions, staged rollout, and human acceptance or rollback decisions.

Across the industries associated with this article—business and general services, legal services, and energy—none of these four skill packs carries a source-supported industry tag; they apply only as transferable uses or general patterns: - In **business and general services**, "Install and manage tools" (S04) is a transferable use for checking provenance, licenses, and account scopes before onboarding tools, requiring adapters matched to package formats and clients plus preserved revocation paths. S03, S05, and S14 have no tag here and serve only as general patterns. - In **legal services**, "Approve computer actions" (S03) is a transferable use—such as having a legal assistant list case-file organization actions for authorization before executing and checking diffs—requiring per-directory read and write restrictions, with external submissions excluded from default permissions. The other three packs carry no legal tag. - In **energy**, "Release and restore apps" (S05) is a transferable use for packaging installation files, signatures, and recovery evidence for site auxiliary software and updating in stages after manager confirmation. It covers auxiliary software delivery only, never power plant equipment control, and requires adaptation for offline environments, trusted signatures, and site change workflows. Meanwhile, S14 is tagged as a transferable use only in public services, where it must connect to organizational identity and real document permissions rather than prompts.

In addition, every skill pack on the site is a proposed composition demonstrated with synthetic data and not yet connected to live services; component maturity reflects static source inspection rather than production deployment.

Pre-Pilot Checks for Engineering and Risk Leaders

Before funding an agent pilot that combines external content reading with tool execution, leaders can apply three concrete checks:

• Are credentials bound to specific objects and narrow scopes? Verify that agents do not share broad service accounts or long-lived tokens; each call should bundle target designation with scoped authorization so the runtime cannot exercise broad privileges on behalf of untrusted text.
• Do policy gateways and human gates separate untrusted reading from state changes? Once a session ingests external web pages, emails, or documents, any subsequent file modification, outbound request, or interface action must pause for deterministic policy validation and human approval, with rejected actions blocked from advancing.
• Can every plugin installation and release be audited and rolled back? Confirm that third-party packages undergo signature and license verification before registration, and that recovery evidence and rollback procedures are verified before updates reach users.