Security

This is the operator's version of what the security page says: the boundaries Tempio holds, described so you can check them rather than take them on trust.

Platform credentials

You authorise Tempio against a platform and the credential comes back to the server, never to the page you were looking at.

• It is written encrypted at rest with AES-256-GCM under a key from a versioned ring. The ring is what makes rotation possible without re-authorising every account you have connected: a new key is added, becomes the one that encrypts, and the old one keeps decrypting until the last blob has been resealed.
• It is bound to the workspace and the grant it belongs to. The binding is part of the encryption, so a blob moved onto another workspace's row fails to authenticate rather than quietly granting access across a boundary.
• It is decrypted inside the request that uses it and nowhere else. Not in a log, not in an error report, not in anything returned to a browser.

Tempio never asks you for a platform password, and the only thing it holds is the grant that platform issued, which you can revoke on the platform's own side at any time.

One workspace, one boundary

Every read and every write in the ads domain is filtered by workspace at the application layer, and the workspace comes from your session or from the credential the request arrived on — never from a parameter the caller chose. An id from another workspace does not produce a refusal so much as produce nothing: it matches no row.

That includes the links a tool result hands an agent. A deep link is built from a row a scoped query already returned, so an id from elsewhere never produces a URL because it never produces a row. The URL is not a grant either: opening it needs a session, and the page checks membership again.

The isolation is covered by cross-workspace tests on the ads services, so a service that lost its scope fails its own suite rather than shipping quietly.

What a credential can reach

Three scopes, chosen when a key is minted, and they only ever narrow.

approve is opt-in and off by default. The in-app agent is never handed those tools at all — they are filtered out of the tool list it is built with, rather than refused at run time — so there is no phrasing that gets the chat to apply something.

A key also dies with the membership that minted it. Membership is re-read on every call, not checked once on the day the key was created: remove somebody from the workspace and the keys they minted stop answering in the same moment, with nothing to revoke by hand. Keys are shown once, stored only as a prefix and a hash, and revocable. MCP keys has the mechanics.

Nothing writes without passing the gate twice

Every write from every door — the app's own buttons, the agent, your AI over MCP — is a change request before it is a change. What the gate re-reads at the moment of apply is current state rather than the state the draft was written against: the connection's status and every budget-bearing figure are checked again before anything is sent. Guardrails is the list of what is checked.

A connection whose status is anything but active blocks every apply on it. That is the kill switch, and it is one click on Connections.

The record

Every action lands in an audit row: the workspace, the actor and what kind of actor it was — a person, the agent, an MCP credential or staff — the action, the target, and a little structured metadata. Drafts, approvals, applies, refusals, connection changes, plan edits and raw platform calls all write one.

The log names an actor rather than linking to a user account, which is what lets it hold a rule or a key as readily as a person, and what lets it outlive the row it describes: a change request can be edited or superseded, and what happened to it stays readable.

For raw platform requests the row carries the method, host, path and size of the call. The response body is never stored.

Staff access

Tempio's own staff console is a separate application with its own guard, and it is the only place an admin actor type comes from. Staff actions land in the same audit log as everybody else's, under that actor type, so "who changed this" has one answer wherever the change came from.

What is not true yet

Stated plainly, because the alternative is letting silence imply it:

• No external security audit has been carried out, and none is scheduled.
• Tempio holds no security certification of any kind.
• There is no data processing agreement on offer and no published list of sub-processors.
• There is no status page and no uptime commitment. A platform-side failure shows as a failed sync on the connection, with the platform's own error attached to it — Troubleshooting covers reading one.
• There is no penetration test report to send you, because none has been commissioned.

Everything above this section is a mechanism you can check. Nothing above it is a certification, and none of it is claimed as one.

If you find something

Write to hello@tempio.ai with what you found and how to reproduce it. A report that names a workspace, a key prefix or a request id is faster to act on than one that does not — and please do not include the key itself.