Dedicated deployments

Use the customer portal URL assigned during deployment. The CLI, MCP client, and verifier must reach the services published for that environment. A VeriProof SaaS hostname is not a substitute.

Deployment discovery publishes the portal, API, ingest, MCP, documentation, and OAuth addresses. Private network and certificate policy still apply to the machine running the CLI, MCP client, or Azure SQL verifier.

Choose either Solana or Azure SQL Database Ledger when the tenant is created. That selection is part of the tenant’s trust boundary and cannot be changed later. Local VeriProof tenants use Solana on devnet; a dedicated deployment uses the provider selected for its tenant.

Prepare access with the deployment administrator

Before enabling agent access:

Configure the customer portal identity provider. V1 supports Microsoft Entra and Okta.
Configure the deployment-local VeriProof authorization service to federate to that provider.
Register the approved CLI and MCP clients, including their exact redirect addresses.
Allow authorization code with PKCE and resource-bound MCP access tokens.
Configure the MCP resource, issuer, and client values in the deployment.
Grant users normal VeriProof roles; do not create a broad agent role.
For Azure SQL verification, grant a separate least-privilege identity access to the proof table, protected digest storage, and ledger verification procedure.

The CLI and MCP clients use the VeriProof authorization service, which connects to the configured identity provider. After an authentication change, refresh the client configuration and verify sign-in against this deployment.

The VeriProof application key remains limited to ingest and v2.2 policy evaluation operations.

Verify the selected scope

Run the CLI diagnostics and call get_my_context through MCP. Confirm the intended tenant, role, and application access. Test Azure SQL verification separately when that provider is configured; successful portal sign-in does not establish database access.