{"schema":"obelisk-public-changelog-v1","service":"Obelisk","title":"What's new","updatedOn":"2026-10-27","updatedMonth":"2026-10","servedCommit":"74791feb2fce315560520dff86e0de9ab7e879da","self":"https://obeliskgate.com/changelog?format=json","human":"https://obeliskgate.com/changelog","entries":[{"id":"agent-grants-you-can-read","releasedOn":"2026-10-27","releasedMonth":"2026-10","title":"Approve exactly what an agent may do, in plain words","summary":"An app can now ask for a specific, limited permission for an AI agent — which actions, on which addresses and for how long — instead of a broad scope. Obelisk accepts one fixed format, lists the request on the approval page in plain sentences, never grants it silently, ends the permission when any time limit you approved runs out, and puts exactly what you approved into the agent's access token. We also now ask everyone who used an authenticator app to set it up again after an earlier flaw that could have exposed those secrets; passkeys are unaffected.","category":"security","link":{"href":"https://obeliskgate.com/.well-known/openid-configuration","label":"See the supported request types"}},{"id":"recover-a-lost-passkey","releasedOn":"2026-10-26","releasedMonth":"2026-10","title":"Recover your account when the device with your only passkey is gone","summary":"If you lose the only device that holds your passkey, you can now get back in on your own. Use one of your one-time recovery codes, or ask for an email recovery to your verified address. An email recovery opens only after a 72-hour hold, and we email you a link to cancel it; if you sign in on another device during the hold, your account page shows the request with a cancel button. Either path lets you add a new passkey and nothing else, and every use emails your verified address whatever your alert settings. Recovery codes count only if they were created after you signed in with a passkey, so replace an older set from a passkey session. Signing in with a passkey cancels any pending email recovery. The authorization decision point that scores untrusted content for prompt injection is also now live at /access/v1/evaluation.","category":"security","link":{"href":"https://obeliskgate.com/auth?screen=recovery","label":"Recover an account"}},{"id":"mcp-tool-manifest-pinning","releasedOn":"2026-10-25","releasedMonth":"2026-10","title":"Pin the tools of an MCP server before your agent trusts them","summary":"Our MCP server has a new read-only tool, pin_tool_manifest. Give it the tools another MCP server lists and it returns a digest for each tool and for the whole set, flags hidden Unicode text a reviewer cannot see, and reports an injection signal. Send back the digests you stored at approval and it names any tool that changed, appeared or disappeared, so a tool quietly rewritten after you approved it is caught before the call. The server now speaks MCP 2026-07-28 and still answers older clients, publishes its own catalogue digest so you can pin us too, and refuses a request whose Mcp-Method or Mcp-Name header disagrees with its body. The Security page now maps our controls to the OWASP Top 10 for agentic applications, including the risks we do not cover.","category":"security","link":{"href":"https://obeliskgate.com/security#agentic","label":"See the OWASP mapping"}},{"id":"saml-sign-in-refuses-a-document-type-declaration","releasedOn":"2026-10-22","releasedMonth":"2026-10","title":"SAML sign-in refuses a response that declares a document type","summary":"When your organisation signs in to Obelisk through SAML, we now refuse any response that carries a document type declaration or an entity declaration, before any part of it is read. No SAML identity provider needs to send one, and a response is read twice, once to check its signature and once to find who is signing in; refusing these declarations means those two reads never depend on how they would be interpreted. We also moved to the current release of the XML signature library we use, which includes fixes to how signed XML is canonicalized.","category":"security","link":{"href":"https://obeliskgate.com/security","label":"How we protect sign-in"}},{"id":"post-quantum-signature-on-the-tree-head","releasedOn":"2026-10-20","releasedMonth":"2026-10","title":"The transparency tree head now carries a post-quantum signature","summary":"The tree head we publish now carries a second signature made with ML-DSA-65 (RFC 9964, FIPS 204), beside the existing ES256 signature and in a separate field, so a verifier that checks only ES256 keeps working unchanged. The ML-DSA public key is published in the same key set as the ES256 key. Sign-in tokens are not post-quantum signed. Our release check verifies the live post-quantum signature before a release and confirms that a head changed after signing is refused.","category":"security","link":{"href":"https://obeliskgate.com/security#crypto","label":"See the cryptography"}},{"id":"every-page-says-what-obelisk-does-today","releasedOn":"2026-10-18","releasedMonth":"2026-10","title":"Every page now says only what Obelisk does today","summary":"We reviewed all 40 public pages and corrected what overstated the service: post-quantum signing is described as deployed but not yet producing signatures, the FAQ no longer says every sign-in leaves a receipt, the authenticator-code answer now says a code sign-in gives a limited session, and comparisons with other providers are dated and sourced or say plainly what we did not find. The MCP page now shows a request you can copy and the protocol revision it speaks, and the FAQ answers how to export or delete your account.","category":"documentation","link":{"href":"https://obeliskgate.com/help/faq","label":"Read the FAQ"}},{"id":"each-sign-in-step-signs-with-its-own-key","releasedOn":"2026-10-15","releasedMonth":"2026-10","title":"Each step of signing in now uses its own key","summary":"While you sign in, the Gate keeps a small signed note in your browser so the next step can check it started the process. Organization invitations, sign-in with Google or GitHub, and company single sign-on each keep one. They all used the same key, and an invitation note can be made to say almost anything, so an invitation link could have been turned into a note the other two would accept. Sign-in with Google, GitHub and company single sign-on are not switched on here yet, so this could not have been used against anyone. Each note now has its own key, and an automated check refuses any new one that shares a key. If you were part-way through accepting an invitation when this went out, open the link again.","category":"security","link":{"href":"https://obeliskgate.com/auth?screen=signin","label":"Sign in"}},{"id":"sign-in-no-longer-reveals-which-accounts-exist","releasedOn":"2026-10-15","releasedMonth":"2026-10","title":"The sign-in page no longer tells anyone whether an account name exists","summary":"When you type an account name to sign in, your browser asks the Gate which passkeys belong to it. Until now a name with no account got back an empty answer and a real name got its passkeys, so anyone could find out, one name at a time, which accounts exist. That check was rate-limited but it worked. A name with no account, or one whose passkeys have all been removed, now gets back a believable answer that can never be used to sign in, so the two cases look the same. Nothing changes when you sign in with your own passkey. If you mistype your name, your browser will now say it has no passkey for this site, rather than offering every passkey it holds and failing afterwards. One limit remains: an account with two or more passkeys can still be told apart from one with none. Signing up still says when a name is taken, because it has to. While reviewing this change we also tightened the check every signed-in request goes through, so that only a genuine sign-in session is ever accepted as one.","category":"security","link":{"href":"https://obeliskgate.com/auth?screen=signin","label":"Sign in"}},{"id":"account-separation-checked-before-each-release","releasedOn":"2026-10-13","releasedMonth":"2026-10","title":"Account separation is now checked automatically before each release","summary":"The review behind yesterday’s security fix is now a permanent, automated check that runs before every release and stops the release if one account’s data could reach another. It found nothing new. We also made a smaller fix: a passkey you add from your account page now remembers how your device reaches it, so the right prompt is offered the next time you sign in.","category":"security","link":{"href":"https://obeliskgate.com/account","label":"Your account"}},{"id":"one-account-on-every-device","releasedOn":"2026-10-12","releasedMonth":"2026-10","title":"One account on your phone, tablet and laptop — and the account page now says which passkeys follow you","summary":"We checked what happens when you use one Obelisk account on more than one device, and fixed what got in the way. Your account page now says, for each passkey, whether it is synced by your password manager to your other devices, can sync but is not backed up yet, or stays on the device that created it. That is the passkey’s own report, which we show and do not rely on for anything. New passkeys are named after the browser and system they were made on instead of all being called “Passkey”. If you sign in on a new device and tick “Keep me signed in”, or come in by email link or authenticator code, the account page used to answer “Could not start. Try again.” when you tried to add a passkey there. The rule behind that has not changed, and it should not: a session that lasts thirty days, or that could be phished, cannot change how you sign in. The page now says so and offers a button to confirm with your passkey, after which adding one works. The “My passkey is on another device” button now asks your browser for the phone-and-QR-code option directly. Your display choices — light or dark, high contrast, larger text, reduced motion — are saved to your account as before. On each device the sign-in page now picks all of them up, and the public site your light or dark theme, after you next open a signed-in page there. Confirming with your passkey gives you a normal-length session in place of the thirty-day one. Behind the scenes, each account now has one stable identifier for passkeys instead of a new one on every request, so when you make a new passkey your password manager can replace an old one for the same account rather than keep a dead entry beside it. A passkey you only remove here still has to be deleted from your password manager by hand. One thing is still not solved, and our help pages say so: if your only passkey lives on one device and that device is lost, there is no self-service way back in, so add a second passkey or use one that syncs. Two older faults were found while this work was reviewed and are fixed with it. After signing in, a specially built link could send you on to another website; it can no longer leave Obelisk. And an account name whose record held details but no passkey could be registered by someone else, who would then have held that record; a name is now free only if nothing at all is stored under it.","category":"identity","link":{"href":"https://obeliskgate.com/help/faq#newdevice","label":"Sign in on a new device"}},{"id":"authenticator-secret-exposure-closed","releasedOn":"2026-10-12","releasedMonth":"2026-10","title":"We closed a hole that exposed authenticator-app secrets","summary":"This is a security fix, and you should know what it was. One address on the Gate, left over from early development and used by no page, would give anyone who asked the authenticator-app secret of any account they could name. No sign-in was needed. An authenticator-app secret is what generates the six-digit codes, so someone holding it could produce valid codes for that account. On this Gate a code alone gives a limited session: it can view the account, but it cannot add or remove a passkey, change the account name, or delete the account. Passkeys were not exposed and cannot be read this way. The same address could also start authenticator setup on an account that had none, which changed nothing a person could use but should never have been possible. We found it ourselves, in a review that requested every address on the Gate as someone other than the owner. It is closed: the secret is now shown only to the account’s owner, signed in with their passkey. We have no record that it was used, and we cannot rule it out, because the address did not log who called it. If you use an authenticator app with Obelisk, remove it and set it up again from your account page; that replaces the secret. In the same release, every page and download that is about one person or one organization now tells browsers and networks never to store it, and on a phone or tablet the lists of links in our help, legal, API and comparison pages are full-height rows that are easy to tap.","category":"security","link":{"href":"https://obeliskgate.com/account","label":"Your account"}},{"id":"one-tap-size-rule-and-a-log-that-fails-closed","releasedOn":"2026-10-12","releasedMonth":"2026-10","title":"One rule for tap sizes, and a tamper log that no longer reads damage as empty","summary":"Yesterday’s fix to the sign-in links showed that two of our own checks disagreed about how big a tappable control must be on a phone. They now share one rule, the stricter of the two: 44 pixels in both directions, measured with the page at rest. Run across every page, that rule found a handful more. On the home page the button that copies the signed ledger head was squeezed to 29 pixels wide on a phone; it is full size now. A contact link on the About page, the data link on the Stats page and one settings toggle were each a little short and are fixed. Small labels on the home page were under 12 pixels and are now 12, and the source links on our Auth0 comparison were too faint in the light theme. Lists of links, such as the help index, are still judged by an older and looser standard; we have not decided whether those rows should grow on a phone. Behind the service, one fix matters more than the rest. The log of signed ledger heads exists so that a rewritten history shows. Our check read a damaged or cut-short line in that log the same way as a log that had not been started, and reported nothing wrong. It now treats a line it cannot read as a break and raises the alarm. We also found two internal alarms that reported “all clear” when their measurement had not actually run, and they now say so instead.","category":"security","link":{"href":"https://obeliskgate.com/proof","label":"Verify it yourself"}},{"id":"sign-in-links-easier-to-tap-and-a-claim-we-missed","releasedOn":"2026-10-11","releasedMonth":"2026-10","title":"Sign-in links are easier to tap, and a claim we said we had removed","summary":"A correction first. On 10 October we wrote that the sign-in page no longer calls itself post-quantum migration-ready. That was true of the line at the foot of the page and not of a small label near the top, which kept saying it in five languages. The label is gone now. The reason is unchanged: the quantum-resistant signer is written and deployed but produces no signature on this host. On a phone, six small links on the sign-in screens were only as tall as their text: “Create your account”, “Not now”, “All sign-in options”, “Manage your account”, “Why am I seeing this?” and the contact link on the recovery screen. Each now has a full-size tap area and nothing on the page moved. Our own check had reported one of the six, because it only ever loaded the first sign-in screen; it now loads the others too. Three smaller fixes on the same screens: the button on the create-account screen says “Create your passkey” instead of “Sign in with passkey”, the button that confirms a sensitive action says “Verify with passkey”, and the contact link on the recovery screen is readable in the dark theme. Behind the service, four more of our maintenance tools, including the one that releases new versions, now stop on an option they do not recognise.","category":"product","link":{"href":"https://obeliskgate.com/auth","label":"Sign in"}},{"id":"our-maintenance-tools-refuse-a-mistyped-command","releasedOn":"2026-10-11","releasedMonth":"2026-10","title":"Our maintenance tools now refuse a mistyped command","summary":"Nothing you see or sign in with changed in this release. Behind the service, the tools we use to back up the Gate, replay usage records for billing and run our scheduled checks used to ignore an option they did not recognise and carry on. A mistyped “show me, don’t do it” could therefore have run for real. Eight more of those tools now stop and say which option they did not understand before they read or change anything. We also added two checks on our own housekeeping: one lists every internal tool that nothing runs automatically, so each is either explained or removed, and one stops our internal notes from describing a deployment as pending after it has finished.","category":"security","link":{"href":"https://obeliskgate.com/security","label":"How we run the Gate"}},{"id":"anyone-can-create-an-account","releasedOn":"2026-10-10","releasedMonth":"2026-10","title":"Anyone can create an account, and the home page says who Obelisk is for","summary":"Creating an account no longer needs an invitation. Sign-up is open, and every sign-up now has to pass a bot check before it reaches us. The home page is sorted by who you are: sign in with a passkey, add sign-in to your app, or bring a team — each with the one next step that actually works today. Developers see the price in the open: the first 10,000 sign-ins each month are free, then per sign-in, with no per-seat fee. Links shared from Obelisk now unfurl with a real preview image instead of a blank card, and every page carries a plain description of what is on it.","category":"product","link":{"href":"https://obeliskgate.com/help/faq#create","label":"How sign-up works"}},{"id":"what-we-do-not-have-yet","releasedOn":"2026-10-10","releasedMonth":"2026-10","title":"What we don't have yet, in writing","summary":"Our trust page now ends with the things Obelisk does not have. We hold no SOC 2 or ISO 27001 certification, no independent security firm has tested the Gate, there is no paid bug bounty, the Gate runs on a single server with no uptime guarantee, and SAML applications cannot be connected to the hosted Gate yet. If one of those is a requirement for you, it is better found on this page than in procurement. We also removed three statements that promised more than the service does: the sign-in page no longer calls itself post-quantum migration-ready, because the quantum-resistant signer is written and deployed but produces no signature on this host; our sender-bound token section no longer says a stolen token is simply inert, because the protection is opt-in per request and a token issued without a proof is an ordinary one; and our glossary no longer says a weaker sign-in can never perform a sensitive action, because a break-glass recovery session can. The agent capability preview on our MCP page now shows our published risk weights and says plainly that it is an illustration, not a decision — the real verdict comes from the policy engine when a request is made.","category":"security","link":{"href":"https://obeliskgate.com/trust#gaps","label":"Read what we don't have yet"}},{"id":"your-usage-page-now-says-what-we-actually-do","releasedOn":"2026-10-10","releasedMonth":"2026-10","title":"Your usage page now says what actually happens at the limit","summary":"If an account without billing set up passed its monthly sign-in limit, the account page called it “now metered” — which reads as “still working, now billable.” That was the opposite of the truth: new sign-ins to that account's apps are refused, and the app's token request gets an HTTP 402 error, until billing is added or the next month begins. The page now says so plainly, tells you which of your accounts it applies to, and no longer claims usage above the free tier is metered unless there is a payment method. The pricing page always described this correctly; the page you would actually open did not. We also corrected an off-by-one that showed the grace band for one sign-in longer than the Gate allowed.","category":"product","link":{"href":"https://obeliskgate.com/pricing#limit","label":"What happens above the free tier"}},{"id":"five-claims-we-corrected","releasedOn":"2026-10-10","releasedMonth":"2026-10","title":"Five things we used to say, and what they say now","summary":"Before this, five statements on our pages claimed more than the service does, and we changed them without saying so. Putting that right. Our integration pages listed SAML as ready across ten places, which read as \"connect your SAML app today\" — SAML apps such as GitHub, Google Workspace, AWS, Slack, and Atlassian can't be connected on the hosted Gate yet; it is built, and connecting it on the hosted Gate is still on the roadmap. Our comparison page sold a live security Rating \"on the login\"; the Rating is a live, public security score for the Gate itself, not a score attached to each sign-in. We said a project using Obelisk holds zero secrets: A public (PKCE) client holds no client secret at all; a confidential client holds one client secret, shown to you once, of which Obelisk keeps only a SHA-256 hash. We said agents authenticate on their own, where in fact autonomous tools act with scoped OAuth tokens that act for a person who signed in, so a person is always behind the grant. And we described apps as storing no credentials without saying what they do receive: Your app stores no user credentials: it receives a signed ID token describing the person, not a password, passkey or authenticator secret. Our trust page also still claims that signing in through another provider inherits the same phishing resistance, and that there is one audited front door; both are being re-measured and the page will say what we find.","category":"security","link":{"href":"https://obeliskgate.com/compare","label":"See what we compare"}},{"id":"one-clear-seal-across-obelisk","releasedOn":"2026-10-06","releasedMonth":"2026-10","title":"One clear seal across Obelisk","summary":"The double-ring seal now appears consistently across Obelisk. A simpler small icon keeps the obelisk and its surrounding circle clear at favicon sizes.","category":"product","link":{"href":"https://obeliskgate.com/about","label":"About Obelisk"}},{"id":"our-help-pages-now-match-what-the-sign-in-does","releasedOn":"2026-10-04","releasedMonth":"2026-10","title":"Our help pages now match what sign-in actually does","summary":"We checked every page against the code behind it and found places that still promised more than they deliver. The help center told you to sign in with a recovery code after losing a device; this Gate does not accept recovery codes for sign-in, so the lost-device answer now says what works: a second passkey on another device, a limited session from an emailed link, and contacting us when neither is available. The sign-in menu's \"Use a recovery code\" option is now \"Lost your passkey?\", the home page no longer says you can never be locked out, and our trust page calls the audit log tamper-evident rather than one that \"can't lie\". An invite link that was already used, has expired or was withdrawn now says so on the sign-up page. Our privacy policy now says that our rate limiters hold your IP address in memory only while it counts toward a limit or a lockout (they now drop it after that), and that our audit records keep a hash of it. A completed second-step pass now stays spent even across a service restart. Your account shield no longer awards points for recovery codes the Gate cannot yet accept; those points now go to a backup passkey, the recovery that works. Public agent profiles now refuse claims of KYC, AML or guaranteed payments in their name, purpose, description and lifecycle notes, including hyphenated, spaced-out, punctuated and look-alike spellings (a guard that matches phrases, so we keep extending it). Our security and about pages, and the machine-readable manifest we publish for agents, no longer present the Gate's own disaster recovery as your way back in, and an invite link we cannot read now says so.","category":"security","link":{"href":"https://obeliskgate.com/help/faq#lost","label":"Read the lost-device answer"}},{"id":"a-launch-checklist-that-measures","releasedOn":"2026-10-03","releasedMonth":"2026-10","title":"A launch checklist that ticks only what we measured","summary":"Your account page now shows the path from a new account to a live app: a passkey, a second passkey (which you keep on another device), your first registered app, the first real sign-in through it, a payment method while billing is on, and a teammate. Each step is ticked only when the Gate has measured it, such as an actual sign-in through your app this month, and a step we cannot measure on this Gate says so instead of guessing.","category":"product","link":{"href":"https://obeliskgate.com/account#launch","label":"Open your checklist"}},{"id":"sign-up-is-one-step","releasedOn":"2026-10-03","releasedMonth":"2026-10","title":"Signing up is one step: create a passkey and you are in","summary":"Creating an account used to walk you through four screens: a passkey, an authenticator app, then typing back one of your recovery codes. Only the passkey was ever needed, and this Gate does not yet accept recovery codes for signing in. Now you create a passkey and you are in. Adding an authenticator app is one click away in your account, and the welcome screen suggests the backup that actually works: a passkey on a second device. While sign-up is by invitation, the sign-up page now says so before you start, with a link to request access, instead of failing after the click.","category":"product","link":{"href":"https://obeliskgate.com/help/faq#create","label":"How sign-up works"}},{"id":"a-new-device-finishes-its-second-step-first","releasedOn":"2026-10-03","releasedMonth":"2026-10","title":"A new device finishes its second step before you are signed in","summary":"If you set up an authenticator app, signing in with a passkey on a device we have not seen before asks for a code from that app. The sign-in page asked for the code, but you were already signed in behind it, so closing the page left a fully signed-in session; and an app you were signing in to could receive that session before the code was asked for. Now nothing is signed in until the code is entered: the passkey step hands back a five-minute pass that only a fresh authenticator code can complete, and a completed pass cannot be reused. Accounts without an authenticator app sign in with the passkey alone, as before.","category":"security","link":{"href":"https://obeliskgate.com/trust","label":"How sign-in is protected"}},{"id":"authenticator-codes-work-once","releasedOn":"2026-10-03","releasedMonth":"2026-10","title":"Authenticator codes now work once","summary":"A six-digit code from your authenticator app could be used again for about a minute and a half after it was accepted. Someone who saw a code over your shoulder, or captured it on a fake page, could reuse it in that time. Each code is now accepted once: the next sign-in or confirmation needs the next code. This follows the TOTP standard (RFC 6238), which says a verifier must not accept the same code twice.","category":"security","link":{"href":"https://obeliskgate.com/security","label":"Security details"}},{"id":"a-way-to-ask-for-access","releasedOn":"2026-10-03","releasedMonth":"2026-10","title":"A way to ask for access, and invites that belong to one person","summary":"While sign-up is by invitation, the sign-in page said so and stopped there. It now links to a short request form that reaches our team. Invitations can now be personal: each one works once, expires, and can be withdrawn on its own, instead of one shared invite code that everyone used. When an invitation has already been used, has expired or was withdrawn, the sign-up page says which.","category":"product","link":{"href":"https://obeliskgate.com/contact?topic=access","label":"Request access"}},{"id":"our-privacy-policy-names-who-processes-your-data","releasedOn":"2026-10-03","releasedMonth":"2026-10","title":"Our privacy policy names who processes your data","summary":"The privacy policy now lists the service providers that process personal data for us, and what each one handles: Hetzner hosts our servers, Cloudflare runs our bot check and stores our encrypted backups, Brevo delivers our sign-in and invite emails, and Stripe handles billing. It also says what we do with your IP address: our rate limiters hold it in memory only, while it counts toward a limit or a lockout, and our audit records store a hash of it instead of the address. The privacy and terms links that browsers show in their built-in sign-in dialog pointed to pages that did not exist; they now open the real policies. The terms now name the company you are agreeing with.","category":"transparency","link":{"href":"https://obeliskgate.com/legal/privacy#subprocessors","label":"See the subprocessors"}},{"id":"buttons-that-match-the-door","releasedOn":"2026-10-03","releasedMonth":"2026-10","title":"Buttons that match the door","summary":"While new accounts are by invitation, several of our pages still said \"Create your account\" and sent you to a sign-in page that then told you sign-up was invite-only. The app portal showed a registration form that could not save, and the Teams page promised a working app ID from that form. Every one of those buttons now follows what the service actually allows: \"Create your account\" when sign-up is open, \"Request an invite\" when it is by invitation, and \"Sign in\" otherwise. The app portal and the Teams page say that new app registrations are on request while self-service registration is switched off, and how to ask.","category":"product","link":{"href":"https://obeliskgate.com/contact?topic=access","label":"Request an invite"}},{"id":"what-gets-you-back-in-after-a-lost-device","releasedOn":"2026-10-03","releasedMonth":"2026-10","title":"What gets you back in after a lost device, stated plainly","summary":"Our pages promised a \"never-lockout guarantee\" with three layers. Those layers protect the service itself: a resilient backend, an operator recovery path and encrypted off-site backups. They are not something you can use to get back into your own account. For you, the recovery that works on its own is a second passkey on another device. An emailed sign-in link or an authenticator code gives you a limited session that cannot add a passkey to an account that still has one. The sign-in page also offered a recovery-code option that our server did not answer. We removed the guarantee from every page and replaced it with what you actually get, and we say that recovery beyond these paths is case by case. Add a passkey on a second device today if you have not.","category":"security","link":{"href":"https://obeliskgate.com/trust#never-lockout","label":"Plan for a lost device"}},{"id":"a-seal-that-checks-where-it-is","releasedOn":"2026-10-03","releasedMonth":"2026-10","title":"A seal that checks where it is","summary":"The \"Secured by Obelisk Gate\" seal used to show its check marks on any page that embedded it, even for a site name that was never registered with us. A lookalike page could borrow a real site's seal. Now the seal shows a check mark only for a site that is registered with Obelisk Gate and can complete a sign-in, and only when your browser reports that the page showing it is at one of that site's registered addresses. Anywhere else it says plainly that it is not verified, or that it is on the wrong site. The seal's verification page also stopped showing a rating that was really Obelisk Gate's own rather than the site's: it now lists what we actually read about that site's registration, and says \"not measured\" where we have measured nothing.","category":"security","link":{"href":"https://obeliskgate.com/developers/seal","label":"How the seal works"}},{"id":"verifying-an-agent-run-means-checking-a-signature","releasedOn":"2026-10-03","releasedMonth":"2026-10","title":"Verifying an agent's run now means checking a signature","summary":"Our public tool for verifying an agent's run proof accepted a proof that anyone could assemble by hand, and reported it as verified. It now verifies only a run token that Obelisk itself signed: it checks the signature against our published keys, confirms the named agent is still active with the same key that answered the run challenge, and never reports a hand-built proof as verified. Run proofs also commit to their inputs and outputs with a random value mixed in, so a short or guessable output can no longer be worked out from its commitment. Separately, API keys issued for an agent that has enrolled its own key are now bound to that key: the key string alone is not enough, and the key stops working while the agent is suspended or revoked. Keys for agents are issued from the agent's card in Agent Studio, each carrying the one scope you name; a key valid for any scope is issued only when you ask for one explicitly.","category":"security","link":{"href":"https://obeliskgate.com/agents","label":"Agents on Obelisk"}},{"id":"self-registered-apps-cannot-borrow-another-apps-audience","releasedOn":"2026-10-03","releasedMonth":"2026-10","title":"Self-registered apps can no longer ask for another app's tokens","summary":"An app can register itself with Obelisk by publishing a small metadata document on its own website. Such an app could previously ask for an access token addressed to a different app. That request is now refused. A self-registered app also can no longer complete a silent sign-in for someone until that person has approved it on screen at least once, and the approval screen names the website that published the app's document next to the name the app chose for itself.","category":"security","link":{"href":"https://obeliskgate.com/developers","label":"Integrate Obelisk"}},{"id":"billing-matches-the-published-contract","releasedOn":"2026-10-03","releasedMonth":"2026-10","title":"Billing now matches what our pricing page promised","summary":"Our pricing has always said that token refreshes and silent re-checks inside a live session are free, and that you are billed only for a real authentication. The meter did not yet tell those apart, so a silent re-check of an existing session was counted the same as a sign-in. It now records how each sign-in was completed and bills only the ones the pricing contract bills, and if you can see your organization's usage, billed and not-billed sign-ins are now shown separately. The published prices did not change.","category":"billing","link":{"href":"https://obeliskgate.com/pricing","label":"See the pricing page"}},{"id":"the-status-page-says-what-was-measured","releasedOn":"2026-10-03","releasedMonth":"2026-10","title":"The status page now separates targets from measurements","summary":"Our status page described recovery, and copies of our audit history kept off this server, as if they were already in place and proven. It now separates the two: each recovery objective sits next to what has actually been measured on this server, and it says \"not yet measured\" wherever no restore drill or verified off-server copy is on record. The transparency panel also no longer says our published chain heads work like Certificate Transparency's log. Ours are anchored heads linked in a hash chain; that is useful, but it is not a Merkle tree with consistency proofs, so the panel now says what it is. An earlier note of ours made the same comparison, and this replaces it.","category":"transparency","link":{"href":"https://obeliskgate.com/status","label":"See the status page"}},{"id":"less-motion-at-rest","releasedOn":"2026-10-03","releasedMonth":"2026-10","title":"Pages that hold still","summary":"The site moved constantly: dozens of looping animations ran on the home page while nothing was happening. Pages now hold still at rest, with at most two looping animations on any page, and motion is kept for moments when something changes. If your device asks for reduced motion, the pages honour it. The colours were also tidied into one accent and one set of surfaces, so the site reads the same on every page in light and dark.","category":"product","link":{"href":"https://obeliskgate.com/","label":"Home"}},{"id":"finishing-the-what-is-signed-correction","releasedOn":"2026-10-02","releasedMonth":"2026-10","title":"Finishing the correction about what is signed","summary":"On 30 September we wrote that every page now described our receipts accurately: hash-chained, with only the head of the chain signed. That was not yet true. Sixteen sentences on the home page, pricing, the comparison pages, the agents, security and help pages still described a receipt as if it carried its own signature, and so did a label on the sign-in page in all five of its languages, because the check we had added recognised only two ways of phrasing the claim. Those sentences now say what we can measure: each receipt is hash-chained to the one before it, and the head of that chain is signed. The pricing page also no longer says your invoice is verifiable; it says what is true today, that each billable sign-in is recorded as a hash-chained receipt carrying its own identifier, so a rewritten charge breaks the chain. The check now reads every page our sitemap lists, as a visitor receives it, and fails on any phrasing of the old claim. Nothing about the service changed in this release: no receipt, key, proof or price behaves differently.","category":"transparency","link":{"href":"https://obeliskgate.com/security","label":"Cryptography reference"}},{"id":"a-correction-to-our-correction","releasedOn":"2026-10-02","releasedMonth":"2026-10","title":"A correction to our correction","summary":"On 29 September we corrected how this site described our risk engine, and that correction was itself wrong. It said sign-ins are scored in real time and resolve to one of three verdicts, and that a second engine with eleven dimensions governs actions taken by agents and tools. This time we ran both instead of reading their code. The sign-in score is computed only to be shown to you on your account page, and nothing acts on it. The second engine was not consulted by any request our service answered. It now scores a capability grant at the moment one is minted, but it only records that score next to the grant: it allows or refuses nothing. So neither one decides anything today, and no page should have said they did. What does decide is simpler, and we tested it route by route: sensitive changes need a passkey sign-in. Adding another passkey or removing one, changing your authenticator or recovery codes, minting an API key, registering an agent, and renaming or deleting your account are all refused to a remembered session, an authenticator-code sign-in or an email-link sign-in until you sign in with your passkey again. Every page that described a risk engine now says that instead, the comparison pages answer the risk-engine question with a plain no, and the pricing page no longer counts a fraud or risk engine among the tools the toll replaces. Nothing about the service changed in this release; the descriptions now match what we measured.","category":"transparency","link":{"href":"https://obeliskgate.com/compare","label":"See the comparisons"}},{"id":"corrected-competitor-prices","releasedOn":"2026-10-02","releasedMonth":"2026-10","title":"Corrected competitor prices on our pricing page","summary":"Our pricing calculator compared the Gate Toll with Auth0 and Clerk using list prices we had not re-checked, and both were wrong. For a 50,000-user app it showed Auth0 at about $1,150 a month; Auth0's published B2C Essentials price at that size is $3,500. It showed Clerk at about $825; Clerk's free plan now covers 50,000 retained users, so the right figure is $0. We also said per-user pricing bills for accounts that never sign in. Monthly-active-user pricing counts only people who sign in that month, so that was wrong too, and we have removed it. The calculator now includes WorkOS, which is free to a million users, links each vendor's pricing page, shows the date we checked it, and compares three app sizes. At 50,000 users the Gate Toll costs less than half of Auth0's list price, and more than Clerk or WorkOS. Our release check now compares every figure with the vendor's live pricing page.","category":"transparency","link":{"href":"https://obeliskgate.com/pricing","label":"See the pricing page"}},{"id":"corrected-our-comparison-pages-on-agent-identity","releasedOn":"2026-10-02","releasedMonth":"2026-10","title":"Corrected our comparison pages on agent identity","summary":"Our comparison pages said Okta, Auth0, Clerk, WorkOS and Stytch did not treat AI agents as first-class identities. That was wrong: Okta's Agent SSO, generally available since August 2026, registers agents as first-class identities, and Microsoft Entra Agent ID is generally available too. We also said no other identity provider gives agents an inspectable identity of their own, which nobody could check, and we set \"zero project-side secrets\" against other providers' client secrets, although a confidential Obelisk client holds a client secret too. All three claims are gone. The comparison now covers Microsoft Entra Agent ID, Descope and Keycard, every agent row links the vendor page it is drawn from and the date we checked it, and it says plainly that Obelisk does not issue tokens to agents yet. Our release check now re-reads every cited page.","category":"transparency","link":{"href":"https://obeliskgate.com/compare","label":"See the comparison"}},{"id":"the-obelisk-sdk-is-public","releasedOn":"2026-10-01","releasedMonth":"2026-10","title":"The Obelisk SDK is public on npm and PyPI","summary":"You can now install the Obelisk SDK from the public registries: npm install @obeliskgate/obelisk-auth for JavaScript, and pip install obelisk-auth for Python. Both are version 1.0.0. Until now our developer page offered the JavaScript package as a private beta you had to ask for.","category":"product","link":{"href":"https://obeliskgate.com/developers#sdk","label":"Install the SDK"}},{"id":"a-post-quantum-signer-that-is-built-and-waiting","releasedOn":"2026-09-30","releasedMonth":"2026-09","title":"A post-quantum signer, built and waiting on the server","summary":"Earlier today we corrected a note that said our post-quantum work was further along than it was: what existed was the space a second signature goes into, with nothing behind it. That gap is now filled. There is a real signer, written against the published standard for post-quantum signatures in this format (RFC 9964, using the algorithm NIST standardised as ML-DSA), and it signs the head of our receipt chain alongside the existing signature rather than replacing it — so nothing you verify today changes. It is deployed, and it is not yet producing signatures, for a reason worth stating plainly: the algorithm needs a newer version of the underlying runtime than our server currently runs. Until that server is moved, the capability sits there unused. We could have described this as \"post-quantum ready\" and left it at that; instead the release check now measures the live site on every deploy and reports, in as many words, that the signer is deployed and inert — so the day the server moves, the claim changes because something was measured, not because someone remembered to update a page.","category":"security","link":{"href":"https://obeliskgate.com/security","label":"Cryptography reference"}},{"id":"what-is-signed-and-what-is-hashed","releasedOn":"2026-09-30","releasedMonth":"2026-09","title":"Being exact about what is signed","summary":"Nine places on this site told you that every receipt we issue is signed, and the cryptography reference named Ed25519 as the algorithm. We checked the receipts themselves: all 16,965 of them are hash-chained, each one committing to the one before it, and none of them carries an individual signature. So that wording was wrong in two ways — the algorithm was misnamed, and the thing being signed was not the receipt. What is actually signed is the head of the chain: the current root is signed with ES256 using the same key you can fetch from our published key set, and a receipt is tied to that signed root by the inclusion proof you can already request for any receipt. That is the same design certificate transparency uses, and it is a stronger guarantee than the one we were describing, because it means you do not have to trust us about a single receipt in isolation — you check it against a root we have signed and cannot quietly change. Every page now says that instead. Separately, the note we published yesterday said our post-quantum hybrid signer was built and tested. Read again, that was still too generous: what is built and tested is the space the second signature goes into, along with the plumbing to accept one, and no post-quantum algorithm is wired up behind it yet. The pages now say that too. Nothing about the service changed in this release — no receipt, key, proof or page behaves differently. What changed is that the descriptions match what we could actually measure.","category":"transparency","link":{"href":"https://obeliskgate.com/security","label":"Cryptography reference"}},{"id":"a-faster-first-tap-on-the-sign-in-page","releasedOn":"2026-09-29","releasedMonth":"2026-09","title":"A faster sign-in page","summary":"The sign-in page was slower to answer a tap than our own responsiveness budget allows, on wider screens especially, and two things were behind it. First: if you have a passkey, the page offers it through your browser's autofill, and preparing that offer was starting while the page was still loading — so an immediate tap waited behind it. That is now prepared once the page has settled. On its own it did not fix the budget miss, which is worth saying plainly rather than implying otherwise. The second cause was the real one: the soft moving light behind the sign-in card was being re-blurred by the browser on every single frame, because the blur was applied to the whole group rather than to each glow in it. The same effect is now drawn once per glow and simply moved, which is the cheap way to do it. Nothing looks different — same light, same motion, same passkey offered in the same place — the page just answers you sooner.","category":"performance","link":{"href":"https://obeliskgate.com/auth","label":"Sign in"}},{"id":"two-corrections-to-our-own-claims","releasedOn":"2026-09-29","releasedMonth":"2026-09","title":"Two corrections to our own claims","summary":"We hold ourselves to a rule: if we can't measure it, we don't claim it. Two statements on this site did not meet it, and both are now corrected. First, our pages described a post-quantum signature slot as already reserved in every receipt we issue. That overstated where the work had got to — the hybrid signer is built and tested, and it signs into a separate field so nothing you already verify would change, but it is not switched on for issued receipts today, and the pages now say so plainly. Second, our risk engine was described as scoring every sign-in across eleven dimensions. The eleven-dimension engine is real, but it governs actions taken by agents and tools rather than sign-ins; sign-in and account activity are scored in real time on four live signals and still resolve to allow, step up, or deny. Both capabilities are genuine and unchanged — what changed is that each description now names exactly what that capability scores, and how far the other has got. No behaviour of the service was altered by this release, and the internal check that flags an unsupported claim now runs with no exemptions outstanding.","category":"transparency","link":{"href":"https://obeliskgate.com/security","label":"Cryptography reference"}},{"id":"more-reliable-sign-in-and-safer-account-changes","releasedOn":"2026-09-23","releasedMonth":"2026-09","title":"More reliable sign-in and safer account changes","summary":"Passkey sign-ins now stay reliable when several people sign in at once, and sessions renew more smoothly. Account changes have stronger safeguards, including clearer boundaries for organization access and more reliable account deletion.","category":"security","link":{"href":"https://obeliskgate.com/changelog","label":"Release notes"}},{"id":"a-safety-check-that-had-quietly-stopped-reading-recent-work","releasedOn":"2026-09-10","releasedMonth":"2026-09","title":"A safety check that had quietly stopped reading recent work — and the cross-check that will notice next time","summary":"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.","category":"reliability","link":{"href":"https://obeliskgate.com/changelog","label":"Release notes"}},{"id":"the-running-server-is-now-checked-against-the-vault-it-was-provisioned-from","releasedOn":"2026-09-09","releasedMonth":"2026-09","title":"The running server is now checked against the vault it was provisioned from, without any value leaving either side","summary":"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.","category":"security","link":{"href":"https://obeliskgate.com/security","label":"How Obelisk protects sign-in"}},{"id":"the-running-server-is-now-checked-against-its-own-settings","releasedOn":"2026-09-09","releasedMonth":"2026-09","title":"The running server is now checked against the settings it was given","summary":"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.","category":"security","link":{"href":"https://obeliskgate.com/security","label":"How Obelisk protects sign-in"}},{"id":"sign-up-is-now-invite-only","releasedOn":"2026-09-09","releasedMonth":"2026-09","title":"Creating an account on obeliskgate.com now requires an invitation","summary":"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.","category":"security","link":{"href":"https://obeliskgate.com/security","label":"How Obelisk protects sign-in"}},{"id":"alerts-we-do-not-recognise-now-reach-you","releasedOn":"2026-09-08","releasedMonth":"2026-09","title":"Alerts we do not recognise now reach you, and unrated vulnerabilities stop sinking to the bottom of the list","summary":"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.","category":"security","link":{"href":"https://obeliskgate.com/security","label":"How Obelisk protects sign-in"}},{"id":"health-checks-no-longer-compete-with-your-requests","releasedOn":"2026-09-08","releasedMonth":"2026-09","title":"Health checks no longer compete with your requests","summary":"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.","category":"performance","link":{"href":"https://obeliskgate.com/status","label":"See current status"}},{"id":"the-public-transparency-check-answers-faster","releasedOn":"2026-09-08","releasedMonth":"2026-09","title":"The public transparency check answers faster, and answers the same","summary":"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.","category":"transparency","link":{"href":"https://obeliskgate.com/proof","label":"Verify it yourself"}},{"id":"bot-protection-ready-and-a-sign-in-link-that-cannot-be-spammed","releasedOn":"2026-09-06","releasedMonth":"2026-09","title":"Bot protection is ready to switch on, sign-in links can no longer be requested without limit, and verification answers the way the standards say","summary":"Four changes. First, the sign-up, contact, website-scan and email-sign-in forms on obeliskgate.com now carry a Cloudflare Turnstile challenge whenever it is enabled for the site. You will normally never see it; it exists so that automated abuse of those forms can be stopped without making a real person solve puzzles. Applications that sign people up from their own pages are not affected. Second, the email sign-in link can now be requested only a few times per address and per connection in a short window, so nobody can flood an inbox with sign-in mail. Third, an unauthenticated request to the OpenID user-info endpoint now answers with the standard challenge header (RFC 6750), so client libraries recognise it correctly. Fourth, the public transparency check now reports each ledger on its own, so a difference that is simply the server being ahead on one ledger and the operator ahead on another is described as exactly that rather than flagged as tampering.","category":"security","link":{"href":"https://obeliskgate.com/security","label":"How Obelisk protects sign-in"}},{"id":"prove-your-agent-owns-its-domain","releasedOn":"2026-09-04","releasedMonth":"2026-09","title":"Prove an agent owns its domain, and pull in its agent card, without leaving the page","summary":"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.","category":"identity","link":{"href":"https://obeliskgate.com/account/agents","label":"Open Agent Studio"}},{"id":"our-daily-security-sweep-runs-to-the-end-again","releasedOn":"2026-09-03","releasedMonth":"2026-09","title":"Our daily security sweep was stopping early, and we did not notice","summary":"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.","category":"transparency","link":{"href":"https://obeliskgate.com/trust","label":"How Obelisk proves itself"}},{"id":"invitations-that-actually-arrive-and-organisations-you-can-delete","releasedOn":"2026-09-03","releasedMonth":"2026-09","title":"Invitations now arrive by email, organisations can be deleted, and a sign-in link stays private","summary":"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.","category":"organizations","link":{"href":"https://obeliskgate.com/account","label":"Manage your organisations"}},{"id":"recovery-codes-and-the-power-of-a-remembered-session","releasedOn":"2026-09-02","releasedMonth":"2026-09","title":"Two corrections: your recovery codes, and what a remembered sign-in is allowed to do","summary":"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.","category":"security","link":{"href":"https://obeliskgate.com/account","label":"Review your account security"}},{"id":"our-own-safety-checks-can-no-longer-be-quietly-weakened","releasedOn":"2026-09-02","releasedMonth":"2026-09","title":"Our own safety checks can no longer be quietly weakened","summary":"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.","category":"security","link":{"href":"https://obeliskgate.com/trust","label":"How Obelisk proves itself"}},{"id":"every-refusal-is-now-machine-readable-and-every-receipt-is-a-link","releasedOn":"2026-09-01","releasedMonth":"2026-09","title":"Every refusal is now machine-readable, every receipt is a link, and security alerts can reach your inbox","summary":"Three things landed for the people and the agents who build on Obelisk. First, when Obelisk refuses a request — too many attempts, a spent read budget, an account quota — it now answers in the standard Problem Details format with a type link you can open, plus rate-limit headers that say exactly when to retry; the new Error reference page lists every type. Second, every receipt now has its own public page: paste a receipt hash after /proof/ and your browser refolds the inclusion proof itself. Third, security alerts by email are real: with the switch on, a sign-in from a device we have never seen, a new API key, a new passkey, or a revoked agent sends you a note. Also: if you are already signed in, the sign-in page now offers to continue as you instead of starting over; a full security activity timeline with filters lives under your account; reusing an authorization code now revokes the tokens it minted; and the MCP explain_rating tool, which had been answering 'Unrated band.' for every score, now explains the band it was asked about.","category":"product","link":{"href":"https://obeliskgate.com/problems","label":"See the error reference"}},{"id":"renaming-an-agent-can-no-longer-bring-a-revoked-one-back","releasedOn":"2026-09-01","releasedMonth":"2026-09","title":"Renaming an agent can no longer bring a revoked one back","summary":"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.","category":"security","link":{"href":"https://obeliskgate.com/agents","label":"Manage your agents"}},{"id":"a-revoked-agent-is-now-revoked-to-every-part-of-obelisk","releasedOn":"2026-09-01","releasedMonth":"2026-09","title":"Every list, lookup and edit now treats a revoked agent as revoked, and a compromised one gets no new access","summary":"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.","category":"security","link":{"href":"https://obeliskgate.com/agents","label":"Manage your agents"}},{"id":"revoking-an-agent-now-really-revokes-it","releasedOn":"2026-08-31","releasedMonth":"2026-08","title":"Revoking an agent now ends its access across Obelisk and its delegation chain","summary":"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.","category":"security","link":{"href":"https://obeliskgate.com/agents","label":"Manage your agents"}},{"id":"agent-profiles-grow-up-and-a-sign-in-annoyance-is-fixed","releasedOn":"2026-08-30","releasedMonth":"2026-08","title":"Agent profiles grow up: profile pages, domain proof, easier editing — and a sign-in annoyance is fixed","summary":"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.","category":"product","link":{"href":"https://obeliskgate.com/agents","label":"See what agents get"}},{"id":"deleting-your-account-now-ends-every-connected-sign-in","releasedOn":"2026-08-28","releasedMonth":"2026-08","title":"Deleting your account now ends every connected project's access too — and two more protections","summary":"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.","category":"security","link":{"href":"https://obeliskgate.com/help","label":"Browse the Help Center"}},{"id":"your-keys-your-quota-and-a-page-for-checking-us","releasedOn":"2026-08-27","releasedMonth":"2026-08","title":"See what your API keys are actually doing, and check our claims yourself","summary":"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.","category":"experience","link":{"href":"https://obeliskgate.com/proof","label":"Verify it yourself"}},{"id":"readable-and-reachable-on-every-device-in-both-themes","releasedOn":"2026-08-25","releasedMonth":"2026-08","title":"Every page, every screen size, both themes — measured and fixed","summary":"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.","category":"experience","link":{"href":"https://obeliskgate.com/help","label":"Browse the Help Center"}},{"id":"sign-in-returns-you-to-the-project-you-came-from","releasedOn":"2026-08-25","releasedMonth":"2026-08","title":"Signing in from a connected project now returns you there — and can happen without leaving the page","summary":"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.","category":"federation","link":{"href":"https://obeliskgate.com/developers","label":"Read the integration guide"}},{"id":"sign-out-really-ends-a-session","releasedOn":"2026-08-25","releasedMonth":"2026-08","title":"Signing out really does end the session now — and a correction about that","summary":"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.","category":"security","link":{"href":"https://obeliskgate.com/account","label":"Review your sessions and devices"}},{"id":"agent-controls-proof-tools-and-honest-pages","releasedOn":"2026-08-24","releasedMonth":"2026-08","title":"Full agent controls, a prove-it-yourself receipt check, and a truth pass across the site","summary":"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.","category":"product","link":{"href":"https://obeliskgate.com/agents","label":"See what agents can do"}},{"id":"agent-proof-links-and-progressive-onboarding","releasedOn":"2026-08-23","releasedMonth":"2026-08","title":"Agents and bots can now carry a proof link","summary":"Obelisk now gives opted-in agents and bots a private-by-default identity profile with an opaque, revocable proof link for people and software to inspect. The verifier separates current key control, accountable ownership, workload and runtime evidence, authorization, human influence, and revocation instead of reducing trust to one badge. A human owner can approve a short device ceremony while the agent proves its own locally generated key, so no agent secret needs to be pasted into a chat. Individual runs can also carry privacy-preserving proof of their commitments and disclosed human involvement. The page is intentionally precise: it never claims that an actor is permanently non-human, fully autonomous, uncompromised, or truthful when the evidence cannot establish that.","category":"product","link":{"href":"https://obeliskgate.com/account/agents","label":"Open Agent Studio"}},{"id":"exact-serving-release-on-status","releasedOn":"2026-08-21","releasedMonth":"2026-08","title":"The status page now shows exactly which release is serving","summary":"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.","category":"transparency","link":{"href":"https://obeliskgate.com/status","label":"View live status"}},{"id":"ask-obelisk-from-your-own-tools","releasedOn":"2026-08-17","releasedMonth":"2026-08","title":"AI assistants can now ask Obelisk directly whether something is trustworthy","summary":"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.","category":"product","link":{"href":"https://obeliskgate.com/mcp","label":"Read the MCP guide"}},{"id":"your-own-security-history-and-receipts","releasedOn":"2026-08-17","releasedMonth":"2026-08","title":"You can now see your own security history — and every receipt about you","summary":"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.","category":"product","link":{"href":"https://obeliskgate.com/account/issuance","label":"Open your receipts hub"}},{"id":"real-time-security-signals-caep","releasedOn":"2026-08-16","releasedMonth":"2026-08","title":"Security events now reach connected apps in real time","summary":"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.","category":"security","link":{"href":"https://obeliskgate.com/security","label":"Read the security overview"}},{"id":"verifiable-agent-repository-links","releasedOn":"2026-08-14","releasedMonth":"2026-08","title":"Agent repository links can now be checked, and say what the check covers","summary":"When an agent is linked to a repository, that link can now be verified rather than simply recorded. The result is shown in three states — confirmed, refuted, or not determinable — and it states plainly what was established: that the repository exists, not that the agent has permission to use it. A private repository is reported as not determinable rather than incorrectly marked missing. Billing records for metered sign-ins are also now written to a tamper-evident ledger.","category":"security","link":{"href":"https://obeliskgate.com/security","label":"Read the security overview"}},{"id":"tamper-evident-agent-usage-record","releasedOn":"2026-08-13","releasedMonth":"2026-08","title":"Agent capability use is now recorded in a tamper-evident ledger","summary":"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.","category":"security","link":{"href":"https://obeliskgate.com/security","label":"Read the security overview"}},{"id":"shared-public-evidence-and-correlated-passages","releasedOn":"2026-08-12","releasedMonth":"2026-08","title":"Public trust evidence now has one privacy-aware source","summary":"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.","category":"transparency","link":{"href":"https://obeliskgate.com/stats","label":"View public evidence"}},{"id":"windows-hello-and-ecosystem-acknowledgements","releasedOn":"2026-08-12","releasedMonth":"2026-08","title":"Passkey sign-in keeps authenticator preference, and integrations can acknowledge rollout","summary":"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.","category":"identity","link":{"href":"https://obeliskgate.com/developers","label":"Review integration options"}},{"id":"grant-verification-evidence","releasedOn":"2026-08-11","releasedMonth":"2026-08","title":"API key checks now leave a clear verification trail","summary":"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.","category":"assurance","link":{"href":"https://obeliskgate.com/account/issuance","label":"Review account receipts"}},{"id":"app-registry-release-inputs","releasedOn":"2026-08-11","releasedMonth":"2026-08","title":"Registered app changes now ride the release path","summary":"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.","category":"reliability","link":{"href":"https://obeliskgate.com/developers","label":"Read the app setup guide"}},{"id":"self-serve-app-registration-and-organizations","releasedOn":"2026-08-09","releasedMonth":"2026-08","title":"Register your own apps, run your organization's sites and team, and protect your agent servers","summary":"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.","category":"identity","link":{"href":"https://obeliskgate.com/organizations","label":"See organizations →"}},{"id":"agent-readable-trust-paths-and-freshness-aware-proof","releasedOn":"2026-08-05","releasedMonth":"2026-08","title":"Agent-readable trust paths now come with freshness-aware proof","summary":"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.","category":"assurance","link":{"href":"https://obeliskgate.com/mcp","label":"Explore agent integration →"}},{"id":"public-registration-and-real-session-ending","releasedOn":"2026-08-04","releasedMonth":"2026-08","title":"Public registration is open, with sign-out that really ends the session","summary":"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.","category":"identity","link":{"href":"https://obeliskgate.com/auth","label":"Go to sign-in →"}},{"id":"checks-that-say-when-they-were-not-allowed-to-look","releasedOn":"2026-08-03","releasedMonth":"2026-08","title":"Our checks now say when they weren't allowed to look","summary":"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.","category":"transparency","link":{"href":"https://obeliskgate.com/trust","label":"See how we prove it →"}},{"id":"monitoring-that-can-report-its-own-blind-spots","releasedOn":"2026-08-03","releasedMonth":"2026-08","title":"Our monitoring now reports its own blind spots","summary":"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.","category":"transparency","link":{"href":"https://obeliskgate.com/trust","label":"See how we prove it →"}},{"id":"exact-release-dates","releasedOn":"2026-08-02","releasedMonth":"2026-08","title":"Release history now shows the exact day","summary":"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.","category":"transparency","link":{"href":"https://obeliskgate.com/changelog?format=json","label":"View the structured history"}},{"id":"gateway-toll-and-trust-flight-plan","releasedOn":"2026-08-01","releasedMonth":"2026-08","title":"One Gateway toll and a safer project onboarding path","summary":"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.","category":"product","link":{"href":"https://obeliskgate.com/pricing","label":"See the Gateway toll →"}},{"id":"passport-v2-client-boundaries","releasedOn":"2026-08-01","releasedMonth":"2026-08","title":"Passport v2 binds every sign-in to a registered project","summary":"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.","category":"identity","link":{"href":"https://obeliskgate.com/developers","label":"Read the integration contract →"}},{"id":"mobile-parity-and-isolated-release","releasedOn":"2026-07-31","releasedMonth":"2026-07","title":"A sturdier mobile experience and safer release path","summary":"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.","category":"experience","link":{"href":"https://obeliskgate.com/status","label":"See the release posture →"}},{"id":"verifiable-release-history","releasedOn":"2026-07-31","releasedMonth":"2026-07","title":"Release history you — and your agents — can verify","summary":"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.","category":"transparency","link":{"href":"https://obeliskgate.com/changelog?format=json","label":"Open the release document →"}},{"id":"exact-revision-release-proof","releasedOn":"2026-07-29","releasedMonth":"2026-07","title":"Every deployment now proves the code it ships","summary":"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.","category":"assurance","link":{"href":"https://obeliskgate.com/status","label":"See the resilience posture →"}},{"id":"evidence-provenance","releasedOn":"2026-07-28","releasedMonth":"2026-07","title":"Security evidence now carries its provenance","summary":"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.","category":"assurance","link":{"href":"https://obeliskgate.com/trust","label":"How verification works →"}},{"id":"weighted-trust-evidence","releasedOn":"2026-07-26","releasedMonth":"2026-07","title":"Trust scores now respect evidence strength","summary":"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.","category":"rating","link":{"href":"https://obeliskgate.com/trust","label":"Explore the trust model →"}},{"id":"checks-prove-they-can-fail","releasedOn":"2026-07-26","releasedMonth":"2026-07","title":"Safety checks now prove they can catch a defect","summary":"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.","category":"assurance","link":{"href":"https://obeliskgate.com/security","label":"Read the security model →"}},{"id":"production-revision-truth","releasedOn":"2026-07-26","releasedMonth":"2026-07","title":"Production status now follows the revision actually running","summary":"Deployment-currency signals now compare the code serving production with the intended release, rather than treating unrelated repository files as runtime drift.","category":"reliability","link":{"href":"https://obeliskgate.com/status","label":"View status and resilience →"}},{"id":"committed-evidence-plane","releasedOn":"2026-07-26","releasedMonth":"2026-07","title":"Integrity reports identify the tree they measured","summary":"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.","category":"transparency","link":{"href":"https://obeliskgate.com/security","label":"Review the security posture →"}},{"id":"unknown-is-not-healthy","releasedOn":"2026-07-26","releasedMonth":"2026-07","title":"Unknown is no longer reported as healthy","summary":"When a dependency or identity provider cannot be measured, Obelisk preserves that result as unknown instead of turning missing evidence into a green status.","category":"transparency","link":{"href":"https://obeliskgate.com/status","label":"See how status is reported →"}},{"id":"website-current","releasedOn":"2026-07-23","releasedMonth":"2026-07","title":"The website, brought fully current","summary":"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.","category":"documentation","link":{"href":"https://obeliskgate.com/api","label":"Explore the API manifest →"}},{"id":"account-control","releasedOn":"2026-07-17","releasedMonth":"2026-07","title":"Security alerts, API keys and full account control","summary":"Your account now includes a security-alert timeline, scoped expiring API keys for agents, security-habit badges, and a direct account-deletion control.","category":"account","link":{"href":"https://obeliskgate.com/account","label":"Open your account →"}},{"id":"live-website-roster","releasedOn":"2026-07-16","releasedMonth":"2026-07","title":"Live website roster","summary":"Organization dashboards now show linked websites with live probe-backed status, response latency, and an uptime sparkline rather than a cached availability claim.","category":"organizations"},{"id":"persistent-accessibility","releasedOn":"2026-07-15","releasedMonth":"2026-07","title":"Theme and accessibility preferences that stick","summary":"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.","category":"experience"},{"id":"account-shield","releasedOn":"2026-07-02","releasedMonth":"2026-07","title":"Account Shield","summary":"Every account now has a live security score, tier, trend, sign-in streak, and a concrete next action that can improve its posture.","category":"rating"},{"id":"verified-seal","releasedOn":"2026-06-28","releasedMonth":"2026-06","title":"The verified “Secured by Obelisk Gate” seal","summary":"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.","category":"verification","link":{"href":"https://obeliskgate.com/developers/seal","label":"Get the seal →"}},{"id":"saml-identity-provider","releasedOn":"2026-06-27","releasedMonth":"2026-06","title":"SAML 2.0 identity provider","summary":"Obelisk gained a SAML 2.0 identity provider that signs Security Assertion Markup Language assertions for downstream applications. The hosted Gate cannot connect a SAML application yet, and a SAML assertion does not say how the person signed in, so other tools sign in through Obelisk over OpenID Connect today.","category":"federation","link":{"href":"https://obeliskgate.com/docs/saml","label":"What exists today →"}},{"id":"off-box-recovery","releasedOn":"2026-06-25","releasedMonth":"2026-06","title":"Off-box recovery and a self-healing watchdog","summary":"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.","category":"reliability","link":{"href":"https://obeliskgate.com/status","label":"Resilience posture →"}},{"id":"integrations-catalogue","releasedOn":"2026-06-23","releasedMonth":"2026-06","title":"Integrations catalogue","summary":"A single catalogue now shows where Obelisk can serve as the identity provider over OpenID Connect or Security Assertion Markup Language.","category":"federation","link":{"href":"https://obeliskgate.com/integrations","label":"Browse connectors →"}},{"id":"credential-transparency","releasedOn":"2026-06-18","releasedMonth":"2026-06","title":"Verify-it-yourself credential transparency","summary":"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.","category":"transparency"},{"id":"assurance-bound-sessions","releasedOn":"2026-06-15","releasedMonth":"2026-06","title":"Assurance-bound sessions","summary":"Sessions carry how identity was proven. Passkey-backed sessions can perform sensitive changes; lower-assurance recovery sessions remain restricted.","category":"identity"},{"id":"obelisk-rating","releasedOn":"2026-06-13","releasedMonth":"2026-06","title":"The Obelisk Rating, 0–100","summary":"A live security score distills measured account or organization signals into one rating with visible coverage and improvement levers.","category":"rating"},{"id":"organizations-and-scan","releasedOn":"2026-06-11","releasedMonth":"2026-06","title":"Organizations, teams and website scan","summary":"Register an organization, invite role-scoped team members, and measure a public website to produce a security rating with concrete improvement levers.","category":"organizations"},{"id":"one-identity-every-project","releasedOn":"2026-06-08","releasedMonth":"2026-06","title":"One identity, every project","summary":"A universal Obelisk account now carries cleanly separated per-project profiles, allowing one passkey-first identity to work across the ecosystem.","category":"identity"},{"id":"passkey-first-sign-in","releasedOn":"2026-05-24","releasedMonth":"2026-05","title":"Passkey-first usernameless sign-in","summary":"One-tap, phishing-resistant sign-in works without typing a username, with controlled recovery paths available when needed.","category":"identity"},{"id":"tamper-evident-receipts","releasedOn":"2026-05-22","releasedMonth":"2026-05","title":"Tamper-evident receipts","summary":"Consequential identity and authorization actions emit signed, hash-chained receipts so the audit trail cannot be silently rewritten.","category":"assurance"}]}