Built to be distrusted.
Agent tokens bound to one person and revocable in a click, a refuse-by-default decision on every call, and an append-only record that includes the refusals.
Short-lived agent tokens, not pasted keys.
An agent does not hold your systems' credentials. It holds a token for your workspace, issued to the person who signed it in, that Tier Two can revoke.
Bound to one person
An agent signs in through OAuth and gets a token issued to one member of your workspace and one client. It carries that person's access (not a shared service account's) and every request re-verifies it.
Revocable in a click
Revoke an agent and its token stops working; the change reaches the endpoint within a minute. There is no key on a laptop to chase and nothing to rotate downstream.
Nothing to paste
No API key crosses a config file, a chat window, or a screen share to get an agent working. The credential the agent would otherwise hold does not exist.
Verifying a Tier Two-signed authorization downstream (the Ed25519 JWT and the published key set) is documented in Docs → Security.
Downstream credentials stay server-side.
Sealed vault
Downstream credentials are AEAD-encrypted at rest, with one write path and one decrypt path. They are never persisted in plaintext.
Server-side only
A workspace's shared key is decrypted only for the call it is needed for and used in process to forward it. It never reaches a device.
Per-person, revocable
When people sign in with their own accounts, tokens are brokered per person and revocable at any time. Downstream permissions stay exactly what that person already had.
Take the token, not the keys.
Assume an agent token leaks. What it buys an attacker is bounded by the modes you set, still stops at every Ask, and is already written down.
Only what that person may do
A stolen agent token reaches exactly the tools set to Allow for that member, not every system the org has connected.
Writes still wait
Anything on Ask still pauses for a human, and the approval names the person and shows the arguments. The theft has to get past someone.
One revoke ends it
Revoke the agent in the dashboard and the next call fails. Nothing downstream has to be re-keyed.
Attempts leave tracks
Every call it tried (allowed, asked, or refused) is already in the append-only ledger, with the tool and the arguments.
Append-only, allowed and refused alike.
Two ledgers back every claim on this page: a call ledger with every call and every refusal (person, agent, connection, tool, outcome, reason), and a governance ledger with every change to the rules themselves. Neither can be edited after the fact.
Call ledger
Who called what, as which identity, and what happened. Refusals are first-class rows, not missing ones.
Governance ledger
Mode changes, preset changes, credential rotations, approvals and revocations, each with the human who made the change.
Streams to your SIEM
Both ledgers export as three versioned streams (decisions, governance changes, sessions) over HMAC-signed webhooks or Splunk HEC. Ordered, at least once, minutes behind live.
What we haven't built yet.
We'd rather tell you than have you find out. These are planned, not shipped:
- Key custody in KMS/HSM
- Directory sync (SCIM)
- Sender-constrained (DPoP) agent tokens
- Self-hosted deployment
Found something? We want to know: jordan@trytiertwo.com