Teams, roles & namespaces

Share a tripwire estate with a team and control exactly who can see and change what, using roles plus Vault-style hierarchical namespaces.

Organizations

Every user has a personal workspace. To collaborate, create an organization — a shared estate of tripwires that members work on together. The creator becomes the owner. Switch which org you are acting in with the org switcher on the dashboard (web), --org (CLI), or the X-Org-ID header (API). With no org selected you are in your personal workspace.

Roles

Each member holds one role. Roles are ranked owner > admin > member > viewer:

^* scoped = the whole org by default, or restricted to specific namespaces if the member has namespace grants (below). Owners and admins always have full, unconstrained access.

• owner — the creator; full control. Cannot be removed or demoted, and ownership cannot be granted to anyone else.
• admin — manage members and roles, plus full tripwire access.
• member — read and write tripwires, optionally constrained to namespace grants.
• viewer — read-only, optionally constrained to namespace grants.

Only an admin or owner can add, re-role, or remove members.

Namespaces

A namespace is a path on a tripwire, like eng/api. A member can be granted read or write on a path. Grants are hierarchical, exactly like HashiCorp Vault: a grant on a path covers that path and everything beneath it, but never its ancestors or siblings.

write implies read down the tree, and a read grant extends visibility down the tree. A tripwire is created in a namespace via the Namespace field (web), --namespace (CLI), or the namespace body field (API).

Worked examples

1. Read-only access for an external auditor

Let an auditor see the production decoys but change nothing.

# CLI
tripwire orgs add-member <org-id> auditor@partner.example \
  --role viewer --grant prod:read

# Web: Settings → Organizations → Manage members →
#   user: auditor@partner.example · role: viewer · namespaces: prod:read

Result: the auditor sees prod and everything under it, read-only; every other namespace is hidden, and every write is refused.

2. A team owns its own subtree

Give the payments team full control of team/payments and nothing else.

tripwire orgs add-member <org-id> lead@corp.example \
  --role member --grant team/payments:write

Result: read + write across team/payments and everything beneath it; other teams' namespaces are invisible.

3. A platform team that spans sub-teams

Platform engineering should see every engineering namespace, but not ops.

tripwire orgs add-member <org-id> platform@corp.example \
  --role member --grant eng:read

Result: read across eng, eng/api, eng/web (the whole eng subtree) — but the separate ops/* tree stays hidden. This is the hierarchy at work.

4. Delegate administration

Let a team lead manage members themselves.

tripwire orgs set-role <org-id> <user-id> admin

Result: the lead can now add/remove members and has full tripwire access (admins are never namespace-constrained).

Enforcement

• Filtered, not just hidden — tripwires outside a member's granted namespaces are excluded from list and detail responses entirely.
• Writes are refused — creating, editing, moving or deleting outside a write grant returns 403 Forbidden (and the web UI doesn't offer the action).
• Enforced server-side — identically across the web app, the CLI and the API, so the same rules apply however a member connects.

See it proven end-to-end in the namespaces video above: a member granted eng:read is allowed to view eng/* but receives 403 on any write.