Generate a time-bound, revocable token that lets someone else read a specific subset of the user's wallets via their own VaultPilot instance. The classic use case: hand the token to a financial advisor or experienced friend so they can look at the user's DeFi positions without being given signing...
AI agents use generate_readonly_link to create or update resources in VaultPilot MCP — usually the action step of a workflow, after the agent has gathered context. Every call changes real data in your VaultPilot MCP environment.
| Parameter | Type | Required | Description |
|---|---|---|---|
name | string | — | |
scope | string | — | |
wallets | object | Yes | |
expiresIn | string | — |
Parameters from the server's own tool schema.
An AI agent can call generate_readonly_link faster than any human can review — one bad instruction and it creates or modifies resources in VaultPilot MCP by the hundred, each call as confident as the last.
Attacks that exploit this kind of access
Generate a time-bound, revocable token that lets someone else read a specific subset of the user's wallets via their own VaultPilot instance. The classic use case: hand the token to a financial advisor or experienced friend so they can look at the user's DeFi positions without being given signing access. Pass wallets (at least one of evm / tron / solana / btc arrays — addresses validated against per-chain regex), optional name (auto-defaults to share-XXXX), expiresIn (1h / 24h / 7d / 30d, default 24h), and scope (read-portfolio only in v1). Returns the token ONCE — the issuer-side store keeps only sha256 of the token, so a recipient who paste-bombs the token into a public channel cannot have it re-emitted. Recipient runs import_readonly_token to decode and then queries the wallets via standard portfolio reads (get_portfolio_summary, get_lending_positions, etc.) using their own RPCs. Model A — the token is structured intent, NOT a security boundary: anyone holding it can query the listed addresses, but anyone could query those addresses without it (chain reads are public). Revocation (revoke_readonly_invite) is issuer-side bookkeeping; it doesn't recall a token already in the wild. Use list_readonly_invites to see what's outstanding. Read-only — no signing, no broadcast. It is categorised as a Write tool in the VaultPilot MCP MCP Server, which means it can create or modify data. Consider rate limits to prevent runaway writes.
generate_readonly_link accepts 4 parameters: name, scope, wallets, expiresIn. Required: wallets. The full parameter table on this page comes from the server's own tool schema.
Register the VaultPilot MCP server in PolicyLayer and add a rule for generate_readonly_link: 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 VaultPilot MCP. Nothing to install.
generate_readonly_link is a Write tool with medium risk. Write tools should be rate-limited to prevent accidental bulk modifications.
Yes. Add a rate_limit block to the generate_readonly_link 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 generate_readonly_link. 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.
generate_readonly_link is provided by the VaultPilot MCP server (vaultpilot-mcp). PolicyLayer sits as a proxy in front of this server to enforce policies before tool calls reach the server.