Built so a leaked prompt can't become a leaked key.
Permaura treats the LLM as untrusted and puts enforcement where it belongs: at the capability boundary, server-side, audited.
Non-negotiable principles
Agents are never handed raw secrets
The gateway injects a credential at execution time and scrubs it from the response before the agent sees it. No tokens in prompts, logs, or shell history. If a workflow can't be done without exposing a secret to the model, the default is unsupported.
Deny by default
If no policy explicitly allows an action, it is denied. Access is granted by scoped grants, which can carry an expiry, never inherited from whatever credentials live on the machine.
Separate intent from execution
The agent proposes or requests; Permaura executes. The capability boundary, not the prompt, is the security boundary. MCP is transport, not trust.
Audit everything
Who requested what, which agent, which device, which policy decided, which secret was used, what external action happened, and what a human approved: all answerable later.
Threat model
A summary of what Permaura defends against and how. The throughline: limit what the surrounding system can do, rather than trusting the model to behave.
| Threat | Mitigation |
|---|---|
| Prompt injection convinces the agent to act maliciously | The agent can only call capabilities. Policy is evaluated server-side, independent of the prompt. Out-of-scope or over-limit actions are denied with a reason. |
| Secret leaks into transcript, logs, or context | Secrets are injected only at execution time, inside the gateway. The agent is never handed the credential, and the gateway scrubs it from responses before they reach the agent. The audit log keeps a request hash and a summary of each call; a call held for approval also keeps its parameters and result, so the person deciding can see what they are approving. |
| A long-lived credential is over-permissioned | Grants are scoped to principal, resource, and action, can be given an expiry, and can be capped to a number of calls per period, overall and per agent. Sessions revoke instantly. |
| An audit record is altered after the fact | Audit events are hash-chained and ed25519-signed, so an edit made without the signing key fails verification. The log is tamper-evident, not tamper-proof: whoever also holds the signing key could rewrite it, and removing only the newest entries shows up only against a checkpoint kept elsewhere. |
| A high-value action runs without oversight | Critical actions require human approval every time: each request pauses until a person approves or denies it, and an approval releases only that request. A held request does not expire on its own, with one exception: a vault export's approval lapses after ten minutes if it is not collected. A policy can also require the approval to be signed on a paired device (the Permaura iPhone app, its Apple Watch app, or the desktop app on a Mac), or signed on the paired devices of more than one person. From gateway 1.3.44 the quorum counts distinct people, not devices, so one person's iPhone and Apple Watch count once. |
| Hosted execution exposes a secret to the cloud | Local-only is the default. Remote execution is opt-in and honestly scoped: encrypted at rest, briefly decrypted in memory. On a hosted gateway the key that opens your vault is held in our cloud project, so Permaura's cloud administrators can technically reach it, and access to it is logged. BYOK and VPC workers are planned for Enterprise. |
Same-user is not a boundary
Where the gateway and the agents run as one operating system user, any process that user runs can read the operator token and call the API directly. A paired approver device bounds the damage rather than closing the gap: vault export, destructive changes and trust changes are held for a signature while the approval floor is not lowered, so someone holding only the operator token can act within policy but cannot export the vault or turn the hold off. Lowering the floor is the owner’s choice and takes the device’s signature, but once it is lowered, the operator token on the gateway’s machine can export the vault and delete things alone. What makes the operating system enforce the line is running the gateway under its own identity, or keeping agents in a separate account or virtual machine. A container that mounts the owner’s home directory does not.
Account recovery is a trust choice
A gateway with remote access configured is an OAuth resource server for permaura.com, and that makes a permaura.com recovery ticket a third authority for the controls that loosen trust. It exists so an owner whose device and recovery codes are both gone can get back in. The cost is that such a gateway trusts the account and that ticket as part of its custody, because a compromised authorization server could assert the re-authentication itself. A gateway with no remote access has no such route, and no such trust.
Cryptography
The gateway, which seals, opens and uses your credentials, is open source under the Apache License 2.0, and you can read it: github.com/permaura/permaura.
Envelope encryption
A random per-secret DEK (AES-256-GCM / ChaCha20-Poly1305) encrypts each secret, wrapped by a vault KEK.
Key custody
A random vault key, kept in the macOS Keychain or Windows Credential Manager where the platform allows and in an owner-only file otherwise, with each secret's wrapping key derived from it by Argon2id. Hosted workers keep theirs in Secret Manager.
Signed, chained audit
Audit events are ed25519-signed and hash-chained for tamper evidence. Verification is a first-class operation in the console.
Minimal data at rest
Secrets split across ciphertext, wrapped DEK, and metadata. The audit log keeps a request hash and a summary per call; a call held for approval also keeps its parameters and result.
Reporting a vulnerability
Email security@permaura.com. Please do not open a public issue or describe it in a pull request. A vulnerability here can be somebody’s production API key, so we would rather hear about a false alarm than miss a real one.
As much as you have helps: what an attacker gains, the steps to reproduce it, the version or commit you tested, and whether it needs a paired device, an operator token or network access to the gateway. A proof of concept helps and is never required.
We will acknowledge your report, tell you what we think it is, and keep you updated until it is resolved. If we disagree that something is a vulnerability we will say so and explain why. Please give us a reasonable window to ship a fix before disclosing publicly. We will not threaten legal action over good-faith research, and we are happy to credit you in the release notes if you would like to be.
In scope: the gateway, the CLI and npm launcher, the policy engine, the connectors, the SDKs, the hosted service at permaura.com, and the desktop and phone apps. Out of scope: findings that need root on the gateway host, physical access to an unlocked paired device, or the operator token on a gateway with no paired device; missing hardening headers with no demonstrated impact; volumetric denial of service; and scanner output with no analysis. Fixes go into the latest release of each, so please test against it.
What would you hand off, if it had to ask first?
Free on your own computer, no card. Connect one app, say what needs a yes, and answer the first request from your iPhone, Apple Watch, Mac or Windows PC.