Architecture

Deterministic checks

27 of this platform's checks call a provider's own REST API (or, fortls-certificate-valid, open a real TLS connection) and compare the response against a fixed rule with no model call in the loop. A check returns one of three statuses: pass, fail, or needs-review. An authentication failure against the provider's API is always needs-review, never fail, because it proves nothing about the underlying setting.

Where Verazo AI fits in

Verazo AI does not run a check and does not decide pass or fail. Its jobs are fixed and narrower:

• Parsing a request. On the Ask page, Verazo AI reads a plain-language request and matches it against a fixed, allowlisted list of known check types. A request that does not clearly match one is reported as needing human review, never auto-executed against an unrecognized API call.
• Narrating a result. Verazo AI turns a structured check result into a plain-language summary. The status was already decided by the check before Verazo AI sees it.
• Driving the sandboxed browser fallback. For a control with no API, Verazo AI decides the next click or read inside a sandboxed, read-only browser session. The session's network egress is restricted to an allowlist of domains at the Playwright request-interception layer, enforced before Verazo AI's decision runs, not after.
• Drafting text for a human to approve. Verazo AI drafts a policy document, a vendor-questionnaire answer, and a trust-center visitor's chat response. Each draft is either shown for a person to edit and publish, or, for the trust-center assistant, scoped to answer only from what the organization already published.

Five actions that always stop for a person

No model call ever performs these five actions directly:

• Writing to the audit ledger.
• Handing evidence to an external auditor or trust-center visitor.
• Authenticating a browser session with a real customer credential.
• Changing a check's status from pass to fail, or an organization's certification-readiness status.
• A Stripe billing mutation.

The audit ledger

Every evidence record, approval, and configuration change writes one entry to a per-organization, hash-chained ledger. Each entry stores a SHA-256 hash of its own payload, a hash of that payload combined with the previous entry's hash, and an HMAC-SHA256 signature over that combined hash, computed under a secret that is never stored in the database. Verifying the chain recomputes all three for every entry in sequence order: a single edited payload, reordered entry, or forged row fails verification at the exact sequence number where it happened.

The ledger has no update or delete path in the application. Only appending a new entry is possible.

The sandboxed browser fallback

For the minority of controls with no API, a headless, sandboxed browser session reads a provider's admin console instead. The session is read-only by design: it never submits a form or changes a setting. Its network requests are intercepted and checked against a per-run domain allowlist before they leave the browser, which is real and tested against a live headless Chromium instance today. Enforcing that same allowlist at the network or firewall layer, a second, independent layer of the same control, is not yet built.