Security
Security
What Temper protects against, roughly how, what it does not protect against yet, and what you need to do on your side.
This page is for your security review: what Temper protects against, roughly how, and what is not covered yet. It leaves out implementation details.
Our starting assumption
Temper gives each of your end users a computer that runs an AI agent. We assume the agent may already be compromised at any moment: the web pages, emails and documents it reads can contain hidden instructions (prompt injection) that tell it to do things the user never wanted. So protection does not rely on the agent behaving. It relies on boundaries the agent cannot get around:
- The agent runs in an isolated environment and never gets real credentials.
- The agent has exactly one way out to the network, can only go where you allow, and every access is recorded.
- High-risk actions (sending, paying, deleting, changing permissions) need the end user's approval. Decisions can only come in through your backend or your console, so the agent cannot forge them.
- One end user's data is physically separate from another's.
What we protect against
| Risk | Example | How we protect |
|---|---|---|
| Stolen credentials | Instructions on a web page tell the agent to send out an API key or login credentials | Real credentials never enter the agent's computer. The agent gets a stand-in, which the platform replaces with the real value only on the sites you specify. Taking the stand-in is useless |
| Data exfiltration | The agent sends the user's email content to an unknown site | Traffic can only leave through the platform's egress, which only allows domains you permit. Everything else is blocked, and every outbound access is recorded in the audit log |
| Unauthorized actions | The agent is tricked into sending email, paying or deleting files on the user's behalf | Every category of action is checked against the policy you configure. High-risk actions always need the end user's approval. Decisions are only accepted from your backend (signed, or with your API key) and from your team in the console, so the agent cannot forge them |
| Account takeover | The agent uses a verification code or password reset link from the mailbox to sign in to another site | The platform's email tool masks verification codes, reset links and one-time sign-in links before handing a message to the agent. Submitting passwords or verification codes in the browser needs approval |
| Abuse of browser sessions | A page gets the agent to read cookies, or to pay or change a password on a site where the user is signed in | The signed-in browser only allows a limited set of operations: no reading cookies, no running arbitrary scripts. Payment, password and delete operations need approval. While the end user takes over the browser, the agent is locked out |
| Tampering with tools | The agent rewrites a connector's code to use the tool's credentials for something else | Connectors run where the agent cannot reach them. Each connector only gets its own credentials and can only reach its own service |
| Escaping isolation | The agent tries to attack the computer it runs on or the host | Several layers of isolation: the agent runs in a restricted runtime unit, the runtime unit runs in its own virtual machine, and virtual machines are separated from each other and from the host |
| Cross-user access | One user's agent reads another user's data | Each end user has a separate virtual machine and a separately encrypted data disk. Virtual machines cannot reach each other over the network or reach the platform's internal addresses |
| Runaway consumption | The agent loops forever, burning compute or model spend | You can set monthly usage limits per environment and per developer, and an environment is suspended automatically when it goes over. Tasks have timeouts. Idle environments are suspended automatically |
Your account and API
| Risk | How we protect |
|---|---|
| Another developer seeing or changing your resources | Every request is tied to a developer by its API key or console sign-in, and can only see and change that developer's resources. Other developers' resources are treated as if they don't exist |
| A leaked API key | The control plane stores only a hash of each API key, and the key is shown once, when it is created. You can revoke it in the console at any time, and a leaked key can also revoke itself. An API key cannot create new keys, add team members or change the webhook URL |
| Team member permissions | The console signs people in individually (Google or GitHub), with owner and member roles. Only owners can create API keys, change the webhook or remove members, and only after signing in recently. Someone removed from the team loses access immediately |
| Credentials or tokens being read back | Your secrets, end users' OAuth tokens and your OAuth app secrets are never returned by any endpoint. The webhook signing secret and API keys are returned only once, when they are created |
| Forged webhooks | Every webhook the platform sends you carries a signature and a timestamp, and the SDKs include a verification function. When you rotate the signing secret, there is a 24-hour overlap |
| Console impersonation | Console credentials are kept in cookies that browser scripts cannot read. The console only connects to the control plane configured at deployment. Requests that change things are checked against cross-site request forgery |
What we don't protect against yet
We want to be clear that these cases are currently outside what we protect:
- Misconduct by the platform operator or insider access: this is currently constrained by access controls and audit. Stronger cryptographic guarantees (confidential computing) come later.
- Abuse within what you allowed: for example, the agent writes data into the user's own cloud document and then shares it. Stopping this requires tracking data flow, which comes later.
- Mistakes by the model itself: the platform limits the consequences of mistakes (approvals, allowlists, usage limits) but does not guarantee the agent won't make them.
- The security of your own systems: your backend, the API keys and webhook signing secret you hold, and the interface you give your end users are your responsibility (see the next section).
What you need to do
- Keep API keys and the webhook signing secret safe, on the server side only. If you suspect a leak, revoke the key or rotate the secret in the console.
- Always verify the signature of incoming webhooks, using the SDK's verification function on the raw request body. See handling approval webhooks.
- Show approval requests to end users faithfully and let the end users themselves decide. Don't approve high-risk actions automatically in your backend.
- Configure policies, egress allowlists and usage limits as you need them. Store secrets such as model API keys as platform secrets, not in your agent package or in files in the environment. See using your model API key.
- Give team members the right roles, and remove people from the team promptly when they leave.
Security work
- An internal security review is under way during development. An external penetration test will be completed before the first customer goes live, and a bug bounty will open after launch.
- Audit log: every outbound access by the agent, every use of a credential, every approval and every browser operation is recorded. You can query and export the records per environment, and exported records can be checked offline for tampering. See audit.
- To report a security issue, contact us: contact details coming soon.