Scope
Bounded by something you can read
Read, draft and approve are separate scopes on separate keys. A read-only key never sees the approve tools.
Your credentials, your data and your agent’s reach are each held inside a boundary you can inspect: a scope on a key, an organisation on a query, a row on the record.
An unbounded integration, and this one
- One credential carries every permission the platform will grant, because narrowing it was extra work nobody had time for.
- The token sits in an environment file, copied onto whichever machine needed it last, with no record of who holds a copy.
- The log records that an action happened and when, but not which agent took it, on whose authority or against which account.
- Read, draft and approve are separate scopes, chosen when the key is minted. A read-only key never sees the approve tools at all.
- The credential is encrypted at rest under a versioned key, decrypted inside the request that uses it, and never sent to a browser.
- Every draft, plan and connection action lands on the record with the organisation, the actor and the authority that cleared it.
How a credential arrives, and what it can reach
- 01
It arrives encrypted and stays that way
You authorise Tempio against the platform and the credential comes back to the server, never to the page you are looking at. It is written encrypted at rest under a versioned key, so rotating that key does not mean re-authorising every account you have connected. It is decrypted inside the request that uses it, and the decrypted value never appears in an application log, an error report or a payload sent to your browser.
- 02
Every query is scoped to your organisation
Every read and every write in the ads domain is filtered by organisation at the application layer, and that organisation comes from your session or from the key the request arrived on, never from a parameter the caller chose. Cross-organisation tests on every ads service cover the isolation, so a service that lost its scope fails its own suite before it ships.
- 03
A change is re-read at the moment it lands
Every change is written as a draft and held at the gate. Publishing to live accounts is in private beta. When the change lands, the gate re-reads current state rather than the state the draft was written against, because a draft can sit in a queue while real time passes. The connection’s status and every budget-bearing row are checked again before anything is sent. Approve is opt-in when a key is minted, and the embedded chat agent is never handed the approve tools, which are filtered out of its surface rather than withheld at run time.
Six things you can check
Credentials encrypted at rest
Every platform credential is stored encrypted under a versioned key and decrypted only inside the request that uses it. It is never written to a log, never returned by an API route and never sent to the browser.
Scoped to one organisation
Every ads-domain query is filtered by organisation at the application layer. Two workspaces cannot see each other’s accounts, spend or drafts, and cross-organisation tests on every ads service check it.
Keys that carry one scope
A key is minted for a purpose and carries nothing beyond it, so the agent on your laptop and the one on a build server need not hold the same reach, and neither can be widened after the fact.
A key dies with the membership that minted it
Membership is checked on every call the key makes. Remove somebody from the organisation and the keys they minted stop answering in the same moment, with nothing to revoke by hand.
Every action on the record
Every draft, plan and connection action lands on the record, scoped to your organisation. The row carries who acted, which authority cleared it and what the platform said back, so a question asked months later has an answer that does not depend on anyone’s memory.
Any status but active blocks the apply
A connection whose status is paused, disconnected or in error stops every change written against it: the gate re-reads that status at the moment of apply and refuses, naming the connection and its state, before anything is sent.
Questions
Put frontier AI to work on every ad account you run.
Connect an account and read exactly what the key you mint can and cannot reach before you point an agent at it. Early access is open, and invitations go out in the order people joined.
Request early access- Read and draft by default. Approve is a separate permission you grant.
The headers this build sends
The table below is rendered from the same object the build hands the framework, so a header removed from the configuration disappears from this page in the same commit.
| Header | Value |
|---|---|
| Content-Security-Policy | default-src 'self'; script-src 'self' 'unsafe-inline' 'wasm-unsafe-eval'; style-src 'self' 'unsafe-inline'; img-src 'self' data: blob:; font-src 'self'; connect-src 'self' blob:; worker-src 'self' blob:; frame-src 'none'; object-src 'none'; base-uri 'self'; form-action 'self'; frame-ancestors 'none'; upgrade-insecure-requests |
| Strict-Transport-Security | max-age=63072000; includeSubDomains; preload |
| X-Frame-Options | DENY |
| X-Content-Type-Options | nosniff |
| Referrer-Policy | strict-origin-when-cross-origin |
| Permissions-Policy | camera=(), microphone=(), geolocation=(), payment=(), usb=(), interest-cohort=() |
What is not true yet
Encrypted credentials, org-scoped data, every change on the record.
- No external security audit has been carried out, and none is scheduled.
- Tempio holds no security certification of any kind, and no page on this site claims one.
- 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.
- There is no penetration test report to send you, because none has been commissioned.