Skip to main content

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 secret out of the response.
  4. Only the result comes back to the agent. The key never entered the model.
  5. Everything is audited. Each decision is recorded in an ed25519, hash-chained log — tamper-evident by construction.

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.

The dashboard: what your agents are doing right now, and what Permaura decided

permaura.com is never in the request path​

When you sign in and connect a gateway, permaura.com does identity, policy storage, audit metadata, remote-access setup, and billing. What it never does is touch a secret value or sit in the middle of a call.

For a remote agent, permaura.com acts only as the sign-in authority: it proves you authorised 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's servers.

Honesty rule

"Your secrets never leave your device" is true when your gateway runs locally or on hardware you control. 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.