Opening your Perimeter
- From dashboard: On the Bunkers page, open the menu for your perimeter and choose Configure. This is only possible with keys synced with your passkey.
- From CLI: Run
tinfoil perimeter open <name>to open the local address it prints. This works with either key mode and eliminates hosted JS from the threat model. See the trust model for more information.
Connectors
A connection is a service you have connected to the Perimeter, such as your GitHub account or a Postgres database. The catalog holds several hundred presets in four groups:
A preset describes the service’s operations and what each one does: read, write, delete, send, publish, pay, and so on. That is what lets the Perimeter tell a harmless read from a payment. Prefer a named service over a generic connection, as a generic TCP connection lets the Perimeter see only the host and port, so it cannot judge individual requests.
To let a Bunker use a connection, set its access on the Sandboxes page. Inside the Bunker,
monitor connections lists what it can use.
Access control
Each Bunker has an access level for each connection:
When a request needs approval, it waits in Activity, where you choose Allow once, Allow always, or Deny. A request that gets no answer within two minutes fails.
Agents can see their own policy with
monitor policy show and request changes with monitor policy propose. A proposal changes nothing until you approve it under Activity. Agents cannot propose changes to credentials, MCP tool pins, other Bunkers, or global settings.
Credential substitution
A Bunker never sees your real credentials. It gets a placeholder for each one, such astfm_github_k3j9x2m4q, and the Perimeter swaps in the real value after the request passes policy.
monitor run and monitor shell export placeholders as environment variables, so tools pick them up as if they were real:
MONITOR_CREDENTIAL_<CONNECTION>_<NAME>, and under their plain name, like GITHUB_TOKEN, when no other connection uses that name.
A placeholder works only in the position its connection declares (one header, query parameter, Basic auth field, or path segment) and only for that connection’s exact HTTPS origin and path prefix. A placeholder found anywhere else is refused to prevent an agent from sending your GitHub token to another host by pasting its placeholder into a different request.
The Perimeter also refreshes OAuth tokens for you. Protocol connections such as Postgres, SSH, and email do not use placeholders: the Perimeter logs in to the service with the stored credential and passes the session through.
MCP tool pinning
MCP servers are vulnerable to what is known as a Jumping the line attack. An MCP server sends clients descriptions for their tools and how to use them, which gets put directly into the agent’s context. This gives actors an opportunity to perform arbitrary code execution, as a server can decide to prompt inject at a moment’s notice while using the same tools. To prevent rugpulls, the Perimeter offers pinning MCPs as a feature. When you add an MCP connection, the Perimeter records the server’s instructions and the full definition of each tool: name, description, input schema, and annotations. No tool is exposed to the Bunker until you review and approve these definitions. Each time the Perimeter connects to the server, it compares the current definitions with the pinned ones:- A tool whose definition changed in any way, or a new tool, is hidden from the Bunker.
- If the server’s instructions changed, every tool is hidden.
- The connection shows N MCP tools need review. Open it, choose Review MCP tool definitions and View changes to see what is new, changed, or removed, then Approve changes to pin the current set.