What's New

An auditor never asks "did you review this change?" They ask three harder things: did every change go through the gate, what happened to the ones that didn't, and can you show the record is complete. Assurance answers all three, from records PRGuard was already keeping.

Every merge to main, accounted for. The coverage ledger lists each change that reached a default branch, or a release branch the repository names, in the period and how it was governed: audited and passed, merged failing, bypassed with a skip marker, or not audited and why. Gaps are listed with their reason, not hidden. An organisation policy can switch skip markers off: a marker is then ignored, the change is audited, and the ledger shows it.

Exceptions, governed. With Assurance on, closing an error-level finding as won't fix needs an exception: a justification, a compensating control, an approver who is not the requester, and an end date. When it ends the finding reopens on its own.

Your AI, on the record. Each change is classified by origin (human, AI-assisted, AI agent, or bot or other automation) from observable signals: the author, the branch and commit trailers. It is a classification, not ground truth. Each audit records the model that ran. The register shows what share of your merges were classified as AI-written and how they fared against your standards.

Readiness, per framework. Map a rule file to the controls it supports in the Cyber Resilience Act and the EU AI Act. Readiness shows which controls have a rule that audits actually ran with, and which are gaps. An owner can sign a quarter off once it is over.

The two acts, article by article. The EU AI Act and Cyber Resilience Act pages say what each requirement asks, what PRGuard records for it and what stays with you, with a short video for each and a link to the law's own text.

One pack, verifiable offline. Pick a quarter and the frameworks you are audited against. You get a ZIP: the population, sampled audits for each control, your rules at the versions that ran, exceptions, policies, the journal, and a manifest with a SHA-256 for every file and a root hash over all of them. prguard verify pack.zip checks it without talking to us, and so does the verify.py inside the pack. Your code is never in the pack: names, sizes, fingerprints and links, as always.

Ask it. Insights can answer questions about all of this: which merges bypassed the gate last quarter, what exceptions are open, how AI-written changes fared. Each claim links to the record behind it.

Assurance produces evidence for the controls an assessor tests. It does not make you compliant, and nothing in it says a control is met: that is the assessor's judgement.

Assurance is under Governance → Assurance, on Pro and above and during a trial. An owner or an admin switches it on from the organisation page. Pro includes one evidence pack a month; Pro Team and Enterprise have no limit. Records are append-only and hashed on export, and each journal entry is linked to the one written before it.

The guide goes through it part by part.

A review tells you what is wrong with a change. It does not tell you what the change touches: which tables it writes, which outside services it calls, which queues it feeds. That is the question a reviewer asks before approving a change to a payment path, and until now you answered it by reading the code yourself.

The Impact tab. Every audit now carries a map of what the change's code reaches: the database tables and models, the outside services, the queues and background jobs, and which of the changed files import which. Every line on the map names the file and line it was read from, and links to that line in the audited commit. Click a box to see only what is joined to it.

A note on the pull request. When a change reaches something, the review says so in one line, most-reached first, with a link to the tab.

It costs nothing. The map is read from the change itself by pattern. It makes no AI call and uses no credits, and it never changes a verdict.

The Architecture context file. PRGuard only sees the code in the change, so it cannot see who else reads a table or listens on a queue. A new kind of context file, Architecture, lets you say. Describe your system in prose for the auditor, and declare its parts in one yaml block: the components by path, and the stores, services and queues each one uses. You don't have to write the block yourself: the Add a component form beside the editor takes a name, where its code lives and what it reads, calls, publishes or listens to, and writes the block for you. When a change reaches a table, the map then shows the other components that use it, marked as declared rather than seen.

Map this repository. In Context Studio, one button drafts the Architecture file for you from a scan of your code. Nothing goes into the draft that the scan did not find, and you edit it like any other context file.

The Impact tab and the pull request note are on Pro and above, and during a trial. An owner or an admin can switch impact analysis off for the organisation on the organisation page.

Every finding has always had a severity: how bad it is if it's real. It did not say how sure PRGuard was that it is real. A finding the audit had strong grounds for and one it had doubts about looked exactly the same, and you had to work out which was which yourself.

Now every finding carries a confidence level as well: high, medium or low.

PRGuard works it out. The AI doesn't grade itself. An audit is several separate checks, and confidence comes from what those checks did with the finding:

• High. PRGuard's deterministic pre-scan found the same problem in the same place, or its patch was applied to your file and fitted, and none of PRGuard's later checks disputed it.
• Medium. The review reported it and nothing checked it independently. Most medium findings are real. They just haven't been confirmed a second way.
• Low. One of PRGuard's own later checks disputed the finding, and nothing independent backs it up.

Why you still see low-confidence findings. When a later check doubts a serious finding, PRGuard does not quietly drop it. An error must not disappear on the AI's say-so alone, so the finding stays, and it still counts towards the result. What's new is that PRGuard tells you it had doubts: "PRGuard could not confirm this finding. Check it before acting on it." Look at these before you spend time on a fix.

Where you'll see it

• On each finding. Open a finding on the audit page and Confidence sits under its rule, with a sentence saying what the level means.
• Filter and sort. A Low confidence filter above the findings shows the doubtful ones on their own, and Sort by confidence puts the findings PRGuard is surest of first.
• On GitHub. A low-confidence finding is marked in the review, in its comment on the line, and in the PRGuard audit check. High and medium findings read as they always did.
• Active Issues. Low-confidence findings are marked, with a filter to show only those.
• Excel export. The workbook has a Confidence column, and the summary sheet counts each level.

What doesn't change. Confidence is there to help you decide what to look at first. It never changes an audit's verdict or its score, and a low-confidence error still fails the change until someone has looked at it. Audits that ran before today don't have confidence levels, and their pages look as they did.

A context file only works if the auditor can apply it. Until now you had no way to tell. You saved the file, it passed the injection scan, and that was all PRGuard said. If a rule was too vague to check, had no severity, or pointed at a file that had since moved, your audits got weaker and nothing told you.

Now PRGuard reviews every context file when you save it and shows you what it found.

Two minutes, start to finish: a payments team saves its rules, the review calls out two it can't apply and a file reference that doesn't exist, and the rewritten file comes back clean.

What it looks for. Each file is read the way the auditor reads it, as a set of rules to apply to a change:

• A rule it can't check. "Code should be well tested" can't be judged from the lines a pull request changes, so the auditor guesses or skips it.
• A rule with no severity. If a rule doesn't say how serious a breach is, the auditor decides for itself whether to fail the pull request.
• A rule with no measure. "Avoid long functions": how long is long?
• Rules that disagree. Two statements that can't both be followed, or a repository file that contradicts your organisation-wide one.
• An exemption that won't be honoured. A context file can't switch off a security check. If yours tries to, the review says so, so nobody assumes it took effect.
• Text that isn't a rule. Leftover notes and placeholder lines. The auditor reads them on every audit and can do nothing with them.

Each finding quotes the text it is about and suggests a rewrite. A file of clear, checkable rules comes back with nothing to raise.

Broken file references, caught. A context file can point the auditor at a source file with @ref:, so it reads that file alongside your rules. If the path is wrong, the auditor simply goes without it. PRGuard now checks every reference against the repository and tells you which ones won't load and why: the file isn't there, the path is a folder, it's a kind of file PRGuard never loads, or it's a path mentioned in passing that needs @ref: in front of it. An organisation-wide file is checked against every connected repository, and the review names the ones where the file is missing. After a repository changes, Re-check references runs the check again.

Fix it where you find it. Open a file in Context Studio and click Review, beside History and Edit. Click the quoted text in any finding and the editor opens with that line selected. The details panel shows where things stand, under the scan result: reviewing, how many findings, or nothing to raise.

Every version keeps its review. The version number is now a menu: pick an earlier version to read it as it was, with the review it got. The History page shows each version's review next to what changed, and which findings that change resolved. Findings are steady from one save to the next: one stays until you change the text it is about, or fix it somewhere else in the file.

It never holds up an audit. The review is advice. It runs once the injection scan has passed, your audits don't wait for it, and nothing it finds changes what an audit does. It reads your context files and nothing else, never your source code. The reference check looks at file names, not at what is in the files.

What it costs. One small AI call on your organisation's credits each time a file's content changes. Save the same text again, or restore an earlier version, and the earlier review is reused at no charge. The reference check is always free. Owners and admins can turn reviews off under Organisation → Features → Context file review.

Context file review is on for every plan. A file you saved before today gets its first review the next time you change it.

Anthropic released Claude Sonnet 5.5 on 28 September, and it is available in PRGuard from today. It costs the same per token as Claude Sonnet 5, and it's faster and stronger at coding, so Claude Sonnet 5.5 replaces Claude Sonnet 5 as our recommended Claude model.

How the two compare

¹ Anthropic's published figures. ² Sonnet 5.5 at maximum effort.

What changes for you

• If you were on Claude Sonnet 5, we've moved you to Sonnet 5.5. It costs the same per token, so there's nothing to change on your side.
• If you chose a different model, you're still on it. We haven't changed anything for you, and you can move to Sonnet 5.5 in AI Models whenever you like.
• New organisations start on Claude Sonnet 5.5.
• Claude Sonnet 5 is still available. To go back to it, open AI Models in your settings and pick it.

What it costs. Sonnet 5.5 charges the same per token as Sonnet 5, so any difference in what an audit costs comes from how many tokens it uses. Every audit is billed at the rates of the model that actually ran it, and you can see the per-call breakdown in any audit's Transcript tab. If you switch models, the first audit of a pull request you have already audited runs fresh on the new model. It doesn't reuse the earlier report.

Until now, PRGuard met your code at the pull request. By then the work feels finished, and every finding means another commit, another push and another wait for review. The new PRGuard extension for VS Code runs the same audit on your changes before you commit, right in the editor, and helps you fix what it finds while the code is still fresh in your mind.

The same audit, earlier. Stage your changes and click Run check. Your change goes through exactly what a pull request would: the prompt-injection screen, your organisation's own standards, the deterministic pre-scan and the full review, with every suggested patch verified against your file. Results come back in a few minutes, and you can keep working while it runs. You can also check everything you haven't committed, or your whole branch. The Next check view shows exactly which files will be sent before you press the button.

Findings where you work. Each finding lands at its exact line: in the new PRGuard panel next to Problems, in the Problems list, and as an underline in the editor. Hover it to read the explanation and act on it without leaving the file.

Fixes in one click. Where PRGuard has written a patch and verified that it applies to your file, Apply fix makes the change, scrolls to it and highlights it. Undo fix takes it back out. Apply all fixes does the whole check in one step.

Or hand it to your AI assistant. Fix with AI passes any finding, with its full explanation, to Claude Code, Gemini Code Assist or GitHub Copilot Chat. You choose your assistant once and it is remembered. Nothing is sent until you have read it and pressed Enter.

Progress that keeps up with you. Findings tick themselves off as their fixes land, whether you applied them here, typed them yourself or had an assistant make them. You can also tick off or dismiss a finding by hand, and that decision follows the same finding into your earlier checks. Every check is kept in the workspace's History, so you can go back to any run.

Your standards, in your repo. Your organisation's context files (the rules PRGuard reviews against) sync into a folder in your workspace, where you and your coding assistant can read them. They stay up to date on their own.

Billed like a pull-request audit, and never posted to GitHub. Each check uses your organisation's credits, exactly as a pull-request audit of the same change would, and the extension asks before every run. Run an identical change again and the earlier result is reused at no charge. Checks appear in Governance → Audit log marked Local, and leave no comment, review or status on GitHub. Your uploaded files are deleted as soon as the check ends, whether it succeeds or fails. If one fails, just run it again from the editor.

The extension is free to install from the Visual Studio Marketplace, and our getting-started guide takes you from install to your first check in under five minutes. You'll need an API key from Account → API & CLI.

An AI review is only worth as much as your ability to check it. Every audit now has two new tabs that open the box completely: the Transcript shows the full conversation behind your audit, and the Rule trace shows which rules were in force and how each one was applied.

The Transcript — read the audit as it happened. Every step, in order, in plain English: the injection screen that checks your change before anything else reads it, the detection rounds, the standards recheck, the write-up, the final summary. Each step says what it did and how it ended — "Flagged 3 potential violations to verify", "Nothing new found", "The screen found no injection attempts" — so you never have to interpret raw output to know what happened. Where the AI produced reasoning, you can read it; where it didn't, the transcript says so plainly.

Your code is never kept. Where your change or a file was sent for review, the transcript records only the file name, its size, and a fingerprint of exactly what was sent — then links out to GitHub for the content itself, where your own repository permissions decide who may read it. Your context files go one better: each one links to the exact version the audit used, and that link keeps working even if you've edited or deleted the file since.

The Rule trace — which rules, provably. It opens with your own context files: which were in force (with the exact version, one click away), and which were set aside — with the reason in plain words, like "quarantined — injection risk" or "superseded by repo-level file". Then PRGuard's own automatic checks: how many ran against your change and what they flagged. And finally the auditor's own rule-by-rule account — clearly marked as the AI's self-report and cross-checked against the findings actually raised, so every claim reads either "corroborated by finding" or "attested only". You always know which statements are pipeline fact and which are the model's word.

Our instructions stay ours — verifiably. The prompts PRGuard writes are its craft, so the transcript seals them: you see their size and fingerprint, proving exactly what was sent and that it never changed, without the wording itself. The same goes for the injection screen's inner workings — its verdict is always shown; its detailed reasoning is withheld so the screen stays hard for an attacker to probe.

Both tabs are live today on every plan, on every audit from here forward. Open any audit from Governance → Audit log and look for Transcript and Rule trace next to the summary.

To catch as much as possible, PRGuard doesn't read your change once — it reviews it several times over, because a second and third look reliably find things a single pass misses. Until now, every one of those passes paid full price to re-read the same material: your change, your standards, the pre-scan results.

Now the repeat passes reuse what's already been read. The first pass pays once; the follow-up passes re-read the same material at a fraction of the price. On a large pull request reviewed across several passes, that cuts the review's reading cost by roughly half to two-thirds — and the bigger the change, the bigger the saving.

Nothing about the review itself changes. Every pass still takes a genuinely fresh look at your code and finds exactly what it would have found before. The only thing that's gone is paying repeatedly for the same reading.

And you can see it working. Open any audit's Transcript tab: passes that reused earlier reading carry a "cached" marker, so the saving shows up on the same record as everything else about your audit.

Every audit PRGuard runs leaves a record: what changed, who shipped it, what was flagged, and what happened to each finding afterwards. Insights, new today, makes that history conversational — ask a question in plain language and get an answer grounded in your audit trail, with a citation for every claim.

Ask the question a dashboard can't answer. "What changed in the payments module in the last 30 days?" "Who has been changing our auth code, and what did the audits flag?" "Which findings from last month are still unfixed?" One question replaces a Slack interruption, a trawl through pull requests, and an afternoon of git archaeology — and any member of your organisation can ask, project managers very much included.

Grounded by construction, not by promise. Insights is not a chatbot with opinions. Answers are assembled from a narrow set of read-only queries over your own organisation's audit records — the AI chooses search filters, and it never sees anything beyond what those organisation-scoped queries return. Every claim cites the audit it came from, each citation links straight to the full record, and citations are validated server-side: a reference that doesn't match an audit actually retrieved for that answer is stripped.

Flagged is not the same as fixed. Every finding carries its lifecycle — open, in progress, fixed, or dismissed — so answers distinguish "was flagged in review" from "is still a problem today". That difference is usually the whole point of asking before a release goes out.

Honest about coverage. Answers draw only on what PRGuard has audited on your connected repositories. If your question reaches beyond the audit record — an uncovered window, an unconnected branch — the answer says so rather than guessing.

You'll find Insights in your dashboard sidebar, included with the Pro, Pro Team and Enterprise plans — and included in the trial, so you can try it before choosing a plan. Questions are metered as AI credits like any other PRGuard call, with daily per-member and per-organisation allowances to keep usage predictable. Ask your first question — your audit history already knows the answer.

Until now, the first sign that your organisation had run out of audit credits was an audit that didn't run. That's the wrong moment to find out — so credit depletion now announces itself ahead of time, and stops repeating itself afterwards.

A warning while there's still time to act. When a debit takes your balance below 15% of your monthly plan allowance, owners and admins get one email — audits are still running, here's where the balance stands, here's the top-up page. It fires on the crossing, not on every call afterwards, so a draining balance doesn't become a draining inbox. Top up past the line and the warning resets for next time.

A clear notice the moment audits pause. If the balance falls below the minimum needed to start an audit, a second email says exactly that: reviews on new pull requests and pushes are paused, each affected commit shows an "insufficient credits" commit status on GitHub, and auditing resumes automatically as soon as credits are available — by top-up or at your next cycle reset.

One email, not one per push. Previously, every audit blocked by an empty balance emailed every owner and admin — an active repo could turn a quiet billing state into a stream of identical messages. Blocked-audit emails are now throttled to one per organisation every six hours, and topping up (or a plan renewal, upgrade, or gifted credits) resets the throttle immediately so a fresh depletion is never silently swallowed.

The billing page tells the same story. When your balance is low or exhausted, the billing screen now opens with a banner stating exactly where you stand — amber while audits still run, red once they're paused — with a one-click jump to the top-up section. The email links land on that same spot, and the "Credits Remaining" figure changes colour to match. Same thresholds everywhere: email, GitHub commit status, and billing page never disagree.

Two upgrades this week, both aimed at the question an auditor will actually ask you: not "did you review this change?" but "prove it, and prove the record hasn't been touched since."

Append-only, all the way down. Every decision made about a finding — a status change, an auto-fix outcome, a retraction — now writes an entry in an append-only journal: who made the change, what it changed from and to, and when. Journal entries can never be edited or deleted, by anyone, including us.

Findings resolve to the exact rule that raised them. Context files now keep full version history — every edit preserves the previous text, who changed it, and when. Each audit records the precise version of every rule it ran against, so a finding from last quarter still shows the rule text as it stood at the time, even if the rule has been rewritten since. Each record also carries the audit engine's prompt version, so you can always tell which generation of the reviewer produced a finding.

See every change to a rule — and roll one back. Open any context file in Context Studio and click History for a complete timeline: each version, who changed it and when, and a line-by-line diff of exactly what changed — with the full text of any past version one click away. Need to undo an edit? Restore any previous version in a click; it’s saved as a new version, so nothing in the history is ever lost. The record is append-only — the same evidence an assessor would ask for: what the rule said, and when.

PR-only fix delivery, enforced org-wide. Auto-fixes have always landed as a reviewable pull request by default, with direct commit as a per-fix choice. Organisations that want the human-review step to be a guarantee rather than a default can now enforce it: with the policy enabled, every AI fix lands as a pull request — the direct-commit option disappears from every dispatch, anything that slips through is converted to a PR before it touches GitHub, and each conversion is logged. A control your auditor can rely on, not a preference they have to verify per commit.

As always, no action is needed — the evidence guarantees apply to every audit from today. The PR-only policy can be switched on — or off — by any organisation owner or admin from the Organisation page, and every change to it — who, when, and in which direction — is recorded in your activity log.

Two engine upgrades this week, both focused on making every audit sharper and more dependable.

Deterministic pre-scan, verified by AI. Every audit now opens with a deterministic security scanner that checks the changed lines for high-risk patterns — SQL built by string concatenation, shell commands assembled from user input, disabled TLS verification, unsafe deserialisation, hardcoded cloud keys and tokens, committed private keys, and more. Each hit is passed to the AI auditor for verification in full context: genuine problems land in your review with the usual plain-language explanation, while pattern-level false positives are filtered out before they reach you. The result is the precision and repeatability of pattern matching combined with the judgment of the AI review — in a single audit, at no extra credit cost. The scan runs on our workers, adds no LLM calls, and if it is ever unavailable, your audit simply proceeds as before.

Full provider failover. When an LLM provider suffers an outage, PRGuard already failed the main audit over to your fallback provider. Now the supporting calls — finding deduplication, detailed write-ups, and summaries — fail over too, so a mid-audit outage no longer degrades your report to terse one-liners. A transient malformed response from a provider is retried rather than downgrading the audit, and billing always attributes each call to the provider that actually served it.

As always, no action is needed — every improvement is live on your next push.

Today PRGuard goes public. Connect your GitHub organisation and every pull request and push is automatically audited against your own governance rules before it merges — no extra steps in your workflow.

What you get from day one:

• Automated PR & push audits. A GitHub App installation is all it takes. PRGuard fetches the diff, evaluates it against your Context Files, and posts its findings straight back to GitHub as a review.
• Prompt-injection screening. Every audit is pre-screened by a lightweight gatekeeper before the main review runs, so malicious diffs can't hijack the audit.
• Choose your own model. Pick between Google Gemini and Anthropic Claude for your audits.
• Context Studio. Write your coding standards, security policies, and compliance rules as Markdown and inject them into every audit.
• Credit-based, usage-linked billing. Pay for the audits you run — plan credits each cycle, with top-ups that roll over.
• Findings as tasks. Assign findings to teammates and track them to resolution from your dashboard.

This dev log is where we'll post everything new from here on. Thanks for being here at the start.