How Permaura works

Before the objects and the steps, one idea that everything else hangs off:

The key has to exist in plaintext at the exact instant a call is made. Whoever makes the call holds the key at that moment. So custody and execution are inseparable: "who holds the secret" is "where the work runs." They are one question, never two.

That single fact is why Permaura runs the secret on a gateway you control, and why where the gateway runs is the only real deployment decision. But the loop that runs a request is identical wherever the gateway lives.

The enforcement loop

1. The agent calls a capability, never a raw secret. Tools are named for what they do (braintree.transactions.refund, github.actions.deploy), never get_secret. There is deliberately no way to ask Permaura for a key.
2. Policy evaluates the request. Permaura is deny-by-default: nothing runs unless a grant explicitly allows this agent, this capability, on this connection. High-risk actions can pause for a human.
3. The gateway performs the call. It resolves the secret for the length of one call, uses the plaintext inside a closure that zeroizes on return, calls the upstream API, and redacts the response: fields whose names are known to carry secrets are blanked and, from gateway 1.3.44, so is the credential it opened for that call, as is and in its common encodings, if it is at least 8 bytes long. A shorter credential, or any other secret, is caught only by field name.
4. Only the result comes back to the agent. The gateway never hands the key to the model.
5. Decisions are audited. Each policy decision (allowed, held or denied) and each execution is recorded in an ed25519-signed, hash-chained log, tamper-evident within the limits the FAQ sets out. A call refused before any policy looks at it (unauthenticated, rate-limited, too large, or naming a capability the gateway does not have) is answered without an entry.

Intent is separated from execution

The agent expresses intent ("refund this charge"). Permaura owns execution (holding the key, making the call, recording it). That separation is the whole product:

• A prompt-injection that tells your agent to "refund everything" still hits the policy wall: the agent can ask, but Permaura decides.
• The secret's blast radius shrinks to a single approved call instead of "anything the key can do."
• You get one tamper-evident record of every action an agent took, across every tool.

permaura.com is not in an agent's request path

When you sign in and connect a gateway, permaura.com does identity, your organizations, workspaces and members, remote-access setup, and billing. It never sits in the middle of an agent's call, and it stores none of your connections' credentials.

It does relay the console. The console and the Permaura app reach a gateway they cannot dial directly (one with remote access on, or on another machine) through permaura.com, which passes each request on in memory without logging it. So a credential you type into the console or the app for such a gateway, or a vault bundle and its passphrase, passes through permaura.com on its way to the gateway. The FAQ says how to keep one off it entirely.

For a remote agent, permaura.com acts only as the sign-in authority: it proves you authorized the agent, hands the agent a short-lived token scoped to your gateway, and then steps out of the way. The agent talks directly to your gateway; the bytes of the actual call never pass through permaura.com. Through a managed permaura.app tunnel they do pass through Cloudflare under Permaura's Cloudflare account, which can see or redirect them, and run a second connector for the tunnel, as the threat model explains; on a gateway you run yourself, through a tunnel or domain of your own or on your own network, they pass through nothing Permaura runs. A hosted worker is different, because Permaura runs it.

Honesty rule

"Your secrets never leave your device" is true of what the gateway stores when it runs locally or on hardware you control, with three qualifications: a credential you type into the console for a tunneled gateway passes through permaura.com on the way in, as above; a managed permaura.app tunnel carries the gateway's traffic, including an agent's calls and their responses, through Cloudflare under Permaura's Cloudflare account, which can see or redirect it, and run a second connector for the tunnel; and an owner, or someone an owner has granted Export the vault, can take a stored credential out through a vault export, which is recorded in the audit log and, once a device is paired, waits for its approval unless the approval floor has been lowered. Wherever the gateway makes the call, the plaintext is briefly present there, so hosted execution is not cryptographic zero-knowledge, and Permaura never claims otherwise. See where your gateway runs for the honest tradeoff at each placement.