How do I add guardrails to an AI agent that calls external APIs?

How do I add guardrails to an AI agent that calls external APIs?

Put the check on the outbound HTTP call, inside the tool that makes it. When an agent charges a card, opens a GitHub issue, hits a search API, or sends mail, the control has to run before that request leaves your process, and again on the response before the text re-enters the model.

How to enforce runtime controls on AI agents accessing external APIs

Enforce on that outbound call. Authorize the user and the target object, rate-limit the identity, screen generated arguments, then screen the response.

That job is different from runtime controls on enterprise systems. That page is CRM, warehouse, and internal API access. This page is Stripe, GitHub, search, and send-email: third-party HTTP the agent starts.

A scoped API key answers whether the agent can reach Stripe. It doesn't answer whether this charge, for this user, with these arguments, is allowed on this request. The OWASP Top 10 for LLM Applications treats that gap as excessive agency, and as indirect prompt injection when tool output steers the next call.

This isn't the CRM or warehouse path

Internal systems and outbound APIs fail in different places. The following table compares the two paths:

If the tool reads Salesforce or BigQuery, use the enterprise systems guide. If it calls an external HTTP API, stay here.

What to enforce on an outbound call

Put these checks on the call. Authorization is a separate function on the user and the target object, not a content score. The following table lists each control:

A clean injection score isn't permission to charge. A clean personally identifiable information (PII) score isn't permission to email a new address. Write the allow as an ordinary function on the authenticated user, the target object, and the arguments. For more information about that control model, see AI agent runtime security. For more information about splitting injection, exfiltration, and unsafe actions, see runtime security for LLM applications.

The check sits in the execute function or in the HTTP client

You can't wrap "the agent" from the outside and catch Stripe. Most hosts pass generated arguments straight into the execute function. The vendor call happens in that function, or in a helper that it calls. If the check isn't on that path, then the request goes out.

If you wrote the tool, put the check at the top of execute (or the Python invoke / _run body), then again on the response. If many tools share one HTTP client, wrap that client once. Every outbound call has to go through it. A tool that imports fetch directly bypasses the wrapper.

Framework callbacks that only log after the tool returns aren't a gate. For more information about that trap on another host, see canUseTool is not a policy gate. MCP tools that you didn't write have no local execute function. Gate them on the host hook that can still deny. For more information about that placement, see secure MCP server and agent tool calls.

Most hosts don't give you a wrapper between generated arguments and the function. If yours doesn't, you have to touch execute.

A generic fetch wrapper

Authorize, limit, screen arguments, call the API, then screen the body. Every outbound tool must call this function (or an equivalent client) instead of raw fetch.

1
type AgentHttpContext = {
2
  actor: string;
3
  action: string;
4
  customerId?: string;
5
};
6

7
// Narrower than RequestInit on purpose: a Headers instance doesn't survive
8
// object spread, and a URLSearchParams body doesn't survive JSON.stringify.
9
type AgentInit = {
10
  method?: string;
11
  headers?: Record<string, string>;
12
  body?: string | URLSearchParams;
13
};
14

15
const buckets = new Map<string, { tokens: number; resetAt: number }>();
16

17
function takeToken(key: string, max: number, windowMs: number): boolean {
18
  const now = Date.now();
19
  const current = buckets.get(key);
20
  if (!current || now >= current.resetAt) {
21
    buckets.set(key, { tokens: max - 1, resetAt: now + windowMs });
22
    return true;
23
  }
24
  if (current.tokens <= 0) {
25
    return false;
26
  }
27
  current.tokens -= 1;
28
  return true;
29
}
30

31
export async function agentFetch(
32
  url: URL,
33
  init: AgentInit,
34
  ctx: AgentHttpContext,
35
  authorize: (ctx: AgentHttpContext, url: URL) => void,
36
  isHostile: (text: string) => Promise<boolean>,
37
): Promise<string> {
38
  authorize(ctx, url);
39

40
  if (!takeToken(`${ctx.actor}:${ctx.action}`, 30, 60_000)) {
41
    throw new Error("Outbound rate limit exceeded");
42
  }
43

44
  const allowedHosts = new Set(["api.stripe.com", "api.github.com"]);
45
  if (!allowedHosts.has(url.host)) {
46
    throw new Error("Outbound host is not allowed");
47
  }
48

49
  // String(body) covers URLSearchParams; JSON.stringify would return "{}" and
50
  // screen nothing.
51
  const outbound = init.body === undefined ? "" : String(init.body);
52
  if (await isHostile(`${url.href}\n${outbound}`)) {
53
    throw new Error("Blocked untrusted tool arguments");
54
  }
55

56
  const response = await fetch(url, {
57
    method: init.method ?? "GET",
58
    body: init.body,
59
    headers: {
60
      ...init.headers,
61
      authorization: secretForHost(url.host),
62
    },
63
  });
64
  const text = await response.text();
65

66
  if (await isHostile(text)) {
67
    throw new Error("Blocked untrusted tool output");
68
  }
69

70
  return text;
71
}
72

73
function secretForHost(host: string): string {
74
  if (host === "api.stripe.com") {
75
    return `Bearer ${process.env.STRIPE_SECRET_KEY!}`;
76
  }
77
  if (host === "api.github.com") {
78
    return `Bearer ${process.env.GITHUB_TOKEN!}`;
79
  }
80
  throw new Error("No credential for host");
81
}
82

83
function authorizeCharge(
84
  ctx: AgentHttpContext,
85
  args: { customerId: string; amountCents: number },
86
) {
87
  if (args.customerId !== ctx.customerId) {
88
    throw new Error("Customer mismatch");
89
  }
90
  if (args.amountCents > 5_000) {
91
    throw new Error("Amount exceeds policy");
92
  }
93
}
94

95
const ctx: AgentHttpContext = {
96
  actor: session.userId,
97
  action: "stripe.charge",
98
  customerId: session.customerId,
99
};
100
const args = {
101
  customerId: generated.customerId,
102
  amountCents: generated.amountCents,
103
};
104

105
const charge = await agentFetch(
106
  new URL("https://api.stripe.com/v1/charges"),
107
  {
108
    method: "POST",
109
    body: new URLSearchParams({
110
      amount: String(args.amountCents),
111
      customer: args.customerId,
112
    }),
113
  },
114
  ctx,
115
  () => authorizeCharge(ctx, args),
116
  detectInjection,
117
);

Hold vendor secrets in the wrapper, never in tool arguments. The model doesn't get to pick the Authorization header. Pass your own detector as the last argument; the wrapper only needs a boolean. An allowlist on host is an abuse signal: a search tool that suddenly posts to an unknown origin is the call you stop.

The in-memory bucket is a sketch. In production, share the counter across instances the same way you would any other rate limit; the rate limiting guide covers algorithms and identifiers. Key on the authenticated user (or session), not on a value the model supplies. A limit on the chat route counts workflow starts. One request can still fire 40 Stripe calls.

One worked example on a GitHub tool

The same checks, using a published Guard client as the decision helper. The check still sits inside the tool, immediately before the GitHub client. You aren't wrapping the agent loop. guard() is the API for tools, MCP, and jobs. It takes no Request. Bots stay on protect().

1
import {
2
  detectPromptInjection,
3
  launchArcjet,
4
  tokenBucket,
5
} from "@arcjet/guard";
6

7
const arcjet = launchArcjet({ key: process.env.ARCJET_KEY! });
8
const outbound = tokenBucket({
9
  bucket: "github-create-issue",
10
  refillRate: 30,
11
  intervalSeconds: 60,
12
  maxTokens: 60,
13
});
14
const injection = detectPromptInjection();
15

16
export async function createGitHubIssue(args: { title: string; body: string }) {
17
  if (!session.canOpenSupportIssues) {
18
    throw new Error("Not allowed to open issues");
19
  }
20

21
  const before = await arcjet.guard({
22
    label: "tools.github-create-issue",
23
    actor: session.userId,
24
    correlationId: workflowRunId,
25
    rules: [
26
      outbound({ key: session.userId, requested: 1 }),
27
      injection(`${args.title}\n${args.body}`),
28
    ],
29
  });
30

31
  if (before.conclusion === "DENY" || before.hasFailedOpen()) {
32
    throw new Error(`Denied: ${before.reason}`);
33
  }
34

35
  const issue = await github.rest.issues.create({
36
    owner: "acme",
37
    repo: "support",
38
    title: args.title,
39
    body: args.body,
40
  });
41

42
  const after = await arcjet.guard({
43
    label: "tools.github-create-issue",
44
    actor: session.userId,
45
    correlationId: workflowRunId,
46
    rules: [injection(JSON.stringify(issue.data))],
47
  });
48

49
  if (after.conclusion === "DENY" || after.hasFailedOpen()) {
50
    throw new Error(`Denied: ${after.reason}`);
51
  }
52

53
  return { url: issue.data.html_url };
54
}

actor comes from the authenticated session, never from a tool argument. A policy can be conditioned on the actor, so a model-supplied value lets the caller escape their own scope. label is validated server-side as a slug: lowercase letters, digits, dash, and dot. tools.github_create_issue is rejected; tools.github-create-issue is not.

The key you pass to a rate-limit rule is SHA-256 hashed before it leaves the process, so a raw user ID never reaches Arcjet. Pass anything you need for later correlation as metadata instead. Name the bucket per use case: counters are keyed by bucket plus a server-side hash of the rule config, so two unrelated tools that both default to default-token-bucket still get separate counters, but a shared name is what makes the dashboard readable.

correlationId tags the run so you can reconstruct it later. It doesn't deny step 3 because of steps 1 and 2. Sequence-aware deny isn't something you can buy here.

A direct guard() call returns ALLOW when evaluation can't be completed: a deadline, a parse failure, a local rule error, or a rule error the server returned. The conclusion alone can't tell you that apart from a real allow, which is what hasFailedOpen() is for. Framework wrappers invert that default and deny unless you opt in. Choose per action: a search timeout can return a placeholder; a Stripe charge must not run. For more information about those APIs, see Agent guards and AI runtime protection.

For more information about prompt-injection wiring on LangChain, LlamaIndex, and the Vercel AI SDK, see prompt injection protection for those frameworks. That page owns the inbound and retriever screens. This document owns the outbound HTTP call.

Checklist

Before you ship an outbound tool, check the following items:

• Route every outbound vendor call through one client or through the tool execute function that you ship.
• Authorize the action against session identity and the target object before the client runs.
• Rate-limit on the user or session at the tool. A limit on the chat route counts workflow starts.
• Put destination hosts on an allowlist. Treat an unknown origin as an abuse signal.
• Screen model-generated arguments before the request. Screen the response before it becomes the next prompt.
• Hold API keys in server code. Don't let the model supply the bearer token.
• Decide per action what happens if the check can't finish.
• Tag the run so that an incident is reconstructable. Don't wait for sequence-aware deny.

If the call can't be undone, classify it before you write the allowlist. For more information about that list, see How do I prevent an AI agent from taking irreversible actions?.