How to stop AI agents from taking unsafe or unauthorized actions

How do I stop AI agents from taking unsafe or unauthorized actions?

Classify every tool an agent can call by what it does: reading data, destroying or changing something that is hard to undo, or sending something outside your system. Then intercept each call at runtime, in the code that executes the tool, and refuse it unless the authenticated user, the target resource, and the arguments pass the rules for that class. Refusing by default is what stops an unsafe action. Asking the model to behave doesn't.

Arcjet is one way to run that interception. An Arcjet Guard call in the tool path sends typed facts about the call, such as its class, the user's role, and the destination host, to a policy that returns allow or deny before the side effect runs. A security team can change the policy without an application deploy, and every decision is recorded with its reason.

The rest of this guide covers the three classes, where to intercept, and a worked policy that you can adapt.

Classify unsafe actions into three kinds

Most unsafe agent actions fall into one of three classes. Each has a different failure mode, so each needs a different check.

Keep the classification on the server, in a table the model can't change. A tool that isn't in the table is denied. An "unknown" class is a bug to fix, not a default to allow.

Some tools span classes. An export that reads a thousand records and emails them is both data access and an external call, so apply both sets of checks. The lethal trifecta describes why that combination is the one to design against.

How do I stop AI agents from accessing data they shouldn't?

Resolve every resource from the authenticated session, not from the model's arguments. If the handler looks up invoiceId scoped to the session's tenant, then another tenant's invoice doesn't exist from the agent's point of view, whatever ID the model supplies.

Then bound the reach. Cap the number of records a single call can return, return only the fields the user may see, and deny bulk reads the task doesn't need. Scoped credentials limit what the agent could reach in the worst case. A runtime check limits what it does with that reach on this call. For both halves in detail, see stopping AI agents accessing data they shouldn't.

Hold destructive operations to a stricter bar

A destructive operation needs a stronger reason to allow than a read. Check the user's role for this operation, bound amounts with server-side values, and require an approval that is bound to the exact resource and arguments. If the model changes the amount after approval, evaluate the new action again.

Make the operation idempotent with an operation ID, so a retry doesn't delete or refund twice. For the full pattern, including why a human click is a hold rather than a policy, see preventing irreversible AI agent actions.

Restrict where external calls can go

An external call is how data leaves and how an agent reaches a host an attacker controls. Allowlist destination hosts in a policy the agent can't edit, bind recipients to the verified case or account, and screen outbound content for sensitive data. See egress allowlists for AI agents and detecting malicious URLs.

Intercept at runtime, at the point the tool executes

Put the check in the code that performs the action, immediately before the side effect. That's the only point every path shares: the model's direct call, a retry, a background worker, and an alternate tool that reaches the same service.

Checks elsewhere leave gaps. A system prompt can be overridden by injected text. A tool-name allowlist in the client doesn't check arguments. A gateway sees only the calls routed through it. Keep those layers, but don't count them as the enforcement point. For a comparison of the layers, see least privilege for AI agent tool calls.

When the check can't complete, refuse the destructive and external classes. A timeout in the policy service mustn't become permission to delete.

Example: a policy for each class of action

Give each tool its own guard call with a hard-coded label, and send typed facts about the call that the policy for that label can read. The following destructive tool resolves the project within the user's tenant, then asks Arcjet whether this user may delete it:

1
import { launchArcjet, policyInput } from "@arcjet/guard";
2

3
const arcjet = launchArcjet({ key: process.env.ARCJET_KEY! });
4

5
export async function deleteProject(
6
  args: { projectId: string },
7
  session: { userId: string; tenantId: string; role: string },
8
) {
9
  // Tenant-scoped lookup: another tenant's project doesn't exist here.
10
  const project = await projects.find({
11
    id: args.projectId,
12
    tenantId: session.tenantId,
13
  });
14
  if (!project) return { error: "Not permitted" };
15

16
  const approval = await approvals.find({
17
    resourceId: project.id,
18
    operation: "delete",
19
  });
20

21
  const decision = await arcjet.guard({
22
    label: "tools.delete-project",
23
    actor: session.userId,
24
    inputs: {
25
      role: policyInput.server.string(session.role),
26
      environment: policyInput.server.string(project.environment),
27
      approved: policyInput.server.boolean(approval?.status === "approved"),
28
    },
29
  });
30

31
  if (decision.conclusion === "DENY" || decision.hasFailedOpen()) {
32
    return { error: "Delete denied by policy" };
33
  }
34

35
  return projects.delete(project.id);
36
}

A Guard policy for the tools.delete-project label then states the rules. It reads only the values the application sent:

1
package arcjet.guard
2

3
import rego.v1
4

5
deny contains "requires-admin" if {
6
  input.values.role != "admin"
7
}
8

9
deny contains "production-requires-approval" if {
10
  input.values.environment == "production"
11
  not input.values.approved
12
}

The other two classes follow the same shape, each on its own label. A tools.get-customer policy bounds a data-access tool by the number of records it would return, and a tools.send-webhook policy restricts an external call to reviewed hosts:

1
deny contains "bulk-read" if {
2
  input.values.record_count > 100
3
}
4

5
deny contains "unlisted-destination" if {
6
  not input.values.destination_host in {"api.stripe.com", "hooks.slack.com"}
7
}

Three properties make this safe to run. Every input comes from server state, so the model can't claim to be an admin, approve its own request, or supply its own allowlist. The tenant check stays in code, where the data is. A policy starts in dry run, so you can review what it would have denied against real traffic before it blocks, and a live rule needs a stored test before it can publish. For the authoring workflow, see Guard remote policies.

Add rules to the same call for checks that aren't expressions over inputs, such as a per-user rate limit on destructive actions or prompt-injection detection on a free-text argument.

Test that unsafe actions are refused

For each class, start from an allowed call, then change one fact at a time: a non-admin role, a production project with no approval, 101 records, an unlisted host, and another tenant's resource ID. Assert that the decision is a deny and that the downstream call count is zero. Run the same cases through retries and background workers that reach the same services.

Include the adversarial case. Put an instruction in a tool result or a retrieved document that asks for a destructive action, and confirm that the policy refuses it even though the model proposed it. See AI agent security testing for building the full matrix.

AI agent governance guides

This guide is one of five on governing what an AI agent may do at runtime:

• How to enforce least privilege for AI agent tool calls: limit each agent to the tools, resources, and arguments its task needs, and enforce it in the handler.
• How to audit and log AI agent activity for compliance: record who, what, and when for every tool call, with sensitive fields redacted.
• How to secure an MCP server or AI agent tool calls: enforce inside the handler, where no HTTP request exists to inspect.
• How to prevent data exfiltration and sensitive data leakage from AI agents: detect protected data at the boundaries where it moves.

Learn more: Arcjet Guards · Guard remote policies