Administering an observability and security platform should not be a second job. This guide covers everything an owner or admin needs: who can do what, how to manage your team and their access, how to mint safe tokens for scripts and AI agents, how to govern your data and meet your retention and privacy obligations, and how to deprovision cleanly when people, hosts, or whole organisations move on. The defaults are sensible; this is how to make them yours.
Permission models fail when they are too clever to hold in your head. 24Observe keeps it to three roles, each a clean superset of the last, so you always know exactly what a given person can and cannot do.
Because the roles nest cleanly, onboarding is a one-decision exercise: does this person need to administer the platform (admin), own the account and its billing (owner), or simply operate it (member)? You can change a role at any time and it takes effect immediately. There is no sprawling permission matrix to audit, which is precisely the point — a model you cannot fully understand is a model you cannot trust.
Invite people by email and pick their role as you do. They set their own credentials when they accept, so you never handle anyone’s password. Remove someone and their access ends instantly — but everything they did stays in the audit trail, because access ending and history disappearing are two very different things. As the team changes, role re-assignment is immediate, with no seat-juggling.
When a script, a CI job, or an AI agent needs to talk to the platform, mint it a personal access token scoped to exactly what it needs — and nothing more. The full scope list lets you grant narrow, specific capabilities: read this, write that, and no further. A token is shown once at creation and only by its prefix afterward, so it cannot be re-read off a screen later.
Scope is the first guardrail; caps are the second. Attach a daily mutation and data limit to a token so that even if it leaks, the damage is bounded to a day of limited, recoverable activity rather than an open-ended breach. Revoke a token the instant it is exposed and it stops working immediately — no waiting on a cache to expire.
Some powers are off the table for tokens entirely, by design: an automated caller cannot disable or rewrite a detection, cannot delete data, and cannot read stored secrets, regardless of the scopes it holds. So handing a token to an agent is a bounded decision, not a leap of faith. Every call it makes is attributed in the audit log to that token, so you can always answer exactly what your automation did. The agent cookbook walks through building against this safely.
Accounts sign in with a password and can add multi-factor authentication using time-based one-time codes; as an administrator you can require it across the organisation so a stolen password alone is not enough to get in. New accounts verify their email before they become active, which keeps your member list honest and blocks the obvious abuse vectors at the door.
Underneath, the things that quietly matter are handled for you. Credentials are stored as one-way hashes — they are never recoverable, only resettable, so even a worst-case data exposure does not hand anyone a usable password. Sessions are defended against cross-site abuse. And every authentication-relevant action lands in the audit log, so a sign-in from a new place or a flurry of failures is something you can see rather than something you find out about later. You configure the policy; the platform enforces it consistently.
Data is kept on a rolling window suited to its type, with the controls exposed so you can align retention to your own policy rather than inherit someone else’s default.
Sensitive values can be stripped before data is ever stored — both at the edge, before it leaves your environment, and again on the way in — so secrets never land in your logs to begin with.
Your organisation’s data is isolated end to end. The boundary is enforced at the data layer, not patched on afterwards, so one tenant can never see another’s.
An owner can delete the organisation and the purge removes its data across every store — including archived copies — not just the visible rows. Erasure means erasure.
Data governance is where a lot of platforms quietly let you down — generous about ingesting your data, vague about deleting it. 24Observe treats the end of the data lifecycle as seriously as the start. You can see and shape how long things are kept, keep secrets out of storage entirely with redaction, trust that the tenant boundary is real, and, when the time comes, actually erase an organisation completely. These are the controls a security-conscious admin needs to sign off on a tool, and they are built in rather than promised.
Only owners see or change billing, so the financial controls sit with the people accountable for them. Plans are flat and legible — clear entitlements you can predict, not a thicket of per-feature meters that turn a busy month into a surprise invoice. As you grow, you move between plans deliberately; the security and investigation capabilities are part of the platform on every plan, not a tier you have to climb into.
People leave, hosts get retired, devices get swapped, projects end. Each is a clean, independent action: remove a member and access ends at once; revoke a token and it dies instantly; remove a host or device from the fleet and its credential is revoked so it can no longer send data, with the record kept for your history. On a host, the collector uninstalls in one command. Nothing lingers with stale access, and nothing useful is lost.
Every meaningful action in the platform is recorded: a role assignment, a token minted or revoked, a settings change, a detection edited, an incident resolved. Each entry captures who did it, when, from where, and crucially whether it came from a person or from an automated token — so the work your agents do is never confused with the work your people do. The log is queryable and exportable, which turns the two worst questions in any review — "who changed this?" and "what did that token do?" — into a single search instead of a forensic dig.
That is the throughline of administering 24Observe: small, legible roles; least-privilege tokens with hard limits; strong authentication you can tighten; data you can govern and truly erase; and a complete record of who did what. The point of all of it is to let you hand the platform to a growing team, and to a fleet of automated agents, without lying awake about it. Set the policy once, and the platform keeps it.
If you are setting up for a team rather than yourself, a few defaults will save you trouble later. Keep owners to a small handful — the people genuinely accountable for the account and the bill — and make your operations leads admins rather than owners, so the financial controls stay with the right hands. Put everyone else on member; they can do the entire day-to-day job without administrative reach, and you can promote anyone in seconds if that changes. Require multi-factor authentication for the organisation on day one; it is far easier to set the expectation at the start than to retrofit it onto an established team.
For automation, resist the temptation to mint one all-powerful token "to get things working." Create a separate, narrowly-scoped token per job — one for the deploy pipeline that provisions monitors, one for the chatops bot that reads incidents, one for each agent — each with only its required scopes and a daily cap. When something needs to change, you adjust or revoke one token without disturbing the others, and the audit log tells you exactly which automation did what. Decide your retention and redaction posture early too: configure how long each kind of data is kept to match your policy, and turn on redaction so secrets are stripped before storage rather than discovered in your logs during an audit. These are five-minute decisions at the start and painful migrations later. Made up front, they give you an organisation that is secure, legible, and ready to grow — one you can confidently open to more people and more agents without the administrative overhead growing with it.
Administration is not a one-time setup; it drifts if you never look at it. A light recurring review keeps the account honest without becoming a chore. Once a quarter is plenty for most teams. Walk the member list and confirm everyone still belongs and still has the right role — people change teams, contractors roll off, and access that made sense in spring is a liability by autumn. Walk the token list the same way: every token should map to a job you can name, and anything you cannot account for should be revoked on sight, because an orphaned token with broad scope is exactly the kind of quiet exposure that audits exist to catch. Skim the audit log for anything surprising, and confirm your retention windows still match whatever your policy or your customers require.
The work is deliberately small, and that is the point. Because roles are few and legible, tokens are scoped and named, and every action is recorded, a review is a short read rather than an investigation. You are not reconstructing what happened from fragments; you are confirming that what the platform already records still matches your intent. Offboarding follows the same logic — when someone leaves, removing their membership and revoking the tokens they owned closes their access cleanly and immediately, and the audit log preserves the history of what they did while they were here. That combination, fast clean exits plus a permanent record, is what lets a small administrative team stay comfortable as the number of people and agents touching the platform climbs.
Sensible defaults, small roles, least-privilege tokens, real data governance, and a complete audit trail — set it up once and let your team and your agents get to work.