DEV Community: Josh van Leeuwen

How Do I Stop Prompt Injection From Reaching My Tools?

Josh van Leeuwen — Thu, 22 Oct 2026 11:48:58 +0000

You can't stop untrusted text from reaching a model. If your agent reads public GitHub issues, anyone can put instructions into the text it reads. The model might follow them, even when you've told it not to.

What you can control is what happens afterwards. Which tools the agent can call, what arguments they accept, and whether the model gets to make the decision to execute them at all.

Take an agent that reads GitHub issues and applies labels. It needs to understand the issue, decide on a label and update GitHub. It doesn't need permission to close issues, merge pull requests or read repository secrets.

Here's how I'd build this with Dapr.

Put the agent inside a workflow

I'd use a Dapr Workflow to manage the issue triage process, rather than letting the model decide which actions to take.

The workflow receives a verified GitHub webhook, passes the issue text to an agent and gets back a suggested label. It then checks that label before calling GitHub.

The important part is what the agent doesn't control. It doesn't choose the repository, issue number or which GitHub operation to run. Those come from the workflow and the original verified event.

The model is deciding how to classify the issue, not what it's allowed to do with GitHub.

Treat MCP tools as workflows too

Dapr has an MCPServer resource which lets you declare a connection to an MCP server. When Dapr loads it, it discovers the available tools and registers a durable workflow for each one.

So if our GitHub MCP server exposes add_label and close_issue, Dapr registers workflows named:

dapr.internal.mcp.github.CallTool.add_label
dapr.internal.mcp.github.CallTool.close_issue

The agent doesn't need to manage the MCP connection itself. The application can invoke those workflows, and Dapr handles the MCP call.

For example, the resource on our github-tools application could look like this:

apiVersion: dapr.io/v1alpha1
kind: MCPServer
metadata:
  name: github
spec:
  endpoint:
    streamableHTTP:
      url: https://github-mcp.internal/mcp
scopes:
  - github-tools

The URL and tool names here are examples; you'd use those exposed by your own MCP server.

Now we need to decide which applications can invoke those tool workflows.

Enforce permissions outside the model

A list of permitted tools in a system prompt isn't a security control. The model can be convinced to ignore it.

With Dapr, you can use a WorkflowAccessPolicy to control which App IDs are allowed to schedule particular workflows on another application.

For our example:

apiVersion: dapr.io/v1alpha1
kind: WorkflowAccessPolicy
metadata:
  name: github-tools-policy
  namespace: default
scopes:
  - github-tools
spec:
  rules:
    - callers:
        - appID: triage-workflow
      workflows:
        - name: dapr.internal.mcp.github.CallTool.add_label
          operations: [schedule]

This allows triage-workflow to invoke add_label on github-tools. It doesn't grant access to close_issue, or any of the other tools the MCP server might expose.

The workflow access policy is enforced by Dapr, using the calling application's verified identity. The model doesn't get to override it.

There are two details worth knowing here. You need a policy loaded for deny-by-default behaviour, and the MCP server workflows need to run under a separate App ID. Dapr always allows an application to schedule its own workflows, so you shouldn't rely on this policy to isolate tools running under the same App ID as the caller.

Check the arguments before calling GitHub

Being allowed to call add_label doesn't mean every argument should be accepted.

A poisoned issue could convince the model to suggest a label like security-approved, or try to make it update a different issue.

I'd have the agent return a label, then check it in the workflow before calling GitHub. Something like this, using the Dapr Python Workflow SDK:

import dapr.ext.workflow as wf

wfr = wf.WorkflowRuntime()

ALLOWED_LABELS = {
    "bug", "feature", "docs",
    "question", "needs-triage"
}

@wfr.workflow(name="triage_issue")
def triage_issue(ctx: wf.DaprWorkflowContext, issue: dict):
    # classify_issue is a registered activity that calls the model
    suggestion = yield ctx.call_activity(
        "classify_issue",
        input=issue["body"]
    )

    label = suggestion["label"]

    if label not in ALLOWED_LABELS:
        return {"status": "rejected"}

    return (yield ctx.call_child_workflow(
        workflow="dapr.internal.mcp.github.CallTool.add_label",
        app_id="github-tools",
        input={
            "arguments": {
                "owner": issue["owner"],
                "repo": issue["repo"],
                "issue_number": issue["number"],
                "label": label
            }
        }
    ))

This is the core of the workflow, with the activity implementation and runtime startup left out. The tool arguments will depend on your MCP server.

Notice that the model only supplies the label. The repository and issue number come from the verified webhook that started the workflow.

I'd also validate arguments where the tool runs. Dapr's MCPServer resource supports beforeCallTool hooks, which are themselves workflows. You can use one to reject labels outside the allow-list before the call reaches the MCP server.

That way the check isn't only happening in the application that called the tool.

Use a separate workflow for anything destructive

Adding a label is one thing. Closing an issue, deleting something or deploying a release is another.

For those operations, I'd use a separate workflow that waits for human approval.

Dapr Workflows can wait for an external event, so the workflow can request approval, stop executing and resume when an authorised user responds. There's no need to keep a process running while someone makes the decision.

The approval needs to be verified by your application, not accepted as something the model says it received.

You can then give the review workflow its own App ID and grant it access to close_issue, without giving that permission to the triage workflow.

The same applies to any other tool where a bad decision is difficult to undo.

What this doesn't fix

None of this stops prompt injection from influencing the model. A malicious GitHub issue might still persuade it to suggest the wrong label.

But the model doesn't have permission to close the issue, the workflow won't accept a label outside the allowed set, and the repository and issue number aren't under the model's control.

That's a much smaller problem than giving an agent access to every tool on the MCP server and relying on a system prompt to keep it in line.

You still need to think about prompt injection. You just shouldn't be relying on the model to enforce the limits of what it's allowed to do.

Dapr documentation:

Agents Are For-Loops. That Is Good News for Security.

Josh van Leeuwen — Tue, 13 Oct 2026 09:42:17 +0000

If agents were magic, we couldn’t secure them. They aren’t, so we can.

AI agents are not magic. They are workflows with probabilistic decision-making and real-world privileges. Strip away the framing and you find the classical operator feedback loop you already know from Kubernetes controllers and embedded thermostats: observe, decide, act, repeat. The only new element is that the deciding step is a language model.

This is good news, because it means twenty years of distributed-systems security applies almost unchanged. The model is the part you cannot trust; everything around it is the part you already know how to lock down.

LLMs don’t act. Tools do.

A model emits instructions. It’s the tools in the acting step that translate the model’s intent into real-world behaviour- the database write, the refund, the deployment. Which means the security boundary is not the prompt and never was. It’s the tool layer, and tool access is an authorisation problem we have mature answers for: each agent gets its own verifiable identity, each identity gets explicitly scoped grants, and everything ungrated is denied by default.

Note what this replaces. The common pattern today is one shared API key in an environment variable, used by every agent, with the real policy written in the system prompt as a polite request. A permission that exists only as an instruction to a model is not a permission. And a gateway in front of the tools helps less than it appears: a gateway secures a path, it cannot secure a workload it does not run. If the agent can reach the backing service directly, the gateway is decoration.

What a secured for-loop looks like

Identity issued per agent, short-lived and cryptographically verifiable (SPIFFE gives you the standard). Authorisation scoped per tool, per agent, enforced in the runtime. Deny-all as the starting posture, grants as deliberate exceptions. And a signed execution history, so “what did the agent do” has an answer that survives an audit rather than a log file that anyone could have edited.

There is still a weakness in this system: prompt injection against a tool the agent is legitimately granted. If the agent is allowed to send email and a poisoned document convinces the model to send the wrong one, identity and authorisation did their job and the damage still happened. No infrastructure makes a model trustworthy. What infrastructure can do is keep the set of things a misbehaving model can reach small- which turns a catastrophe into an incident.

The deeper treatments: Agent Identity: The Foundational Layer AI Is Still Missing and Why MCP Gateways Are Not Enough.

SPIFFE in Ten Minutes, for People Securing Agents

Josh van Leeuwen — Sun, 11 Oct 2026 14:01:59 +0000

Every serious answer to "how should agents authenticate?" eventually lands on SPIFFE, so here is the working minimum.

SPIFFE gives every workload a verifiable identity document (an SVID) tied to a URI like spiffe://trust-domain/ns/prod/agent/invoice-reviewer. The document is short-lived, automatically rotated, and cryptographically verifiable against the trust domain's bundle. No secret to leak, no key to rotate by hand, no shared credential to make agents indistinguishable from each other.

Three properties matter for agents specifically. First, identity per workload, not per team or per environment; so "which agent did this" has an answer. Second, mutual verification: the tool verifies the agent and the agent verifies the tool, which kills a whole class of spoofing. Third, federation Identities issued in your cluster can be trusted by AWS or Azure without copying secrets across the boundary.

What SPIFFE does not give you: authorisation. An SVID says who is calling; it says nothing about what they may do. Policy is a separate layer, and identity without authorisation is meaningless. Authorisation without identity is impossible, which is why this comes first.

I spent seven years on cert-manager watching teams hand-roll worse versions of this with long-lived certificates and spreadsheet rotation schedules. The standard exists, so use it.

How Dapr builds universal application identity on SPIFFE, including the cloud federation: https://www.diagrid.io/blog/universal-application-identity-with-dapr