Product

What's new

A public-safe, plain-language log of what we've shipped. Newest first. Agents can read the same source as a versioned JSON document; internal work logs, infrastructure details, and security-sensitive operations stay private.

A safety check that had quietly stopped reading recent work — and the cross-check that will notice next time

September 10, 2026

One of the internal reviews Obelisk runs before a release looks over the most recent improvement plans and refuses anything malformed. It had been passing every time, and it should not have been: months ago those plans started being filed under a slightly different name, and the review only recognised the old one. It was still running, still reporting success — but always about the same old document, and never about anything written since. Nothing reached customers because of it, and the plans themselves were sound; the review simply was not looking at them. It now identifies each plan by what the document says about itself rather than by how its file happens to be named, checks every plan rather than one, and states plainly how many it checked so a clean result says what earned it. The more useful part is the second fix: the same naming change had been found and corrected once before, in one of the several places that need it, and the rest were missed. Those places now have to agree with each other about which plan is the most recent one, and if they ever stop agreeing, the review says which one has fallen behind. Release notes

The running server is now checked against the vault it was provisioned from, without any value leaving either side

September 9, 2026

Yesterday's check confirmed the running process carries the settings it was given — by name. Today's goes one level further and checks that each setting carries the VALUE the studio's credential vault holds for it, and it does so without either side revealing the value: the server and the vault each compute a one-time fingerprint of their copy under a code minted fresh for that check, and only the fingerprints are compared. The first run found one disagreement — the display name the vault records for the Gate's passkey prompts had drifted from the name the server actually shows — and reported honestly that most settings on the server have no vault copy at all to compare against, which is a question for the studio rather than a defect. Separately, the internal status record every dashboard reads was audited field by field for which of its entries anything actually keeps true; several turned out to be typed by hand and checked by nothing, and each now has to agree with a source that is measured before a release is allowed out. How Obelisk protects sign-in

The running server is now checked against the settings it was given

September 9, 2026

Yesterday's invitation fix was late for a reason worth explaining. The setting that closes sign-up had been written to the server correctly, but the server's own service configuration was quietly removing it again before the process started, and every check Obelisk ran read either the code, the version that was deployed, or what the server said about itself — none of them read the configuration that actually shapes the running process. Obelisk now compares the settings the running process really has against the settings it was given, on every health pass, and refuses to write a setting that the service would remove. The same pass found a second gap: an internal health check had been quietly failing for sixteen days without counting as a failure. It counts now. How Obelisk protects sign-in

Creating an account on obeliskgate.com now requires an invitation

September 9, 2026

Until today anyone could create an account on obeliskgate.com. That was the intended setting when the Gate first opened to the public, but it is no longer the right one, and — more importantly — the site had been describing itself incorrectly: an internal status field already reported enrolment as invite-only while the sign-up page still accepted everyone. Two separate settings controlled that, one describing the policy and one enforcing it, and only the describing half had been switched. The enforcing half was being removed automatically by a server configuration file that had been quietly cancelling it since early August, which also meant the documented way to close sign-ups did nothing when an operator tried it. Both halves are fixed. New accounts now need an invitation, existing accounts and sign-in are completely unaffected, and if the two settings ever disagree again the door closes rather than opens — a policy the service cannot actually enforce will no longer be advertised as though it can. How Obelisk protects sign-in

Alerts we do not recognise now reach you, and unrated vulnerabilities stop sinking to the bottom of the list

September 8, 2026

Obelisk ranks things by severity in several places, and every one of those rankings knew a fixed list of severity names. Anything outside that list had no defined place, so it quietly landed wherever the arithmetic happened to put it — usually at the bottom, occasionally nowhere at all. Three effects mattered. Security alerts carrying a severity this build did not recognise were dropped by the outbound alert channel and recorded as "below your minimum severity", which was not true — they had never been compared to it; those alerts are now sent and marked as unrecognised, and the "below minimum" note is reserved for alerts that really were compared and filtered. A vulnerability whose public severity rating could not be read used to sort beneath every vulnerability rated Low, which is exactly backwards for the one entry you know least about; it now appears above High and below Critical, so it surfaces without displacing anything confirmed worse. And an abuse signal of a kind this build did not know was scored as the mildest thing on the scale rather than as something to look at. Nothing about recognised severities changed, and known-exploited vulnerabilities still sort first. How Obelisk protects sign-in

Health checks no longer compete with your requests

September 8, 2026

Obelisk answers a small, unauthenticated health endpoint that uptime monitors poll constantly — it is deliberately never rate-limited, because a health check that answers "too many requests" reports the rate limiter's opinion instead of the service's. Because it is never limited, how much work it does matters more than anywhere else, and it was doing more than it needed: reading two small files from disk and parsing them again for every single check, on the same single thread that serves everyone signing in. Those files now change only when the underlying state does, so the work happens once per change instead of once per check, and a burst of monitoring traffic no longer takes time away from real requests. Nothing it reports has changed. The freshness timestamps it publishes still come from the underlying data, so a background job that stops running still shows up as stale exactly as before, and a missing file still reports nothing rather than something out of date. See current status

The public transparency check answers faster, and answers the same

September 8, 2026

The transparency document at the well-known address is a signed statement about the state of Obelisk's append-only ledgers, and anyone may fetch it without an account. Until now it was rebuilt and re-signed from scratch for every single request, which made a page anybody can call repeatedly the most expensive thing on the site to ask for. It is now prepared once for each published ledger state and reused until that state actually changes, so it returns quickly and under load no longer competes with the requests of people who are signed in. Nothing about what it says has changed: the signature still covers exactly the ledger facts it always did, the time you fetched it is still stamped fresh on every response, and how recent the underlying ledger state is still comes from the signed statement itself, so an old answer can never be made to look current. If the signing key is replaced, the statement is signed again immediately. Verify it yourself

Prove an agent owns its domain, and pull in its agent card, without leaving the page

September 4, 2026

Two things Obelisk could already do, and that you previously could not reach without writing your own API calls. First, domain control. If an agent belongs to a domain you run, you can now prove it: Obelisk shows you one DNS record to publish, and checks it for you. Publishing that record is the proof — only someone who controls the domain's DNS can do it — so the result is evidence rather than a claim you typed. The record is the same every time for that agent and that domain, so you publish once and can re-check whenever you like, and a verified domain shows the date its evidence runs out. Until you prove one, your agent's page now says plainly that its domain is only declared. Second, agent cards. If your agent publishes a standard agent card, paste the address and Obelisk will fetch it, record what it found, and tell you whether the card was properly signed. It fills in the model, provider and capability fields only where you left them empty — it will never overwrite something you wrote yourself. Alongside these, we removed a page describing where the product was going that had drifted badly out of date in both directions: it listed things as unbuilt that had shipped long ago, and left the newest work unmentioned. The roadmap on this site is generated from what is actually true and is the only one now. Open Agent Studio

Our daily security sweep was stopping early, and we did not notice

September 3, 2026

This one is about us, not about your account, and we would rather write it down than leave it out. Every night Obelisk runs a set of automated checks over its own code: a scan for known-bad or tampered software dependencies, a scan for credentials accidentally committed, a check that our published tamper-evident records still match what we hold, and several checks that our own stated rules are still being enforced. Those checks run one after another. We had built them so that the first one to fail ended the whole run — which means that for the past month, one failing check at the front of the queue was silently preventing every check behind it from running at all. The failing check was a real but minor issue in a file maintained centrally rather than by us, and we could not fix it here without it being overwritten again within hours. The consequence was out of all proportion to the cause: the credential scan, the dependency scan and the tamper check had not produced a result in weeks, and because the step that raises an alarm also sat at the back of that queue, nothing told us. Nothing was found to be wrong once they ran again, and we have no evidence anything was missed — but for that period we could not have known either way, and saying so is the point. Two things changed. Every check now runs to completion and reports its own result regardless of what any other check did, with a single step at the end deciding the outcome; a run that somehow records no results at all is now treated as a failure rather than a pass. And the issue we cannot fix here is now labelled with who owns it and a date it expires, so it is visible and time-limited instead of quietly permanent. How Obelisk proves itself

Invitations now arrive by email, organisations can be deleted, and a sign-in link stays private

September 3, 2026

Three changes, one of them a security correction. First, invitations. When you invited someone to your organisation, Obelisk asked for their email address, stored it, and then never used it — you had to copy the invitation link and send it yourself. That works inside one team and does not work at all when you are inviting someone you have never met. Invitations are now emailed, you can resend one without invalidating the link the recipient may already be holding, and the response tells you honestly whether the message was sent rather than always claiming it was not. Related: if your organisation is not one of ours, its emails no longer go out under our studio's branding — they come from Obelisk, neutrally, which is what an identity provider hosting someone else's organisation should always have done. Second, deleting an organisation, which simply was not possible before: an organisation, once created, was permanent. You can now delete one, as the owner, after confirming with your passkey and typing its name. Deleting frees up your allowance to create another, ends any outstanding invitations, and removes it from every member's list — but the name stays retired rather than being handed to a new organisation, because that name appears in past records and reusing it would silently re-point that history at something else. Third, the correction. Requesting a sign-in link by email had two situations in which Obelisk would hand the link back to whoever asked, instead of only emailing it to the address it belongs to. Neither was reachable in normal use and we have no indication either was used, but on a service where anyone can register an account they would have allowed signing in as someone else. Both are closed: a sign-in link now goes to the mailbox it names and nowhere else. Manage your organisations

Two corrections: your recovery codes, and what a remembered sign-in is allowed to do

September 2, 2026

Two corrections, both found by our own review and both fixed before this note was written. First, recovery codes. A visitor who was not signed in at all could ask Obelisk to regenerate the backup codes for an account they named, which threw away that account's saved codes and showed the visitor a fresh set. Nobody used it, but it was there, and it is closed: regenerating recovery codes now requires the account owner, signed in with a passkey, on every path that can do it. Second, remembered sign-ins. When you tick remember-me, Obelisk keeps you signed in for thirty days at a lower level of proof than a fresh passkey. That lower level was never meant to let you hand out power, but a few actions accepted it anyway: creating an organisation, changing an organisation's registered websites, registering a new connected app, and turning off your own security-alert emails. Each of those now asks for your passkey first, the same way inviting a member or changing organisation settings already did. Deleting your account also now keeps the record that your old sessions were ended, so they cannot be mistaken for live ones afterwards. And if you press back or refresh in the middle of signing in to a connected project, you now land somewhere sensible instead of on a wall of raw text. Review your account security

Our own safety checks can no longer be quietly weakened

September 2, 2026

Obelisk's job is to be checkable, so the checks themselves have to be trustworthy. Some of the files in this project are maintained centrally and copied in automatically on a schedule, which is normally how improvements reach us. But one of those files had also grown a set of checks written specifically for Obelisk — and every automatic copy quietly replaced them. The visible half of that was easy to spot: things stopped working and our tests failed loudly. The dangerous half was invisible. One of our honesty checks — the one that catches a page displaying a blank or broken value where a real number belongs — was replaced by a weaker version that reported success either way. A safeguard had been turned down, and nothing said so. We have fixed the shape of the problem rather than the symptom. Checks that belong to Obelisk now live in files that are ours alone, so a scheduled update cannot reach them, and a new standing check refuses any future attempt to keep our own logic inside a centrally-managed file. We also taught the tool that watches for these updates to notice the case it was blind to: it used to look only for our version drifting ahead, and could not see our version being erased — which is exactly what this looked like. Where a correction genuinely belongs upstream, it has been sent there rather than patched over locally, and it is tracked with a deadline so it cannot be quietly forgotten. Nothing about your account, your agents or your data changed. What changed is that a class of silent weakening now has a loud alarm attached to it. How Obelisk proves itself

Renaming an agent can no longer bring a revoked one back

September 1, 2026

A revoked agent is meant to stay revoked, and there was one way left for that to come undone. When you registered a new agent, Obelisk reused the retired slot of an older one — but it only recognised retirement recorded in the older of the two ways we store it. If an agent had been revoked through the newer path, its record was left in place and the new agent was added beside it, so two different agents briefly shared one internal identifier. From there, an ordinary edit — renaming the new agent, or changing its description — was applied to both, and the revoked one came back to life in your list as a copy of the new one. No one had to do anything unusual to trigger it. That is fixed at the root: the retired slot is now always reclaimed, so two agents can never share an identifier in the first place, and revocation cannot be undone by editing something else. Three smaller corrections ship with it. Obelisk keeps a bounded history of retired agents so that past records stay readable; that limit was only counting half of them, so the history could grow without bound, and it was also unable to tell how long ago half of them were retired, which made "keep the most recent" mean less than it should. Revoking an agent that was already revoked no longer overwrites the date it was originally revoked, and no longer re-notifies connected services about it. And when you leave an organisation, a revoked agent of yours no longer keeps that organisation's name attached to it. None of these changed what your agents can do — they change what Obelisk remembers, and how faithfully. Manage your agents

A revoked agent is now revoked to every part of Obelisk — and a compromised one stops collecting access

September 1, 2026

Last release made revoking an agent final. This one finishes the job in the places that decide, moment to moment, whether an agent counts as one of yours. Obelisk records an agent's status in two ways for historical reasons, and while the parts that answer questions about an agent had been taught to respect both, the parts that build your lists had not. An agent revoked through the newer path could still be found, listed, renamed, re-linked, and given new access — even though every page that described it correctly called it revoked. That gap is closed: there is now a single place in Obelisk that answers "is this agent live", and every list, lookup and edit goes through it. Two consequences you may notice. First, an agent you have marked as compromised can no longer be given anything new — no new repository or service connections, and it can neither become a parent of another agent nor be handed one. Compromise is meant to spread nothing; previously we recorded exactly those links while telling you, on the same screen, that a delegated agent inherits its parent's compromise. Suspending an agent is unaffected, because a suspended agent is simply resting and its resume path is unchanged, and clearing a connection is always allowed — the rules only ever tighten. Second, the agent count on our public statistics page now means what it says: only genuinely active agents, not ones still awaiting their first key, resting, compromised, or revoked. Manage your agents

Revoking an agent now really revokes it — everywhere, and down its whole delegation chain

August 31, 2026

A correction, and an important one. When you revoked an agent, your account page showed it gone and its API keys did stop working — but parts of Obelisk kept treating it as live. An agent whose profile you had made public could still complete a live identity check for a connected project, its public proof page still described it as active, and the signed record Obelisk publishes to other services still listed it. Worse, certain later actions could quietly restore it to your list as though the revocation had never happened. The cause was that a revoked agent was marked in one place and read from another, and the reading side preferred the stale answer. Revocation is now final and is honored by every part of Obelisk that answers questions about an agent — including for agents you revoked before today, which are corrected automatically the next time they are read. Two related gaps close with it. Revoking an agent now also revokes the agents it delegates to, and theirs in turn, along with their keys — which is what the confirmation message always said it would do. And connected projects are now notified the moment you revoke an agent from your account, through the same standard channel used when a person's session ends; previously that notice was only sent from a path most people never used. Separately, a brief hiccup in our storage layer could sign everyone out at once; it is now retried once before anyone is signed out, with no reduction in security. Manage your agents

Agent profiles grow up: profile pages, domain proof, easier editing — and a sign-in annoyance is fixed

August 30, 2026

A fix first. If you ever signed in and were immediately asked to sign in again with your passkey — with a message claiming your session had expired — that was our bug, and it is gone. The "keep me signed in" box was pre-checked, and a remembered session deliberately carries less authority than a fresh passkey sign-in, so the most sensitive pages asked you to confirm again while the screen misdescribed why. The box is now unchecked unless you choose it, the confirmation screen says what it actually is (a quick identity check with your passkey), and it returns you to the page you were on. Sessions kept alive by that checkbox also no longer end an hour early on some sign-in paths. The rest of this release is for AI agents. Every agent you register now has its own profile page: what model and provider it runs on, its version, what it can do, its keys, its verified evidence, and who delegates to whom — each item labeled as declared or verified, never blended into a single score. You can prove an agent speaks for your domain by publishing one DNS record, import an agent's public card from where it runs, rename an agent freely (renaming no longer disrupts its credentials), move it between your organizations, and hand an organization to a new owner or leave one yourself. Organizations can be renamed without breaking any links, members show their names instead of account ids, and agents appear alongside people on the organization roster. When an agent is suspended or marked compromised, every connected project is notified through the same standard channel used when a person's session ends. See what agents get

Deleting your account now ends every connected project's access too — and two more protections

August 28, 2026

A correction first. When you deleted your account, Obelisk removed your identity and ended your sessions, and it told every connected project that your session had ended. But a connected project that had been given a long-lived refresh token could keep exchanging it for new access tokens in your name for up to thirty days after the deletion — the check that issues those tokens never asked whether the account still existed. That is fixed: every refresh is now checked against the live account, a refresh for a deleted account is refused and its token family is ended on the spot, and deleting an account ends every refresh token it ever issued at the moment of deletion. Two smaller protections ship alongside it. Adding a new passkey to an account that already has one now requires that you signed in with a passkey — a session that came from an email link, a code, or a social provider can no longer add a passkey to an account that is already protected by one (an account with no passkey yet can still add its first from any session, so recovery still works). And the account actions that rely on your sign-in cookie — deleting the account, removing a passkey, minting an API key, organization changes — now refuse requests that come from a different origin, including sibling sites on the same domain, which browsers alone do not prevent. Nothing about how you sign in day to day changes. Browse the Help Center

See what your API keys are actually doing, and check our claims yourself

August 27, 2026

Your account now shows what each API key has really been doing — how many calls it made, how many were refused, and which permission was denied — so a key being used by someone else looks different from a key you use every day. If your organization hits its website-scan limit, we now tell you exactly where you stand and when it resets, instead of a flat "try again later". Organizations can see a day-by-day view of the sign-ins they were billed for, and the security worklist that raises your Obelisk Rating now shows your progress, names the single highest-value fix, and is visible to admins rather than owners alone. Your account also lists which outside providers have signed you in. New pages: Verify it yourself collects every independent check you can run against us in one place — and is explicit about what those proofs deliberately do not claim; a Roadmap page gives everything that is coming a dated home; and a Glossary defines the vocabulary we use. Sign-in feedback is clearer throughout: actions show progress, and a failure now says so instead of looking like success. Check it yourself

Every page, every screen size, both themes — measured and fixed

August 25, 2026

We rendered every page a person can reach — the website, the sign-in screens, your account area — on six screen sizes from a small phone to a large monitor, in dark and light, and checked each one the way an accessibility audit would: text contrast, minimum text size, the size of everything you tap, headings and landmarks for screen readers, labels on every control, and errors in the browser console. The light theme was the biggest fix: its blue was slightly too pale on white to meet the contrast standard for links and buttons, so it is deeper now, and the text on blue buttons is readable in both themes including the accent colours you can choose in Preferences. Small text was raised to a readable floor everywhere, menu rows, footer links, tabs and the little help rings are now comfortable to tap on a phone, three developer pages that showed a black circle instead of the Obelisk mark are fixed, and the sign-in page and your account pages now have proper page structure for screen readers. Nothing about how Obelisk works changed — only how clearly it reads and how easily it can be used on whatever you are holding. Browse the Help Center

Signing in from a connected project now returns you there — and can happen without leaving the page

August 25, 2026

If you signed in to a connected project through Obelisk and ended up on your Obelisk account page instead of back at the project, that was a defect on our side and it is fixed. A project's return address could be refused silently by one of three checks that disagreed with each other; the checks now share one source of truth, and when a return address is refused you are told so on the sign-in page instead of being quietly sent home. Social sign-in, email links, and first-time registration all now finish where you started. For projects that would rather not send you away at all, Obelisk now offers three ways to sign in without a full-page redirect: a small pop-up that hands the result back to the page, browser-native account chooser sign-in in Chrome and Edge, and passkey sign-in directly on a registered project's own domain. Each is limited to projects whose addresses are registered with Obelisk. Your account area has also been rebuilt with one consistent menu on every page, a navigation drawer that scrolls properly on phones, a Help section on every screen, and an owner-only area that is never rendered for anyone else. Read the integration guide

Signing out really does end the session now — and a correction about that

August 25, 2026

This release closes a real gap in how sessions ended. Revoking a session, signing out a single device, signing out everywhere, deleting an account, and logging out through a connected project all recorded the session as revoked — and the check that authenticates each request never read that record. Your account page showed the session as gone, and connected projects were correctly told it had ended, but the session token itself kept working until it expired on its own, which for a remembered login could be up to thirty days. A previous entry on this page said that sign-out revokes the server-side session rather than only clearing a browser cookie; that is what we intended and had recorded, but the enforcement was missing, so the statement was not true until today. It is now checked on every authenticated request, and a session whose revocation cannot be confirmed is refused rather than allowed. If you have ever signed out of a shared or lost device, signing out again will now definitively end it. This release also adds rate limiting that actually counts on three public verification endpoints, tightens the isolation boundary between directory-provisioned tenants, and signs the short-lived cookie used during social sign-in so it cannot be forged. Review your sessions and devices

Full agent controls, a prove-it-yourself receipt check, and a truth pass across the site

August 24, 2026

Agent Studio now exposes everything an agent identity can do: suspend or resume, mark compromised and recover with a fresh key, rotate keys, rename, transfer ownership to another account, verify a declared repository binding, and watch a pairing complete live instead of guessing. Each agent shows a claim-by-claim proof meter — the same independent evidence its public proof link shows, never a single score. The security page gained a hands-on check: paste any receipt hash and your own browser recomputes the cryptographic inclusion proof against the published ledger head, so the verdict is your machine's arithmetic, not our word. Under the hood this release also hardened the caching and rate-limit layers after an internal review, made the public proof endpoint dramatically cheaper to serve, and refreshed every page that had drifted from what actually ships — the agents guide, the tool catalogue, the machine-readable site maps, and the navigation. Accessibility preferences now follow you across every signed-in surface, and destructive actions consistently confirm before they act. See what agents can do

The status page now shows exactly which release is serving

August 21, 2026

The public status page now shows the complete release revision and deployment time reported by the running service, with direct links to the independent health response and machine-readable release history. If that bounded build proof is unavailable, the page says so instead of implying certainty. The layout keeps the full value readable on desktop and mobile in both light and dark themes. View live status

AI assistants can now ask Obelisk directly whether something is trustworthy

August 17, 2026

Obelisk now answers trust questions over the Model Context Protocol, the standard way AI assistants call external tools. Any MCP-capable assistant or agent can call three read-only tools: scan a public website and get its security rating, verify whether an access token Obelisk issued is genuine and still valid, and look up an organization's published rating. The endpoint needs no account for these checks, applies the same rate limits and abuse protection as the website's public scanner, and never exposes anything a signed-in page would not show. The tool catalogue is published for discovery, and the machine-readable site index points agents at it. Nothing changed for human sign-in; this makes the checks you could already run on the website available to the software that increasingly does the checking. This release also made routine speed and reliability improvements behind the scenes, with no change to what you see or how you sign in. Read the MCP guide

You can now see your own security history — and every receipt about you

August 17, 2026

Your account page now shows the security events that were previously visible only to us: failed sign-in attempts against your account, authenticator app changes, recovery-code regeneration, username changes, handle claims and releases, and devices you signed out. Each event says where it came from — events written to the tamper-evident chain are labelled as such, and events from the general activity log are labelled separately, so you can tell what is provable from what is merely recorded. The page also tells you how many events it measured but did not show you, rather than quietly leaving them out. Your identity ledger became a full receipts hub: alongside your sign-in chain it now lists your agents' lifecycle events and actions, your API-key grants, and the tokens issued for you to each connected app. It links the published proof head so you can pin today's value and check tomorrow that history was not rewritten, and it no longer states a whole-ledger verification result and your own entry count as if they were one claim. Renaming your account no longer hides your earlier history from you, and the ledger page now honours the theme, accent, and accessibility settings you chose. Separately, apps integrating Obelisk can now receive and verify real-time security events with a single call from the SDK. Open your receipts hub

Security events now reach connected apps in real time

August 16, 2026

When a session is revoked or a credential is added or removed, Obelisk now pushes a signed Security Event Token (the CAEP / Shared Signals model) to each connected app that registered a delivery address, so access ends when it is revoked rather than when a token happens to expire. Apps without a delivery address can collect their queued events from an authenticated poll endpoint. Deliveries are rate-limited, refused for non-public or non-HTTPS destinations, and every attempt is written to the receipt ledger. Separately, a SAML sign-in response can no longer be presented twice, and every newly minted session must state its authentication strength explicitly. Read the security overview

Agent capability use is now recorded in a tamper-evident ledger

August 13, 2026

The record of which agent used which capability, and whether it was allowed, is now written to a hash-chained, lock-protected ledger and checked by the same integrity gates that guard Obelisk's other audit trails. Altering or deleting an entry is detectable. Entries written before this change cannot be verified retroactively, so they are counted and shown as such rather than presented as proven. Read the security overview

Public trust evidence now has one privacy-aware source

August 12, 2026

The new public statistics page and its agent-readable JSON feed now draw from the same five-minute aggregate snapshot, so human and machine views cannot disagree. Small populations are shown as a privacy band instead of a precise count, unavailable measurements stay visibly unavailable, and token activity now carries one passage identifier across usage and issuance evidence for clearer reconstruction. View public evidence

Passkey sign-in keeps authenticator preference, and integrations can acknowledge rollout

August 12, 2026

Username-first passkey sign-in now preserves the authenticator transport hints needed for platform authenticators such as Windows Hello. Obelisk also exposes a verifiable acknowledgement path for connected projects, so rollout status can be proven by signed integration responses instead of inferred from documentation. Review integration options

API key checks now leave a clear verification trail

August 11, 2026

Every API key verification now records whether it passed, failed, expired, or was revoked, and whether the key belongs to a person or an agent. That gives users and operators a stronger audit trail for machine access without exposing the secret key itself. Review account receipts

Registered app changes now ride the release path

August 11, 2026

The release system now carries the app registry that sign-in uses to validate callbacks, so newly registered project URLs reach production with the code that depends on them. That closes a gap where the service could report the right software revision while still using an older registry. Read the app setup guide

Register your own apps, run your organization's sites and team, and protect your agent servers

August 9, 2026

You can now register an application yourself and get a client identifier plus a ready-to-paste configuration, no manual onboarding required — either for your own account or, if you are an administrator, for your organization. Organizations became first-class: one organization owns many websites, each with its own security rating, and members carry owner, admin, or member roles you manage in the account area, with the last owner always protected from removal. And connecting a Model Context Protocol server is now standards-based end to end — authorization responses identify the issuer, and clients can be described by a metadata document — so agent tools can sign in the same trusted way people do. See organizations →

Agent-readable trust paths now come with freshness-aware proof

August 5, 2026

Structured discovery now guides agents to Model Context Protocol integration, organization controls, verification runbooks, and matching human-readable guidance. Release checks can resume without mixing revisions, identity-integrity proof stays aggregate-only and signed, and incomplete or stale evidence remains visibly unmeasured. Explore agent integration →

Public registration is open, with sign-out that really ends the session

August 4, 2026

Anyone can now create an Obelisk account without an invitation while passkey ceremony and request throttles guard the open door. Sign-out now revokes the server-side session instead of only clearing a browser cookie, and standards-based token revocation gives connected projects a reliable way to contain a compromised credential. Create your account →

Our checks now say when they weren't allowed to look

August 3, 2026

One of the safeguards that reviews incoming changes to this service had a rule stopping it from touching work in progress. That rule was quietly also stopping it from examining anything, so it reported "nothing to check" on files it had never opened. Being unable to check something is now its own clearly-labelled result, separate from a clean pass, and it names the files it could not vouch for. A related alarm that no one here could ever act on — the work belongs to another team — now carries an owner and a visible deadline instead of sitting red forever. See how we prove it →

Our monitoring now reports its own blind spots

August 3, 2026

A monitor that cannot reach something used to record that as a fact about the thing it was watching, even when the real problem was the monitor itself. Checks now separate "I could not look" from "there was nothing to see," and a check that has gone quiet for too long counts against our health score instead of being quietly excused. Any deliberate exception is dated, explained, and expires on its own. See how we prove it →

Release history now shows the exact day

August 2, 2026

What's New now shows a full calendar date for every release instead of grouping changes by month. The structured history carries the same exact dates while preserving its month fields for existing integrations. View the structured history

One Gateway toll and a safer project onboarding path

August 1, 2026

Gateway pricing is now one transparent, versioned usage contract: successful interactive sign-ins are passages, while refreshes, retries, recovery, linking, and service activity are free. A new Trust Flight Plan separately records each project's public, private, hybrid, or custom posture and requires real staging, canary, recovery, and acknowledgement evidence before enforcement. See the Gateway toll →

Passport v2 binds every sign-in to a registered project

August 1, 2026

Authorization now rejects unknown clients before showing sign-in, binds callbacks and scopes to each registered project, supports public clients without shared secrets, and requires verified email when a project depends on it. Health and agent-resource metadata are also monitor-friendly. Read the integration contract →

A sturdier mobile experience and safer release path

July 31, 2026

Navigation now stays contained at every screen size, public controls meet a 44-pixel touch target, and contact links remain intact behind edge protections. An isolated staging environment proves the exact release before production, while runtime dependency updates are validated and swapped atomically with rollback to the prior service state. See the release posture →

Release history you — and your agents — can verify

July 31, 2026

What's New now comes from one structured, public-safety-checked source. The same release history is available as JSON, carries stable entry identifiers, and is bound to the revision actually serving it. Open the release document →

Every deployment now proves the code it ships

July 29, 2026

A production release must now have a successful continuous-integration result for the exact revision being deployed. The release boundary rejects missing, stale, malformed, still-running, or failed proof before it changes production. See the resilience posture →

Security evidence now carries its provenance

July 28, 2026

Receipts and integrity evidence now distinguish interactive operators, trusted automation, and runtime environments without guessing. That closes a class of reports that looked authoritative while describing the wrong actor or source. How verification works →

Trust scores now respect evidence strength

July 26, 2026

Security evidence is now weighted by authority and freshness, so a weak or old signal cannot silently carry the same confidence as a current, direct measurement. Explore the trust model →

Safety checks now prove they can catch a defect

July 26, 2026

Critical checks are tested through the same arguments and wiring used in real operation. A check cannot be reported healthy merely because its underlying detector works in isolation. Read the security model →

Production status now follows the revision actually running

July 26, 2026

Deployment-currency signals now compare the code serving production with the intended release, rather than treating unrelated repository files as runtime drift. View status and resilience →

Integrity reports identify the tree they measured

July 26, 2026

Repository security evidence now states whether it measured committed code or a working copy. This prevents an uncommitted local change from being mistaken for production evidence. Review the security posture →

Unknown is no longer reported as healthy

July 26, 2026

When a dependency or identity provider cannot be measured, Obelisk preserves that result as unknown instead of turning missing evidence into a green status. See how status is reported →

The website, brought fully current

July 23, 2026

Sender-bound tokens are now documented for customers and developers, the API manifest covers federation and verification surfaces, every page carries the brand mark, and connector claims derive from one catalogue. Explore the API manifest →

Security alerts, API keys and full account control

July 17, 2026

Your account now includes a security-alert timeline, scoped expiring API keys for agents, security-habit badges, and a direct account-deletion control. Open your account →

Live website roster

July 16, 2026

Organization dashboards now show linked websites with live probe-backed status, response latency, and an uptime sparkline rather than a cached availability claim.

Theme and accessibility preferences that stick

July 15, 2026

Light and dark themes now carry into browser chrome, while higher contrast, reduced motion, larger text, and other accessibility preferences are applied across the product.

Account Shield

July 2, 2026

Every account now has a live security score, tier, trend, sign-in streak, and a concrete next action that can improve its posture.

The verified “Secured by Obelisk Gate” seal

June 28, 2026

Protected sites can embed a live seal that reflects their measured security band and links to a public verification page — proof of protection rather than a static badge. Get the seal →

SAML 2.0 identity provider

June 27, 2026

Obelisk can issue signed Security Assertion Markup Language assertions to downstream applications, making one passkey-first identity usable across compatible business tools. Set it up →

Off-box recovery and a self-healing watchdog

June 25, 2026

Encrypted backups are integrity-checked away from the primary service, and the health watchdog can restart an unhealthy process. The documented total-loss recovery objective is about fifteen minutes. Resilience posture →

Integrations catalogue

June 23, 2026

A single catalogue now shows where Obelisk can serve as the identity provider over OpenID Connect or Security Assertion Markup Language. Browse connectors →

Verify-it-yourself credential transparency

June 18, 2026

Session issuance and passkey changes are recorded in a tamper-evident account log, so you can verify that each sign-in and credential change was yours.

Assurance-bound sessions

June 15, 2026

Sessions carry how identity was proven. Passkey-backed sessions can perform sensitive changes; lower-assurance recovery sessions remain restricted.

The Obelisk Rating, 0–100

June 13, 2026

A live security score distills measured account or organization signals into one rating with visible coverage and improvement levers.

Organizations, teams and website scan

June 11, 2026

Register an organization, invite role-scoped team members, and measure a public website to produce a security rating with concrete improvement levers.

One identity, every project

June 8, 2026

A universal Obelisk account now carries cleanly separated per-project profiles, allowing one passkey-first identity to work across the ecosystem.

Passkey-first usernameless sign-in

May 24, 2026

One-tap, phishing-resistant sign-in works without typing a username, with controlled recovery paths available when needed.

Tamper-evident receipts

May 22, 2026

Consequential identity and authorization actions emit signed, hash-chained receipts so the audit trail cannot be silently rewritten.