Skip to main content
mount_secret is for tools that take a file path instead of an env var (TLS keys, SSH keys, service-account JSONs). It calls POST /v1/access/{itemId}/use with delivery: file, writes the secret to a temp file with restrictive permissions, and returns an opaque mountId. The file path is never returned to the model. Tools that need to read the file are passed the path through other channels (the host runtime can resolve mountId → path).

​
Input

​
Output

​
File system layout

The mount lives at:
Where:
  • abadge-<random> is a 0700 directory created per mount
  • <filename> is the item ID by default, or the value passed in filename
  • The file itself is 0600

​
Auto-cleanup

The MCP server schedules cleanup 5 minutes after the mount is created. Cleanup also runs on:
  • Server startup (sweeps abadge-* directories older than 10 minutes)
  • Explicit release_mount call

​
What the model sees

  • The opaque mountId
  • Permission and expiry metadata

​
What the model does not see

  • The file path
  • The file contents
  • Anything that lets the model directly read the file
The host runtime is responsible for resolving mountId → path and passing it to whatever tool needs the file.

​
Permission required

use on the item, granted to the MCP agent. Local agents only.

​
Errors

​
Audit

access.mount_file — one row per call, with surface: "mcp", the agent ID, the item ID, the field (if any), and the declared purpose.

​
Example

The model emits:
The MCP server returns { mountId: "3a8f1c...", permissions: "0600", expiresIn: "5 minutes" }. The host runtime maps mountId to the actual path and passes it to a follow-up use_secret (or its own subprocess spawn) as ssh -i <path> ....