Workspace roles and policies
The Chancery
The Chancery is identity and access for your Zipper workspace, built on Palace RBAC rather than bolted on beside it. Resources sit in a simple hierarchy — workspace → project → service — and every request is judged by an explicit policy: who (a teammate, a key, an app) may do what (a console action or an API verb) to which resource, under which conditions (project, hostname, time window, or a required MFA claim). Deny always beats allow. Write a change, run it in the simulator against the last twenty-four hours of real audit events to see what it would have blocked or allowed, then publish with one click; policy history keeps the trail and rollback is one action. Ask the plain question — “who can reach The Cellar?” — and get the answer as a list. Honest limits, stated plainly: this is workspace policy, not an identity provider — no SAML or OIDC single sign-on, no directory sync, no organization-wide MFA mandate. It answers “what may happen here,” not “who are you.” Included on every Zipper plan.
Cloudflare analogue: IAM policy engine
What it is
The Chancery is identity and access for your Zipper workspace, built on Palace RBAC rather than bolted on beside it. Resources sit in a simple hierarchy — workspace → project → service — and every request is judged by an explicit policy: who (a teammate, a key, an app) may do what (a console action or an API verb) to which resource, under which conditions (project, hostname, time window, or a required MFA claim). Deny always beats allow. Write a change, run it in the simulator against the last twenty-four hours of real audit events to see what it would have blocked or allowed, then publish with one click; policy history keeps the trail and rollback is one action. Ask the plain question — “who can reach The Cellar?” — and get the answer as a list. Honest limits, stated plainly: this is workspace policy, not an identity provider — no SAML or OIDC single sign-on, no directory sync, no organization-wide MFA mandate. It answers “what may happen here,” not “who are you.”
Closest analogue: IAM policy engine. SLA 99.99% · p99 25ms. Owners publish policies. Stewards simulate and roll back. Wardens and Scribes read access reports.
- ▸Workspace → project → service hierarchy
- ▸Allow and deny policies with conditions
- ▸Policy simulator over real audit events
- ▸Policy history with one-click rollback
- ▸Access reports: “who can reach this?”
- ▸Owner · Steward · Warden · Scribe · Guest roles
How it works
Resources sit in a simple hierarchy — workspace → project → service — and each policy says who may do what to which resource, under which conditions (project, hostname, time window, or a required MFA claim).
Deny always beats allow: a single deny overrides every allow, so guardrails cannot be voted away.
Write a draft, then run the simulator against the last twenty-four hours of real audit events to see exactly what it would have blocked or allowed before you publish.
Policy history keeps every published version — rollback is one action. Access reports answer “who can reach The Cellar?” as a plain list.
Honest limits: this is workspace policy, not an identity provider — no SAML or OIDC single sign-on, no directory sync, no organization-wide MFA mandate.
Use cases
Concrete ways teams use this service on day one.
Separate duties before an audit
An ops lead needs wardens to manage security without touching databases or billing.
- Confirm the built-in roles: Warden covers security services; database and hosting writes stay with Stewards and Owners.
- Add a deny policy on The Cellar for the warden role, with a hostname condition if needed.
- Simulate against yesterday’s audit events, then publish. Rollback stays one click away.
Answer “who can reach this?”
A security reviewer asks which people and keys can touch the payments service.
- Open Access reports → pick the project → pick the service.
- Read the evaluated list: principals, matched policies, and conditions.
- Export the report as the evidence artifact for the review.
Set it up in the dashboard
Dashboard → Identity & Access → The Chancery → Policies: the live allow/deny list on the hierarchy.
Simulator: paste or edit a draft policy and watch it run over real audit events.
History: every published version with author, diff, and rollback.
Access reports: “who can reach …” across people, keys, and apps.
Configure: conditions, simulator, access reports, and policy history window (deny-guardrails cannot be turned off).
API
Control-plane: GET|PATCH /api/v1/services/chancery. Send Authorization: Bearer tz_live_YOUR_TOKEN.
Creates count against the plan quota. A 402 plan_limit means you are at the cap — upgrade or delete an unused resource.
Read Chancery policy configuration
curl -sS https://tinyzipper.com/api/v1/services/chancery \ -H "Authorization: Bearer tz_live_YOUR_TOKEN"
Extend policy history to a year
curl -sS -X PATCH https://tinyzipper.com/api/v1/services/chancery \
-H "Authorization: Bearer tz_live_YOUR_TOKEN" \
-H "Idempotency-Key: $(uuidgen)" \
-H "Content-Type: application/json" \
-d '{"policyHistoryDays":365,"policySimulator":true}'List the same resource in JavaScript
const res = await fetch("https://tinyzipper.com/api/v1/services/chancery", {
method: "GET",
headers: {
Authorization: `Bearer ${process.env.ZIPPER_TOKEN}`,
"Content-Type": "application/json"
}
});
const json = await res.json();
if (!res.ok) throw new Error(json.error ?? res.statusText);
console.log(json);Tips
Start every change in the simulator — it replays real events, not guesses.
Deny beats allow by design; write exceptions as narrower allows, never by deleting the deny.
Built-in roles (Owner, Steward, Warden, Scribe, Guest) are policies too — they live in the same history.
Workspace policy only: for who-your-users-are questions, use The Throne Room sign-in and your own IdP.
Every publish records author, diff, and time — that trail is the audit artifact.
- ▸SOC 2
- ▸Palace RBAC
- ▸Policy audit trail
Runbook
Write an allow or deny policy on the workspace → project → service hierarchy, run it in the simulator against the last twenty-four hours of audit events, then publish. Deny always beats allow. Policy history keeps versions for rollback, and access reports answer “who can reach this service?”. Workspace policy only — not an identity provider.
Next: The Safe-Conduct · All docs · Create a free account