vault_call_api
ZERO-EXPOSURE authenticated HTTP call: store an API key/credential in your vault, then call any API and let the gateway inject the secret server-side — it NEVER enters your context. You send method/url/auth (and optional headers/body); the gateway decrypts, injects, calls through its SSRF-guarded...
This record as markdown: /tools/com-wingmanprotocol-agent-gateway/vault-call-api.md
What vault_call_api does on Gateway
AI agents invoke vault_call_api to trigger actions in Gateway. What it does depends on the arguments the agent supplies, and its effects often reach beyond the immediate call: builds kicked off, notifications sent, workflows started.
| Parameter | Type | Required | Description |
|---|---|---|---|
url | string | Yes | target URL (https recommended) |
auth | object | Yes | {type:'bearer'|'header'|'basic'|'query', ref:'entry[:field]', name?} |
body | object | — | optional JSON body (POST/PUT/PATCH) |
handle | string | Yes | your registered handle |
method | string | Yes | HTTP method |
headers | object | — | optional NON-secret request headers (Authorization is forbidden here — use auth) |
Parameters from the server's own tool schema.
Why vault_call_api is rated High
This tool executes arbitrary authenticated HTTP requests to any URL on behalf of the agent, injecting stored credentials server-side. The blast radius is critical: an AI agent could use it to call any external API (including destructive, financial, or sensitive endpoints) with stored credentials, effectively acting as a privileged HTTP proxy with full credential injection.
From the tool's definition authenticated HTTP call... call any API and let the gateway inject the secret server-side... gateway decrypts, injects, calls through its SSRF-guarded fetch, and returns only the response
Risk signalsAccepts URL/endpoint input (url) · Handles credentials or secrets (auth) · Accepts raw HTML/template content (body)
Attacks that exploit this kind of access
The rule that runs vault_call_api safely
PolicyLayer is an MCP gateway: it sits between your AI agents and Gateway, and checks every tool call against a rule you set before the call runs. Nothing changes on the server itself. For vault_call_api, this is the rule to start with:
vault_call_api stays usable, but rate-capped: a runaway agent can't fire it dozens of times a minute. Everything else on the server is denied unless you say otherwise.
The button opens the PolicyLayer dashboard: create your workspace, connect Gateway, apply this rule, and every vault_call_api call is checked against it from then on.
Questions about vault_call_api
ZERO-EXPOSURE authenticated HTTP call: store an API key/credential in your vault, then call any API and let the gateway inject the secret server-side — it NEVER enters your context. You send method/url/auth (and optional headers/body); the gateway decrypts, injects, calls through its SSRF-guarded fetch, and returns only the response. auth = {type, ref, name?}: type 'bearer' -> Authorization: Bearer; 'header' (+name) -> a named header; 'basic' -> Authorization: Basic of an entry's username+password; 'query' (+name) -> a URL query param. ref names a vault entry ('entry' or 'entry:field', e.g. 'openai_key:key'). Do NOT pass Authorization yourself. CAVEAT: zero-exposure covers OUR outbound path — a hostile API can still echo your credential in its own response body. A redirected POST is followed as GET with the body dropped, and credentials are stripped on a cross-origin redirect. Requires your secret (Bearer). It is categorised as a Execute tool in the Gateway MCP Server, which means it can trigger actions or run processes. Use rate limits and argument validation.
vault_call_api accepts 6 parameters: url, auth, body, handle, method, headers. Required: url, auth, handle, method. The full parameter table on this page comes from the server's own tool schema.
Register the Gateway MCP server in PolicyLayer and add a rule for vault_call_api: allow, deny, rate-limit, or require approval. Point your MCP client at the PolicyLayer proxy URL and the rule is enforced on every call, before it reaches Gateway. Nothing to install.
vault_call_api is a Execute tool with high risk. Execute tools should be rate-limited and have argument validation enabled.
Yes. Add a rate_limit block to the vault_call_api rule in your PolicyLayer policy. For example, setting max: 10 and window: 60 limits the tool to 10 calls per minute. Rate limits are tracked per agent session and reset automatically.
Set action: deny in the PolicyLayer policy for vault_call_api. The AI agent will receive a policy violation error and cannot call the tool. You can also include a reason field to explain why the tool is blocked.
vault_call_api is provided by the Gateway MCP server (https://wingmanprotocol.com/mcp). PolicyLayer sits as a proxy in front of this server to enforce policies before tool calls reach the server.
More on Gateway, and thousands of servers like it.
Across the catalogue