How to secure a Mastra agent

How do you secure a Mastra agent?

Screen inbound messages with guardProcessor, wrap the execute function in an authored createTool with guardTool, and deny unwrapped MCP, workspace, and toolset tools with guardHooks.

A Mastra agent has three places where work can start: a message that reaches processInput, an authored createTool with a local execute function, and an MCP or workspace tool that has none. Those are different jobs. Treating them as one processor list is how createPullRequest still runs after you "blocked prompt injection."

protect() is the HTTP check on a route. The Mastra helpers are guardProcessor, guardTool, and guardHooks. mastraAgentContext() uses a thread, resource, or workflow.runId that the app already has. It never creates an ID. For more information about the helpers, see the Mastra agent guard documentation.

How do you screen inbound Mastra messages?

Put guardProcessor on inputProcessors. Mastra channels already call processInput. On DENY, processInput and processInputStep call abort(), and Mastra raises a tripwire. processInputStep screens later agentic steps so that a tool continuation can't skip the inbound gate.

That is a screen on untrusted content. For more information, see Screen inbound with guardProcessor.

1
import { Agent } from "@mastra/core/agent";
2
import { guardProcessor } from "@arcjet/guard/mastra/v1";
3
import { detectPromptInjection } from "@arcjet/guard";
4
import { arcjet } from "./arcjet.js";
5

6
const inbound = guardProcessor(arcjet, {
7
  action: "message.received",
8
  rules: ({ text }) => [detectPromptInjection()(text)],
9
});
10

11
export const agent = new Agent({
12
  id: "support-agent",
13
  name: "support-agent",
14
  instructions: "Help the user.",
15
  model: "openai/gpt-4o",
16
  inputProcessors: [inbound],
17
});

Helpers default to onGuardError: "deny". "allow" is a legitimate choice on the inbound processor, because failing closed there would stop the agent from answering during an outage.

Why isn't requireApproval a security policy?

requireApproval parks the call until a person clicks. That stops the send if the reviewer sees enough context to refuse. It's a human hold, not a remote policy. For more information, see requireApproval is not a policy gate and human approval gates.

A person is a hold after the policy, or instead of one. Rubber-stamping every tool doesn't remove a lethal trifecta leg. The model has already seen the prompt.

How do you gate authored tools vs MCP and workspace tools?

Wrap createTool with guardTool. On DENY, the function never runs. The model gets a structured ArcjetDenialResult ({ arcjetDenied, reason, message, retryable }). It isn't a throw.

MCP, workspace, and toolset tools skip that wrap. Use guardHooks. beforeToolCall can return { proceed: false, output } so that those tools never execute. afterToolCall runs after Mastra has called the host. A log of the comment isn't a deny. Applying both helpers to the same authored tool double-calls the guard.

See Hooks can deny unwrapped tools. For MCP outside Mastra, see How to secure an MCP server or AI agent tool calls.

Are Mastra guardrails enough?

No. A processor reads the message. Mastra's PromptInjectionDetector and PIIDetector classify, redact, or abort text. They don't see the tool name. For more information about that split, see Mastra guardrails vs an action gate.

An action gate is the labeled allow or deny immediately before the side effect. For more information, see runtime security for LLM applications. If detectors are your only control, then createPullRequest has already run.