Proof for every control, not a promise
44 deterministic checks run today against your cloud infrastructure, identity providers, and public web pages, and Verazo AI only parses requests, narrates results, and never decides pass or fail.
The dashboard home screen, shown with sample data for a fictional company (“Acme Corp”) so you can see the real layout before creating an account.
Deterministic checks first, Verazo AI only for the rest
Most control checks need no model at all, because the target system already exposes a plain API this platform can call directly.
A branch-protection check calls the GitHub API and reads the answer directly. A certificate check opens a TLS handshake and reads the expiry date most browsers already trust. An MFA check calls AWS IAM's own credential report, Okta's policy API, or the Google Workspace Admin SDK, and reads the same yes-or-no answer a human reviewer would otherwise look up by hand. An accessibility scan runs axe-core against your own public pages and reads the same violations an auditor would find by hand.
The scan now walks a full multi-page journey alongside checking one page at a time, and for the rare element a script cannot judge from its markup alone, it adds a screenshot and Verazo AI's own visual read, the same describe-only role Verazo AI plays throughout this page. 44 checks run this way today, across identity providers, cloud infrastructure, cloud-resource configuration, developer tools, endpoint management, and web accessibility, and Verazo AI never decides a single one of their verdicts.
iOS and Android accessibility testing for native mobile apps. Coming soon.
Verazo AI's job is ten things, none of them running a check:
- 01Parse the request. Turn a plain-language ask like “check whether our S3 buckets are public” into one of this platform's known, reviewed control checks, or flag it for human review if it does not match one.
- 02Narrate the result. Write the plain-language summary of what a check found, after the check itself has already run.
- 03Draft a first-pass policy. From an organization's own context, for a person to review before it is used.
- 04Draft a first-pass questionnaire answer. From an organization's own self-reported context, for a person to review.
- 05Answer a trust center question. From what is already published here, nothing else.
- 06Answer a remediation guidance question. About a specific control or task already in view.
- 07Draft a first-pass accessibility fix. An illustrative suggestion for a real violation, never applied automatically.
- 08Draft a first-pass mobile test file. From an organization's own already-selected source.
- 09Make one accessibility judgment call. A structured yes/no read on a single already-selected candidate a script could not judge alone.
- 10Drive the sandboxed fallback. For the rare setting with no API, a sandboxed browser session takes the screenshot Verazo AI then describes. Its network access stops at a fixed allowlist of domains, proven by a real test against a real Chromium sandbox, not just a documented intention.
Verazo AI never decides pass or fail. That verdict is always deterministic code.
Every one of these ten jobs goes through Verazo AI the same way any other integration would, with no session persisting afterward and no credential reused.
Not a fully autonomous agent, on purpose
A wrong verdict or an unreviewed credentialed action in a compliance product costs more than a bad recommendation from a shopping app, so five actions always stop for a person to confirm them first.
- Writing to the audit record
- Handing evidence to an auditor or a trust-center visitor
- A browser action signed in with a real credential
- A change to a control's pass-or-fail status
- A change to your bill
The platform reads your settings. It does not change them.
An approval queue runs each of the five actions above, not a single agent with standing access to your GitHub, AWS, Okta, and Google consoles. A named person confirms the action before it takes effect, every time, with the confirmation itself recorded in the same hash-chained audit ledger as everything else this platform does.
A failing check reaches a person, not a queue
The moment a check fails, a real Slack message and a parallel email reach the right person, and a team member turns the fix into an assigned task with a due date.
The task closes only when the check is re-run and passes again, never from a person's own claim. A documented, time-boxed exception covers the rare control that cannot pass yet, without turning a real fail into a false pass.
Real per-framework coverage, computed from the same fictional Acme Corp data above, including the exact controls still uncovered, not just the ones already checked off.
Built for ISO 27001, SOC 2, GDPR, DORA, NIS2, and the EU AI Act
Full ISO 27001 coverage means all 93 Annex A controls, the control catalogue in ISO/IEC 27001, mapped across all four themes, alongside the AICPA Trust Services Criteria behind SOC 2 and GDPR's Article 30, 32, and 35 obligations.
EU fintechs and their critical suppliers get the same deterministic-first evidence model applied to the Digital Operational Resilience Act (DORA) and the NIS2 directive, including a real register of ICT third-party arrangements and a resilience-testing programme tracker, not just a control catalogue with no live register behind it.
A Data Protection Impact Assessment (DPIA) export generates real, section-appropriate content from your configured controls. An AI system inventory tracks Annex III risk classification and Annex IV documentation completeness for the EU AI Act, alongside the Article 50 transparency wording every provider of a customer-facing AI system needs.
A branded trust center your own prospects and auditors can visit, published at a URL you choose, with an NDA click-through gate, an approval queue for your most sensitive documents, and an AI assistant that answers only from what you have already published.
What a security-conscious buyer asks first
This platform hands an AI agent read access to your GitHub, AWS, Okta, and Google admin consoles, so these are the questions worth answering before anything else.
Why does Verazo AI need read access at all
It does not need access to run a check. Every check with an API calls that API directly, with a stored, encrypted, read-only credential. Verazo AI only sees a check's already-finished result, to write the plain-language summary of it.
What happens when no API exists
A sandboxed browser session takes a screenshot, with network access restricted to a fixed allowlist of domains at the sandbox level, not just in application code. Verazo AI describes what the screenshot shows. It does not decide pass or fail.
Who can see our evidence
Your organization, and anyone you explicitly approve through a trust center you control. Every access request is logged. No evidence reaches an auditor or a trust-center visitor without a decision recorded in the audit ledger first.
Where are our credentials stored
Encrypted at rest with AES-256-GCM, under a key separate from the one that signs your session. A browser-automation credential is short-lived and scoped to one run, never stored between runs at all.
Self-serve pricing, billed through Stripe
Creating an account and configuring your first checks is free and self-serve, with no sales call required.
Real, published tier pricing: not yet live.
Every claim on this page maps to a check you can run, a screenshot you just saw, or a number this platform measured. Create an account to run the first one against your own infrastructure.
This platform publishes what shipped, not a highlight reel. See the changelog.