Vercel rolled out version 7 of its AI SDK with a scoped tool context feature that forces each tool in an AI agent to receive only the secrets it explicitly declares. By limiting exposure, developers can stop third-party tools from accidentally seeing every credential stored in their environment.

Why the change matters

AI agents often stitch together multiple external services—order lookups, ticket creation, payment processing—each requiring its own API keys or URLs. The common shortcut is to hand the whole process.env object to every tool:

execute(input, { context: process.env })

That pattern creates an implicit privilege expansion: adding a new tool instantly grants it access to all existing secrets, including database passwords or payment tokens, without any code review flag. The risk is a compromised or buggy tool suddenly leaking credentials that were never meant for it.

How scoped tool context works

In SDK 7 a tool declares a context schema—a Zod-based definition of the exact fields it needs. When the agent invokes a tool, the caller supplies a toolsContext object that contains only those declared fields. The SDK validates the shape before execution, and any missing or extra keys cause an error.

A minimal demo shows two tools with disjoint requirements:

  • lookupOrder – needs baseUrl to call an internal order service.
  • createTicket – needs supportToken to open a support ticket.

Each tool exports a contextSchema that lists its single required key. When the agent runs, it passes:

{
  lookupOrder: { baseUrl: "https://orders.internal" },
  createTicket: { supportToken: "s3cr3t-token" }
}

Only lookupOrder sees baseUrl; createTicket never touches it, and vice-versa. The SDK enforces this boundary at runtime, turning a hidden dependency into an explicit capability list that reviewers can audit.

Security upside

  • Limits data exposure – credentials stay where they’re needed.
  • Validates context – mismatched or missing fields abort execution.
  • Makes capabilities explicit – reviewers can see exactly what each tool can access.
  • Reduces blast radius – if a tool is compromised, the attacker only gains the secrets that tool was allowed.

The feature does not replace traditional sandboxing. Developers must still employ log redaction, network egress controls, and regular token rotation. Scoped context is a boundary; it doesn’t seal the room.

What developers need to adjust

  1. Define a schema for every tool – use the Zod library that ships with the SDK.
  2. Pass a narrow toolsContext – avoid the catch-all process.env.
  3. Review existing agents – identify any secrets that can be removed from tool calls.
  4. Add automated tests – ensure context validation fails when extra data is injected.

A quick start looks like this:

mkdir scoped-tools && cd scoped-tools
npm init -y
npm install ai zod
npm install -D typescript tsx @types/node

Create demo.ts, declare each tool’s contextSchema, and run it with tsx demo.ts. The SDK will throw if you try to give a tool a secret it didn’t ask for.

Counter-point

Some teams may argue that the extra schema definitions add boilerplate and slow prototyping. While true, the cost is modest—just a few lines per tool—and the security payoff grows with the number of integrated services. In environments handling payment data or personal information, the trade-off is hard to ignore.

What to watch next

  • Adoption metrics – early adopters are reporting fewer secret-leak incidents.
  • Community tooling – plug-ins that auto-generate context schemas from configuration files.
  • Future SDK releases – hints that Vercel may extend scoped contexts to include network permissions and rate-limit caps.

If you’re already building AI agents with Vercel’s SDK, the first step is to audit your current process.env usage. Identify the single value that can be stripped from all tool calls and replace the catch-all pattern with a scoped toolsContext. The result is a tighter security posture without sacrificing the flexibility that makes AI agents powerful.