Organizations, Our Biggest Analysis Update, and the zkao Assistant

This is the biggest change to how zkao finds bugs since we launched. Scan types are now named for what you want done. Deep Audit runs all of its techniques on every scan. Three new techniques expand coverage, and later scans build on what earlier analysis learned about your repository.

The rest of the release is about what you do with what they find: the zkao assistant on every page, @zkao and your teammates in finding comments, findings you can hand to your own coding agent, and scans that explain what they covered. Above all of it sits a new level: organizations.

Organizations

Projects now live inside an organization. Each existing project has been placed in an organization of its own, so nothing changes until you want it to. From there you can create more projects under the same organization, or move your team onto it.

• One team, many projects. Members and roles are set once at the organization level. Owners and admins hold every project in the organization. Members get access to the projects you choose, each with its own project role.
• One balance. Credits are held by the organization and shared by all of its projects. Billing, invoices, and auto top-up live on the organization's billing page. Spend stays attributed to the project that launched it. The API's balance endpoint reports the organization's shared balance and names the organization it belongs to.
• Invitations at either level. Invite someone to the organization with a role, or to a single project as before.
• Move a repository. A repository can move to another project in the same organization from its settings page. Its scans, findings, automations, and guidance move with it.

The header now shows all three levels. Click a level's name to go to its dashboard, or open its switcher to jump to another organization, project, or repository. URLs follow the same shape, so the address bar tells you where you are:

/orgs/acme/projects/payments/repos/payments-api

Organization admins can change these short names from settings. Old links keep working: an address built on an id still resolves, and links in the previous /projects/... form redirect to the new one. The Organizations page in the docs covers roles, access, and billing in more detail.

Scan types named for the job

• Quick Look (formerly ZKAO Pro) is one cheap pass hunting for broken invariants, for code you are still changing.
• Deep Audit (formerly ZKAO Max) is the full methodology over the whole repository, the one worth reporting on. Every scan now runs all of its analysis techniques, from 14,067 credits. From the second scan on, it also goes after what the previous scan left uncovered.
• Continuous Testing is built to be left running. It combines different analysis techniques over successive runs and checks changes for broken security properties. One run is cheap; the coverage builds up over many. It is a feature you turn on per repository, from its own page: give it a monthly budget and zkao picks the cadence. See below.
• Dependency Watch audits your third-party dependencies for known vulnerabilities your code can actually reach, upstream security fixes you have not taken, and updates that look malicious or backdoored. Repeat runs focus on what changed. Its page on each repository is a preview of the features it will offer.
• A Quick Look at a change audits one change: the commits between a base you name and the commit you scan. It reads the change in the context of the whole repository and builds on what earlier scans already learned, so its budget goes to what the change touches. It works on any repository, with no full scan needed first. Launch one from the new-scan page, from CI with the zkao GitHub Action, or from your coding agent through the zkao skill.
• A Quick Look at resolved findings confirms that the fixes for findings you resolved still hold, and reports any bug that came back. Pick up to 50 resolved findings to re-check, or start from a finding's Re-check fix button or from a selection in the findings list. Its minimum budget grows with each finding you add.

The entry-level ZKAO scan is retired. A repository that ran it starts from Quick Look. Links and API calls that name the old scan types keep working.

Our analysis got better

Three new techniques

• Formal verification checks security properties with mathematical proofs. It helps uncover bugs that testing and review can miss in both ZK circuits and other code.
• Dependency analysis looks for vulnerabilities your code inherits from the libraries it uses. It also catches unsafe assumptions about what those libraries guarantee. It is part of Continuous Testing.
• Security checks for code changes look for broken security properties as your repository evolves. They strengthen Continuous Testing and Quick Look scans of a change.

Scans that build on earlier work

Later scans build on what earlier analysis learned about your repository. Coverage deepens over time, especially with Continuous Testing.

Sharper on the bugs that matter

• Analysis is better at finding inconsistent assumptions between parts of a system.
• Checks against specifications catch more missing safeguards and departures from intended behavior.
• Automated testing reaches more edge cases that random inputs miss.
• ZK analysis catches more privacy leaks from public outputs. Aleo coverage is sharper on asset identity errors.

These improvements can find bugs in code earlier scans already looked at.

New coverage: trusted execution and Noir

Scans now understand systems built on trusted execution environments and confidential computing: remote attestation, confidential VMs, key release to enclaves, anonymous access, and binary transparency. They carry hardware-specific knowledge of Intel SGX and TDX, AMD SEV, AWS Nitro, and NVIDIA H100.

Scans now include Noir-specific coverage for soundness, witness constraints, privacy, and verifier integration.

One launch page

Launching a scan is one page again instead of three steps, and it starts with what you want done. Pick a scan type at the top: it says what it is for, how long it usually takes on this repository, and what it costs. The repository, branch, and commit follow, with the context the scan will read: the committed zkao.md, the repository's guidance, its reference documents and repositories, each linked to where it is managed. Below them the page asks only for what the chosen scan needs, then for its budget. A summary at the bottom restates every decision and holds the launch button.

• Two scan types, three ways to look. Quick Look and Deep Audit sit side by side. Inside Quick Look you pick what it reads: the repository, a change, or resolved findings. Everything that used to be a Diff Scan or a Regression Check is still there, under that choice. A look at the repository or a Deep Audit asks for an audit scope, a change asks for a base, and resolved findings ask which findings to re-check.
• Run it now or on a trigger. A Deep Audit can run once, on a cadence, or on every new zkao release. A triggered scan becomes an automation with the same scope and a per-run budget, managed in project settings. A Quick Look of a change can also run from GitHub or from your coding agent. Any other Quick Look simply runs once, so the page offers no choice.
• Scope in your own words. Describe the part of the code you want audited in prose, as an alternative to picking audit areas from the map. The written scope shows on the scan page and as a badge in your scan history.
• Areas of your own. On a repository's Context tab, give an area a name and a description and it becomes selectable at launch like the areas the map discovered. The public API can list, add, and delete a repository's audit areas, and takes area keys when launching a scan.
• Budgets that learn. When a scan of the same scope was pressed for budget, the next recommendation is a quarter more, and the page says why. A balance just under a scan type's minimum no longer blocks the launch: accept a thinner run and the scan starts with what you have.

Each repository at a glance

The project dashboard is now the place to see whether every repository is covered. Each row shows, next to its scan status, whether its Deep Audit is automated and whether Continuous Testing and Dependency Watch are on, in green when they are and muted when they are not. Click one to set it up or manage it.

Continuous Testing and Dependency Watch have pages of their own on each repository, reached from there or from the repository's Features in use card. On the Continuous Testing page you say how many credits a month the repository may spend. The recommended budget runs a scan every day, and the minimum runs one every week. zkao sets the cadence and per-run budget from what you choose. You can also pick audit areas, so each run goes deeper on one area in turn. A progress bar shows how much of this month's budget the runs have used, with the run count and what is left, and you can pause the schedule, change its budget or areas, or remove it. The first run starts within the hour of turning it on. The same controls are in the public API, behind a new automations:write token scope. The Dependency Watch page previews the features it will offer and takes a monthly budget, but saves nothing yet.

The project dashboard's Finish setting up checklist now covers only the project: connect a repository and top up credits. Each repository carries its own checklist on its overview: run a Quick Look, triage what it found, and automate the Deep Audit.

Public badges and widgets now show completed audit activity and schedule status for the repositories you choose to publish. Their linked activity page shows the branch, commit, and scope. Existing embeds need a saved repository selection from Public Badge & Widget on the project overview.

Meet the zkao assistant

The zkao assistant is a chat on every organization, project, and repository page, and on your dashboard, in a pill at the bottom right or one keypress away with ⌘J. It follows the page you are on. Open it and it briefs you: how recent the last scan is and how far the branch has moved since, which findings are waiting on triage and where they cluster, repositories not yet scanned, and scans that failed. Ask it about your findings, scans, guidance, or the code itself and it reads them to answer.

It proposes actions as cards you apply or dismiss: a resolution or severity for one or more findings, a note, an answer to an open question, an edit to your guidance, or a scan filled in with the repository, branch, scope, type, and budget. A scan card only pre-fills the launch page. Nothing is spent until you launch it there. When something goes wrong, or you want a person, it drafts a support ticket for you to send from the chat.

On organization pages it takes the wider view: which projects have critical or high findings nobody has reviewed, which scans failed, which repositories were never scanned, and whether credits are running out.

On your dashboard, settings, and support pages it knows your organizations and projects and links you to the right one. Ask it how something works and it answers from the user docs, with a link to the section it used. On the support page it walks through the troubleshooting pages with you before drafting a ticket.

Some of its work needs no chat at all. Answer a clarifying question and it turns your answer into a guidance suggestion. Explain why you closed a finding and it proposes the same call on similar findings, as a banner you can accept or ignore. Past chats can be reopened, open windows stay in sync, and the window can be docked to the side so it follows you across pages.

Conversations on findings

Mention @zkao in a finding's comments and it replies in the thread. A line under your comment shows while it reads and writes, and its answer appears in place, marked as a reply to you. When it cannot answer, the thread says so instead of going quiet. Tag it again before it has answered and the second question waits its turn. Edit the comment and it starts over on the new text. Delete it and the reply is dropped.

When your comment takes a side, saying a finding is not a real issue, a duplicate, or not worth fixing, the assistant answers with a suggestion you can accept in one click, with your reasoning attached. A statement about your threat model or scope becomes a proposed guidance edit for future scans. @zkao is offered to project members. Viewers can read its replies.

Type @ to mention a teammate. They get a notification and an email with a link straight to the comment. Mention emails can be switched off in Settings > Notifications. A comment posted through the API reaches the people it tags and summons @zkao the same way. Finding notes now render markdown.

No findings left behind

Triage now uses remaining scan credits to check open findings that have not been checked for 30 days, when the scan targets a changed commit on the same branch. Continuous Testing runs these checks too. Each assessment preserves the original finding and shows its checked commit and evidence.

A suggested closure gives you seven days to accept, dismiss, or snooze it. By default it applies after that window. Project settings can dismiss unanswered suggestions instead, and repository settings can override the project policy.

The findings page highlights older open findings and pending suggestions, with review deadlines and a direct link to the automatic decision settings.

A later scan that reports the issue again on a changed commit on the same branch cancels automatic closure. Automatically applied changes are attributed to zkao. Undo restores the previous status and pinned note if the finding has not changed since.

Hand findings to your coding agent

A Hand off to agent button composes a prompt for your coding agent, pointing it at the zkao skill and at the findings, with a box for your own instructions and a preview of what will be copied. It is on a finding page, on a scan's header for every finding in the scan, in the findings toolbar for a selection, and on the dashboard, project, and repository pages. Paste the prompt into the agent and it fetches the findings through the API, verifies each against the audited commit, and can comment, change the severity, or resolve it back in zkao. A checkbox inlines the finding text for an agent that cannot reach zkao.

The prompt names the project and organization, so the agent asks you to approve the right one. The approval page groups your projects by organization and preselects the one the agent asked for.

Scans that explain themselves

A finished scan ends in a card that says what happened in one line: how long the audit ran, what it used, and how many findings it reported. Below that, the scan describes what it covered and what it left for later. A "better next scan" panel names why another run would find more, and quotes a concrete budget when a step ran short. One button, "Repeat this scan automatically", turns the finished scan into a standing one with the same settings.

A confirmed finding now says how it was confirmed: reproduced with a running proof of concept, or verified by analysis of the code. The API reports the same.

Scans recover from failures on our side without charging you for discarded attempts. A run that fails, times out, or hits its budget also keeps the findings it had already reported.

Setting up a repository

The mapping pass that runs when you connect a repository now tells you more. The repository page shows a codebase profile: what the project is, how much code is in audit scope, and its languages and frameworks. While the pass runs, the page shows its stage, a preview of the map, and things worth doing in the meantime. A repository becomes scannable the moment the pass finishes. If setup stops, the page says so and offers a retry. A private repository blocked on GitHub access resumes on its own once access is granted.

The pass raises the threat-model questions the code cannot settle. Each arrives with candidate answers, a line on what choosing each means for the audit, and why it was asked, so you can sharpen the first audit before it runs. The Context tab shows open questions and suggested guidance edits in one review strip above the guidance editor, one item at a time.

A new project's dashboard walks you through getting started: top up, run a Quick Look, triage what it finds and answer its questions, then run and automate a Deep Audit.

The repository page itself is redesigned. A status band says whether the repository is ready, out of date, or still setting up. A card profiles the codebase and its audit areas. An activity log grouped by day records each scan, with its type, scope, branch, who launched it, and how long it ran, alongside triage, comments, and assistant proposals.

Audit areas that follow your code

zkao places each open finding in the audit area it belongs to, and members can change a finding's area from its page. On a repository's findings, an Area filter narrows the list to one area, to retired areas, or to findings with no area.

The area map stays yours. As the code changes, scans suggest changes to it: a new area, one split out of another, two merged, or one retired. Nothing changes until a member accepts. Suggestions wait on the Context tab with Accept and Reject, are counted on the dashboard, and can be posted to Slack. Accepting one updates the automations that rotate through areas and reassigns the affected findings.

Security advisories, in early access

If other people's software depends on yours, you now have somewhere to receive vulnerability reports and something to do with them. A project can run a disclosure program: Settings → Advisories sets it up, and the Advisories tab is where the work happens.

Reports arrive through GitHub's private vulnerability reporting, so a researcher's private report lands in your inbox, and the draft advisory GitHub creates alongside it stays tied to the one you prepare here. Name as many repositories as your program covers, because a researcher files on whichever one they found the bug in, and a report on any of them arrives here.

Your advisory contacts are your own list, added on the Contacts tab or through the API. Each one records which of your repositories they run, and each advisory records which of them it is about, so a notice only reaches the teams running the software in question. An address nobody has confirmed receives nothing embargoed.

Run triage checks a vulnerability report against your current code. It confirms or dismisses the reported issues, identifies duplicates, and provides a proof of concept where possible. It also checks whether an older report still applies.

Triage all reviews every report waiting on a repository together at a lower cost than separate reviews. Each report gets its own verdict and page.

Accepting a report records what it claimed as findings on the repository, alongside the ones zkao found itself. A report you judged real stops being a message in an inbox and becomes something the findings list tracks, whether triage stood the claim up or you accepted it on the reporter's evidence.

A report can be turned into an advisory from its own page, and a confirmed finding from zkao's own scans can become one too. Give it a disclosure date and zkao builds the notification plan backwards from there, as far back as there is still time for: an early warning under embargo, a reminder, a patch notice once a fixed version exists, and the public disclosure on the day. Every wave shows exactly who would receive it and who would not, with the reason, so you can see that an unconfirmed address gets nothing embargoed and a patch notice with no fixed release goes nowhere.

Sending is off until we switch it on with you, which is deliberate: a disclosure notice cannot be recalled. Everything up to that point is live today, and a wave can be walked to see precisely what it would send and to whom.

The API covers the parts that belong in a release pipeline. Reading an advisory shows the software it concerns, the versions it affects, and the state of every planned notice with the reason any is held back. Recording a fixed version is the one write that matters, because a patch notice waits for it and only the people who cut the release know it. Contacts can be listed and added too. Each of these needs its own token scope, so a token that records a version cannot change who is told.

Other Changes

• Repository onboarding recommends daily Continuous Testing and a Deep Audit every two weeks. Both cover the whole repository, with recommended budgets and a combined monthly estimate before activation.
• A live banner on every dashboard shows the scans running right now.
• Scans from automations now email you only when they find something new or fail. Settings > Notifications can switch them to every scan or none. An automation whose last three scans fail is paused, and its members get one email. A link in each of these emails stops only that kind. See scan emails.
• An opt-in weekly or monthly scan digest sums up the scans that finished on your projects, with the new findings per repository.
• Invoices and receipts can carry your company details. Enter the company name, address, tax ID, and billing email once, and every invoice and card receipt prints them as Bill to, including ones already issued.
• Developer docs for the API, CLI, SDK, GitHub Action, and agent skill live at docs.zkao.io, linked from your project's Integrations page and the user guide.
• The API and CLI accept the ZK- id shown on a finding page wherever a finding id is expected.
• Organization settings list every API token across the organization's projects, with a revoke button.
• The CLI keeps a token per project, so logging in to a second project keeps the first. zkao whoami shows which project and organization a token belongs to.
• A scan launched through the API or the CLI no longer needs a budget. Leave it out and the scan runs at the budget zkao recommends, and the response says what it was.
• Support has its own page with a request form and a table of your tickets.
• Findings pages are one table you can group by severity, resolution, triage, or scan, with an activity view per finding. Opening a finding is instant.
• Activity feeds mark what is new since your last visit. Dots on organizations, projects, and repositories show where something happened, and findings with unread comments carry a dot in the list.
• A finding's resolution controls are one thing now: pick a reason, pin an existing comment, or write your own explanation inline. Members now see the assumptions a finding rests on, and a false positive can name the assumption that fails.
• Scans recover from more failures on their own.
• The projects list and the repositories page are sortable tables, and repository rows on the project overview show scan progress inline.
• Pin organizations, projects, and repositories to keep them at the top of your lists. The dashboard is simpler, with fewer status widgets.
• Members who are not project admins no longer see Add credits links.
• A ? icon next to budgets, credits, roles, statuses, and scan context explains what each one means. Several pages are shorter for it, and a few explanations that were wrong are now correct.
• The Context tab keeps a log of what changed there and who changed it: guidance edits, answered questions, decided suggestions, audit areas, and reference material.
• When the assistant replies on a finding and mentions your repository's guidance, the word links to it.
• Commit lists attribute commits to the linked GitHub account rather than the raw git author name.
• Repositories can be deleted from their settings and from the repositories list. A repository with scan history keeps a 30-day grace period. A deleted repository no longer blocks re-adding the same URL.
• New robot illustrations across onboarding, empty states, billing, and the new-version banner.
• A new public site, built around the zkao v3 film: a living room and a research workbench you can explore, product clips on every page, and a light and dark theme.
• The user guide is up to date, with new screenshots and a section on scoping a large codebase with audit areas. It is now a page per topic: a getting-started walkthrough, answers to common questions about organizations, credits, scans, findings, and the API, and troubleshooting pages for repository access and scan problems.