Read what the publisher documents, then identify the settings, entitlements and operational evidence needed to support your own claim.
204 supplier evidence checks within 550 reviewed records. These are documentation reviews, not tests of your supplier account or certifications.
Read free. Save the version you used.
The complete answer, sources, questions and limitations are free, and you can save the JSON locally. A single purchase adds a server-saved snapshot for later authenticated retrieval. The Evidence Receipt option adds the existing unsigned delivery receipt.
Payment adds no private evidence, fresh assessment, monitoring or supplier clearance. Keep your access key to retrieve a purchase. Routine verified delivery needs no email.
GitHub audit evidence: Event coverage and export history
Does a GitHub audit export establish a complete history of repository activity?
GitHub documents different audit access methods and coverage for web and Git events. Plan, export method and retention affect what can be obtained. A returned export therefore needs an event-type and time-range check; an absent row does not by itself establish that no activity occurred.
Claim to check: An audit export contains every repository action needed for this review.
Buyer evidence still required
A dated export showing its query and event categories
Plan entitlement and exporter role
Streaming-destination continuity and retention, if longer history is required
Suggested review condition: Require additional evidence when the needed event type or time range is outside the demonstrated export coverage.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Recheck plan, available event categories, export method and archive retention.
Optional saved evidence: Preserve why an activity-history claim was limited to a specific export method and interval.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Does a GitHub audit export include every Git operation?
Which GitHub audit events are visible through the web interface?
Does GitHub audit API access depend on the plan?
Are GitHub web and Git events retained equally?
Can a missing GitHub audit event prove nothing happened?
What query parameters should accompany a GitHub audit export?
Does a streamed GitHub archive establish continuous capture?
Which organization role can obtain GitHub audit evidence?
What evidence supports a claimed repository activity timeline?
Can browser-triggered Git activity be missing from a Git export?
What should I save alongside a GitHub audit-history review?
When does a GitHub export need a coverage qualification?
Slack export evidence: Plan and conversation coverage
Does a Slack workspace export contain private channels, direct messages and the files themselves?
Slack distinguishes public-channel exports from broader conversation exports, which depend on plan and additional approval. The documentation describes messages and file links rather than a universal archive of every file. Check the approved export type and retention before using it as evidence of a complete workspace history.
Claim to check: This Slack export is a complete copy of all workspace conversations and attachments.
Buyer evidence still required
Export eligibility and any required approval
A dated export manifest identifying conversation scope
Evidence that needed file contents were retained separately from links
Suggested review condition: Qualify completeness if private conversations, retention periods or linked file contents are not accounted for.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Recheck plan, export approval, conversation scope and link availability.
Optional saved evidence: Retain the export-scope limitations behind a workspace review or migration decision.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Do all Slack plans export private channels?
Are Slack direct messages included in a public-channel export?
Does a Slack export contain file bytes or file links?
Who must approve a broader Slack export?
Does Slack export availability establish permission to collect every conversation?
What retention settings affect Slack export completeness?
Can an expired file link leave a Slack evidence gap?
What plan evidence should accompany a Slack export?
Can an agent label a Slack export complete without checking conversation types?
What is missing from a public-only Slack archive?
What should be preserved for a Slack migration evidence review?
Notion AI evidence: No-training claims and retention scope
Does Notion AI not training on customer data mean no provider retains any of it?
Notion states that customer data is not used for model training by default. Retention is a separate, plan- and feature-dependent claim, with explicit exceptions for some AI features and External Agents. Treat training, provider retention and deletion of other stored representations as distinct questions; the reviewed documentation does not verify a particular workspace.
Claim to check: No training means no retention anywhere in our Notion AI workflow.
Buyer evidence still required
The current workspace plan and feature inventory
Administrative settings for data-retaining models
A provider- and data-layer-specific retention explanation for the intended workflow
Suggested review condition: Do not infer universal zero retention from the no-training statement; obtain clarification for feature exceptions or ambiguous deletion timelines.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Recheck feature exceptions, subprocessors, workspace settings and plan.
Optional saved evidence: Retain the distinction between training policy and retention for a specific procurement question.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Does Notion AI no-training imply zero retention?
Does Notion AI retention depend on the workspace plan?
Are Notion External Agents covered by the same retention controls?
Can some Notion AI features use data-retaining models?
What settings should a Notion AI procurement review request?
Does provider retention cover Notion embeddings too?
What evidence supports a workspace-specific Notion AI privacy claim?
Can a public Notion policy prove our admin settings?
How should an agent handle ambiguous Notion deletion timelines?
Does Notion AI data policy cover a separate MCP client?
What source version should support a Notion AI review?
When should a Notion AI retention review be refreshed?
Figma AI evidence: Feature access and content-training settings
Can Figma AI be enabled while our team content is excluded from model training?
Figma documents separate controls for AI feature access and content training. Training defaults depend on plan, and switching training off applies to new content and edits. Verify the actual team or organization setting; neither a paid plan nor an AI-enabled interface alone proves the training choice.
Claim to check: Our paid Figma account automatically excludes all content from AI training.
Buyer evidence still required
A dated admin view of the applicable content-training setting
The plan and team or organization to which that setting applies
Clarification of historical-content treatment if the review requires it
Suggested review condition: Require configuration evidence before making a customer-specific no-training claim; do not infer retroactive removal from a prospective setting.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Recheck plan defaults, organization scope and the effect of later setting changes.
Optional saved evidence: Preserve the configuration questions behind a design-data procurement decision.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Is Figma AI access separate from content training?
Does paying for Figma disable model training automatically?
Which Figma admin setting controls content training?
Does turning Figma training off cover new edits?
Can a Figma training toggle prove historical model deletion?
Do Figma Starter and Enterprise training defaults differ?
Which team does a Figma training setting apply to?
Can an agent infer training status from available Figma AI tools?
What dated evidence supports a Figma no-training claim?
Does the Figma setting cover an external design assistant?
What should a Figma procurement review preserve?
When should Figma training policy be checked again?
Atlassian residency evidence: App scope and excluded data
Does pinning an Atlassian app to a region keep every account, integration and AI data flow there?
Atlassian Cloud residency applies to defined in-scope app data. The documentation lists exclusions and treats Marketplace app data separately. A pinned product location therefore does not establish that every account record, log, integration or AI-related flow stays in that region. Identify the app and data category before relying on the claim.
Claim to check: All data associated with our Atlassian organization stays in its selected region.
Buyer evidence still required
The current app-level residency status
A mapping from the buyer data categories to published inclusions and exclusions
Separate evidence for each Marketplace app or external recipient
Suggested review condition: Require additional evidence for excluded categories and integrations; do not turn a residency setting into a compliance conclusion.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Recheck app type, data-category tables, region setting and integration inventory.
Optional saved evidence: Preserve the category-by-category scope behind a regional-hosting claim.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Does Atlassian residency apply at project or app level?
Are all Atlassian user account records region-pinned?
Does a Jira region setting cover Marketplace apps?
Can Atlassian audit logs be outside residency scope?
What does an Atlassian Not Set location mean?
Do Atlassian AI data categories have their own residency scope?
Does an app pinned in Europe prove every data flow stays there?
What evidence should support an Atlassian regional-hosting claim?
Should Commercial and Isolated Cloud residency be reviewed separately?
Can an agent infer legal compliance from a pinned Atlassian region?
What buyer data categories are missing from a residency review?
When should an Atlassian residency assessment be refreshed?
Supabase backup evidence: Database recovery and stored files
Does a Supabase database backup also recover the uploaded files used by my application?
Supabase documents that database backups contain Storage metadata, not the stored object contents. Restoring a database backup does not recover objects deleted afterwards. A whole-application recovery claim needs separate evidence for files and other dependencies, together with the actual backup configuration and a suitable restore check.
Claim to check: A database backup alone establishes complete recovery of our Supabase application.
Buyer evidence still required
The backup configuration and a dated available recovery point
Separate retention and recovery evidence for stored objects
A restore review covering the dependencies the application needs
Suggested review condition: Do not approve a whole-application recovery claim when only database backup evidence is available.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Recheck backup mode, Storage handling, role credentials and application dependencies.
Optional saved evidence: Retain the distinction between database restoration and attachment recovery during supplier review.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Are Supabase Storage objects inside database backups?
Can restoring Supabase metadata recover a deleted uploaded file?
What does a Supabase database backup prove about whole-app recovery?
Which Supabase backup configuration was actually enabled?
What recovery point is available for the Supabase project?
Do custom-role credentials need separate attention after a restore?
What should a Supabase recovery test include besides tables?
Can an agent claim backups are complete without checking file storage?
What evidence supports a Supabase attachment-recovery claim?
Does plan entitlement prove a backup was successfully captured?
What should be saved for a Supabase recovery review?
When do new app dependencies require a Supabase backup review?
Vercel audit evidence: Entitlement, exporter role and event scope
Does having Vercel deployment logs mean our plan provides administrative audit evidence?
Vercel documents Audit Logs as an Enterprise feature accessible to team owners. Its event catalogue and export or streaming path need their own review. Deployment output is not equivalent to an administrative activity trail, and the availability of an audit feature does not demonstrate successful capture in the buyer account.
Claim to check: Our existing deployment logs are a complete administrative audit trail.
Buyer evidence still required
Applicable Enterprise entitlement and owner access
The event types required for the review
A dated export or verified delivery to the intended archive
Suggested review condition: Request audit-specific evidence where the supplied material is only build or runtime logging.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Recheck audit entitlements, event coverage and migration of streaming integrations.
Optional saved evidence: Preserve the evidence gap between operational logs and an administrative audit requirement.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Are Vercel Audit Logs available on every plan?
Who can export Vercel administrative audit logs?
Are Vercel build logs the same as audit logs?
Which Vercel administrative events are required for our review?
Does a Vercel audit feature entitlement prove capture was enabled?
What evidence shows a Vercel audit export succeeded?
Does a Vercel export link provide a permanent archive?
How should a SIEM integration migration affect a Vercel audit review?
What should an agent ask before claiming complete Vercel auditability?
Do Vercel runtime logs prove who changed team access?
What source version belongs in a Vercel procurement receipt?
Linear SCIM evidence: Provisioning and offboarding coverage
Does enabling Linear SCIM prove every former user and integration has lost access?
Linear documents SCIM provisioning and suspension driven by the identity provider, including group mapping and exceptions requiring attention. Disabling SCIM stops synchronization; changes may need to be pushed again after re-enablement. A supported feature is not proof of complete offboarding across users, guests and independent integration credentials.
Claim to check: SCIM support alone proves every access path is revoked when someone leaves.
Buyer evidence still required
The relevant identity-provider change and its successful synchronization
The resulting user and team state in Linear
A separate inventory and review of credentials not covered by the user update
Suggested review condition: Require account-state and integration evidence before claiming complete offboarding; resolve synchronization gaps.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Recheck synchronization, manually managed guests, plan changes and integrations.
Optional saved evidence: Retain the demonstrated provisioning scope and outstanding offboarding questions.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Does Linear SCIM support prove a user was actually suspended?
What happens when Linear SCIM is disabled?
Must changes be pushed again after Linear SCIM is re-enabled?
Does a Linear plan downgrade remove existing SCIM users?
Can manually managed Linear guests need separate offboarding?
Which identity-provider group maps to a Linear team?
What evidence shows a Linear suspension synchronized successfully?
Does Linear SCIM establish every integration credential was revoked?
Should an agent check account state after an offboarding request?
Can removing a group mapping leave a Linear team unchanged?
What should a Linear access-review snapshot preserve?
When do Linear provisioning changes require another review?
Stripe delivery evidence: Verified events and duplicate handling
Does receiving a Stripe webhook prove that payment was verified and fulfilled exactly once?
Stripe documents signature verification, possible duplicate deliveries and no guaranteed event ordering. Receiving a webhook or returning a successful response does not by itself prove a matching payment entitlement or completed fulfilment. Review authenticity, object state and the application processing record separately.
Claim to check: One successful webhook delivery proves a valid payment and exactly-once fulfilment.
Buyer evidence still required
Evidence that the handler verifies authentic events in the intended mode
The matching payment or subscription state from the provider
An idempotent processing and fulfilment record covering retries and duplicates
Suggested review condition: Refuse payment reliance on caller-supplied status or an unverified event; seek provider-bound payment evidence before delivery.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Recheck endpoint secrets, event versions, retry behavior and fulfilment idempotency.
Optional saved evidence: Retain the delivery-versus-entitlement distinction behind a payment-integration review.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Does a Stripe webhook response prove an order was fulfilled?
Can Stripe deliver an event more than once?
Does Stripe guarantee webhook event order?
Is an unverified Stripe event valid proof of payment?
Can a caller-supplied receipt establish Stripe entitlement?
What object state should support an automated payment decision?
Can manual Stripe resends overlap automatic retries?
Does a payment event timestamp establish processing order?
What evidence supports exactly-once application fulfilment?
Should an agent distinguish webhook delivery from payment settlement?
What should a Stripe payment-delivery review preserve?
When should Stripe webhook verification be rechecked?
Cloudflare Logpush evidence: Delivery gaps and retained history
Does enabling Cloudflare Logpush provide a complete searchable archive of past activity?
Cloudflare describes Logpush as delivery to a destination, without its own storage or search service. It cannot backfill historical data. A usable history therefore depends on the selected dataset, successful delivery and destination retention; missing records during a failed or disabled job cannot be treated as evidence of no activity.
Claim to check: Turning on Logpush creates a complete retained history, including earlier gaps.
Buyer evidence still required
Job configuration showing dataset and filters
Delivery-health history covering the claimed interval
Destination receipt and retention evidence for the records being relied on
Suggested review condition: Qualify the history when delivery or retention is unproven; do not infer a clean incident history from missing logs.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Recheck job health, dataset availability, filters and destination retention.
Optional saved evidence: Retain the capture and retention gaps behind a logging-completeness claim.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Does Cloudflare Logpush store logs for later search?
Can Logpush backfill events from before it was enabled?
What happens to logs while a Cloudflare Logpush job fails?
Does an empty Logpush archive prove no traffic occurred?
Which Cloudflare dataset was actually exported?
Can Logpush filters omit events needed for a review?
What evidence proves a Logpush destination retained the data?
Does Cloudflare product availability determine Logpush dataset access?
Should an agent check delivery health before interpreting missing logs?
Can destination retention shorten a Cloudflare activity timeline?
What should a Logpush evidence-review snapshot retain?
When does a changed Logpush destination require another review?
GitHub Actions: Privileged workflows and untrusted contributions
Does a pull-request workflow prove external contributions cannot access privileged execution?
GitHub warns that privileged workflow triggers combined with untrusted checkout can expose secrets or repository write access. Review triggers, checked-out revisions and job permissions together. A pull-request label or successful workflow run does not establish an isolated execution boundary.
Claim to check: All contribution checks run without privileged access.
Buyer evidence still required
Dated workflow definition and actual trigger
Effective job token and secret access
Evidence identifying the revision executed and runner isolation
Suggested review condition: Require workflow evidence before accepting a blanket claim that contributor code cannot reach privileged execution.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Recheck workflow triggers, action revisions, runner placement and credential scope.
Optional saved evidence: Save the privilege assumptions behind a supplier CI review.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Does a pull-request workflow always run without secrets?
Can a privileged workflow check out untrusted code?
What GitHub Actions trigger ran this contribution check?
Which token permissions were available to a workflow?
Does a passing CI job prove isolation?
Can self-hosted runner reuse affect contribution safety?
What evidence supports a restricted CI execution claim?
Does secret masking guarantee secrets never enter logs?
Should procurement inspect workflow permissions or only the CI badge?
How do I qualify an unverified CI isolation claim?
Can I preserve the reviewed GitHub Actions privilege boundary?
When does a changed workflow require a new supplier review?
GitLab job tokens: Allowlist and effective user access
Does a GitLab job-token allowlist grant the pipeline user access to another project?
GitLab states that adding a project to the job-token allowlist does not grant extra permissions to its members. Access also depends on the triggering user and allowed token capabilities. Review both the source-project allowlist and the effective identity before accepting a cross-project access claim.
Claim to check: The job-token allowlist fully defines cross-project pipeline authority.
Buyer evidence still required
Target project allowlist and access settings
Triggering user identity and target permissions
Required operation and token capability evidence
Suggested review condition: Require identity and operation evidence when an allowlist alone is presented as proof of effective access.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Recheck membership, job-token settings and supported operations.
Optional saved evidence: Retain the distinction between an allowed pipeline origin and authorized target operations.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Does GitLab job-token allowlisting grant project membership?
Which user permissions affect a GitLab CI job token?
Can an allowlisted pipeline access every target API?
What evidence defines cross-project GitLab CI access?
Does removing user access affect an allowlisted job?
Are job-token capabilities equivalent to a personal access token?
Which project controls incoming GitLab job-token access?
Does a successful job prove every cross-project operation is permitted?
How should a procurement review describe a job-token allowlist?
What should an agent check before retrieving another project artifact?
Can I save the GitLab pipeline-authority review?
When should GitLab job-token permissions be revalidated?
Datadog Logs: Index exclusion is not data deletion
Does excluding a Datadog log from an index mean it was deleted or never collected?
Datadog documents that index-excluded logs can still reach Live Tail, metrics and archives. Exclusion controls searchable indexing rather than proving deletion from every destination. Check the complete configured route before relying on a no-retention or no-event claim.
Claim to check: Logs missing from an index were not retained anywhere.
Buyer evidence still required
Dated index and exclusion configuration
Archive and downstream destination inventory
Evidence for the relevant event interval and retention policy
Suggested review condition: Qualify deletion or absence claims when only index-search evidence is available.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Recheck exclusion filters, archive destinations and retention settings.
Optional saved evidence: Preserve why searchable coverage and retained data were treated separately.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Does Datadog index exclusion delete a log?
Can excluded Datadog logs still reach an archive?
Can a log absent from search appear in Live Tail?
Does a Datadog no-match result prove no event occurred?
Which routes must be checked for a no-retention claim?
Can excluded logs still support metrics?
What evidence distinguishes indexing from storage?
How should procurement review a log-deletion statement?
Do index filters describe every log destination?
What interval should a log-coverage review record?
Can I save the Datadog retention boundary?
When should a changed archive route trigger review?
Elasticsearch: Combined roles can broaden data access
Does one restrictive Elasticsearch role prove a user cannot read other documents or fields?
Elastic documents that permissions from multiple roles can combine to broaden access to the same index. A role without the relevant restriction can defeat the intended document or field limit. Review the complete role assignment, not one restrictive role in isolation.
Claim to check: A restrictive role proves the identity only sees the intended subset.
Buyer evidence still required
Complete role assignments for the identity
Definitions for every role covering the target index
Authorized test evidence of effective read scope
Suggested review condition: Require the full role combination before accepting a restricted-data-access claim.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Recheck role membership, index patterns and unrestricted grants.
Optional saved evidence: Save the role-combination evidence behind a data-separation decision.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Can multiple Elasticsearch roles broaden document access?
Does one restricted Elastic role override an unrestricted role?
What happens when field restrictions differ across roles?
Which role assignments matter for an Elasticsearch access review?
Can an agent infer read scope from one role name?
Does a document-level rule prove tenant isolation?
What evidence should accompany a restricted-search claim?
Can a new role change existing effective data access?
How should procurement check Elasticsearch data separation?
Does a successful query prove only intended records are visible?
Can I preserve an Elastic role-union review?
When should an agent request complete role evidence?
Sentry scrubbing: Incoming events and attachment handling
Does enabling Sentry server-side scrubbing prove sensitive data never left the application or was removed historically?
Sentry describes server-side scrubbing and states that new advanced rules apply to incoming events. Its JavaScript attachment guidance provides a pre-send handling point. These controls do not by themselves prove that sensitive data never left the application or that older stored material was removed.
Claim to check: Enabling scrubbing proves zero sensitive-data transmission and historical cleanup.
Buyer evidence still required
Client pre-send handling and attachment configuration
Server scrubbing rules with activation dates
Separate evidence for historical data removal and downstream copies
Suggested review condition: Require transmission and historical-retention evidence before accepting a zero-disclosure claim.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Recheck SDK hooks, safe-field exemptions, rule activation and attachment handling.
Optional saved evidence: Retain the difference between future-event filtering and retrospective cleanup.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Does Sentry server scrubbing prevent data from leaving my app?
Do new Sentry scrubbing rules clean earlier events?
Can Sentry attachments be changed before sending?
Which Sentry fields are exempt from scrubbing?
What evidence supports a zero-sensitive-data claim?
Does a server setting prove the client removed attachments?
How should I record when scrubbing rules became active?
Can old retained events require separate review?
What should procurement ask about error-reporting data flow?
Does an enabled scrubber prove every sensitive value was recognized?
Can I save the Sentry data-handling review?
When should an agent qualify a historical cleanup claim?
Okta service apps: OAuth grants and administrative roles
Are OAuth scopes alone sufficient evidence of the authority granted to an Okta service app?
Okta documents both scope grants and administrative role assignments for service apps. Roles constrain permissions and resources; an organization setting can also automatically assign a broad administrative role. Review the app grants, roles and organization settings together before claiming least-privilege access.
Claim to check: The service app scope list completely establishes its effective authority.
Buyer evidence still required
Granted Okta API scopes
Admin role assignments and applicable resource sets
Relevant organization setting and dated access review
Suggested review condition: Require role and resource evidence when scope names alone are offered as a least-privilege claim.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Recheck role assignments, scope grants, resource sets and automatic-role settings.
Optional saved evidence: Preserve the reviewed identity, role and scope combination for a service integration.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Do Okta OAuth scopes alone define service app permissions?
Which admin roles are assigned to an Okta service app?
Can organization settings grant a service app broad authority?
What resource set limits an Okta custom role?
Does a successful token request prove least privilege?
What evidence supports an Okta integration access review?
Can changing roles change the authority of a service app?
Which authentication method is documented for Okta-scoped service apps?
How should procurement assess non-human Okta access?
Does a read-looking scope name prove every grant is read-only?
Can I save the Okta scope-and-role review?
When should an agent request effective-role evidence?
Does an empty Auth0 tenant-log search establish that no authentication event occurred?
Auth0 documents plan-dependent retention and possible indexing delay. A query result needs a time-range, plan and collection check before it supports an absence claim. Longer history requires evidence of an external logging arrangement; the feature description does not establish that one was operating.
Claim to check: An empty tenant-log query proves no relevant authentication activity.
Buyer evidence still required
Tenant plan and applicable retention window
Dated query with filters and requested interval
External export continuity and storage evidence where needed
Suggested review condition: Qualify absence claims when retention or ingestion coverage is not demonstrated.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Recheck subscription, retention, ingestion delay and external logging continuity.
Optional saved evidence: Retain the coverage limit behind an authentication-history review.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Does an empty Auth0 log query prove no login occurred?
Does Auth0 log retention depend on subscription?
Are Auth0 tenant logs guaranteed real-time?
Can a recent Auth0 event appear after a delay?
What evidence supports a longer Auth0 activity history?
Does offering log streaming prove our tenant exported logs?
Which query interval should an authentication review preserve?
Can expired logs leave a gap in an Auth0 investigation?
How should procurement assess identity-log availability?
What evidence distinguishes no results from no activity?
Can I save the Auth0 log-coverage review?
When should an agent refuse an unsupported absence claim?
1Password service accounts: Vault scope and allowed actions
Does giving an agent a 1Password service account restrict it to the intended secrets?
1Password describes service accounts with selected vaults, Environments and permitted actions, independent of an individual identity. Effective secret access depends on those choices. Check the configured scope and usage evidence before assuming a token exposes only the secrets needed for the task.
Claim to check: A service account token only exposes the intended automation secrets.
Buyer evidence still required
Dated account scope and allowed-action configuration
Inventory linking required secrets to approved containers
Usage report and credential lifecycle evidence
Suggested review condition: Require configured scope evidence before providing secret access to an agent.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Recheck vault and Environment access, permitted actions and credential lifecycle.
Optional saved evidence: Save the secret-container and action boundaries used in an automation review.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Which vaults can a 1Password service account access?
Can service accounts have different allowed actions?
Is a 1Password service account tied to an individual employee?
Do service account tokens automatically limit access to one secret?
What evidence supports an agent secret-access decision?
Can service accounts access selected Environments?
How can usage evidence support a secret-access review?
Does an API token name prove its actual permissions?
What should procurement request for automation secret management?
Can broad vault access exceed a narrow agent task?
Can I preserve the reviewed 1Password access scope?
When should an agent request a narrower secret permission?
Microsoft Graph: Delegated and application authority
Does a Microsoft Graph permission name mean the same access with and without a signed-in user?
Microsoft distinguishes delegated access on behalf of a user from application access under the app identity. Delegated permissions are bounded by the access of that user, while application permissions can reach data without a user present. Review the permission type, consent and resource controls before judging the scope from its name.
Claim to check: The permission name alone describes the app data-access boundary.
Buyer evidence still required
Granted permissions including delegated or application type
User permissions or application resource restrictions
Consent record and any additional role requirements
Suggested review condition: Require permission-type and effective-resource evidence before approving broad organizational access.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Recheck grants, consent, user roles and application resource limits.
Optional saved evidence: Retain the access-model distinction behind a Microsoft 365 integration decision.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Are Graph delegated and application permissions equivalent?
Can a Graph app access data without a signed-in user?
Does delegated Graph access exceed the access of that user?
What does Files.Read.All mean for different Graph access types?
Who granted consent to a Microsoft Graph application?
Can Graph API access also depend on administrative roles?
Does a familiar scope name prove limited organizational access?
What evidence should procurement request for a Graph connector?
Can a background app act under its own identity?
How should an agent document delegated resource boundaries?
Can I save the Graph permission-type review?
When should a permission change trigger a fresh access assessment?
Google Workspace: Delegation scopes and impersonated users
Does Google Workspace domain-wide delegation give a service account unlimited direct access to user data?
Google describes domain-wide delegation as authority to impersonate a specified user for API calls, bounded by authorized OAuth scopes and the permissions of that user. Review the delegated client, scopes and selected user. Approval to delegate is distinct from permission for every proposed collection or action.
Claim to check: Domain-wide delegation establishes unlimited direct access to all Workspace data.
Buyer evidence still required
Admin delegation record for the client and scopes
Selected user and relevant resource permissions
Approved operation and evidence of effective access
Suggested review condition: Require the intended user, scopes and task purpose before relying on a domain-wide delegation claim.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Recheck delegation grants, impersonated identity, resource access and service-account custody.
Optional saved evidence: Preserve the impersonation and scope boundary behind a Workspace integration review.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Does Workspace domain-wide delegation grant unlimited data access?
Which user is impersonated in a delegated Google API call?
Do delegated OAuth scopes limit Workspace API access?
Can a service account access data the impersonated user cannot?
Does delegation remove the need for an approved task purpose?
What evidence supports a domain-wide delegation review?
Which client ID has Workspace delegation authority?
Can changing the impersonated user change accessible data?
Does a Google service account equal a normal Workspace member?
How should procurement assess unattended Workspace access?
Can I save the Workspace delegation review?
When should an agent ask before accessing data belonging to another user?
AWS CloudTrail: Management history is not every data access
Does an empty CloudTrail event history prove no application data was accessed?
AWS distinguishes management events from data events. Default trail and event-store coverage does not include data events, and Event history is not a data-event search. A conclusion about application data access needs evidence of the relevant event category, resource selectors, period and destination.
Claim to check: CloudTrail is enabled, so every access to application data is searchable.
Buyer evidence still required
Dated trail or event-store configuration and resource/event selectors
Coverage of the exact API operation and Region during the period
Destination, retention and query evidence, including filters
Suggested review condition: Do not infer no data access from management-only history or an unverified capture period.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Recheck event selectors, resource coverage, trail status and retention.
Optional saved evidence: Preserve the coverage questions behind an access-history review.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Does empty CloudTrail history prove no data access?
Are data events enabled by default in a new trail?
Which event category covers an object-read claim?
Can Event history substitute for a data-event store?
What resource selectors should procurement request?
Does one Region establish account-wide log coverage?
Could a query filter hide a captured event?
What evidence establishes historical trail configuration?
Does current logging recover earlier uncaptured activity?
What should an agent say when data-event coverage is unknown?
Can I save the source limits behind an access review?
When should CloudTrail coverage evidence be refreshed?
Azure Activity Log: Control plane and resource operations
Does the Azure Activity Log show everything an application did inside a resource?
Microsoft describes Activity Log as control-plane evidence and resource logs as the place for data-plane operations. Activity Log has a default retention window; diagnostic routing can retain entries elsewhere. Buyers should establish the required operation and destination instead of treating one activity view as a complete application history.
Claim to check: The subscription Activity Log is a complete record of application data operations.
Buyer evidence still required
Operation-to-log-category mapping for the resource
Dated resource logging and diagnostic-routing configuration
Retention settings and retrieval evidence for the requested period
Suggested review condition: Qualify completeness when only control-plane history or the default retention view is available.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Recheck resource log categories, diagnostic routes and retention policies.
Optional saved evidence: Save the distinction between resource administration and application activity evidence.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Does Azure Activity Log include application data-plane activity?
Which log supports a claim about resource administration?
Can a subscription activity view prove a file was never read?
What evidence should I request for Azure resource logging?
Does exporting Activity Log add missing data-plane events?
How does retention affect a historical investigation?
Which destination holds the required Azure logs?
Can a current setting prove historical capture?
What should an agent do with an incomplete date range?
Does resource creation evidence prove application behaviour?
Can I save a control-plane coverage review?
When should an Azure logging claim be checked again?
Google Cloud: Data Access defaults and viewer permissions
Can a missing Google Cloud Data Access result mean the event was never logged?
Google documents that Data Access logging usually needs explicit enablement, with service-specific exceptions including parts of BigQuery. Viewing those logs also needs appropriate permissions. Check service settings, inherited configuration, exemptions and viewer access before interpreting an empty result.
Claim to check: A general log viewer can establish complete Data Access history without checking configuration.
Buyer evidence still required
Applicable audit configuration and inherited settings for the service
Exempted principals and routing/retention evidence
Viewer permissions and the exact search scope
Suggested review condition: Do not turn absent results into an absence-of-access claim without capture and viewer evidence.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Recheck audit configuration, exemptions, service exceptions and viewer roles.
Optional saved evidence: Preserve the enablement and visibility conditions used in a cloud-data review.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Can missing Google Cloud audit results reflect viewer permissions?
Are Data Access logs enabled for every service?
Does the BigQuery exception apply to every BigQuery API?
What inherited audit settings affect my project?
Could an exempted principal explain missing access records?
Does a Logs Viewer role expose every audit category?
Which evidence establishes the service logging state?
Can routing change where Data Access records appear?
Does enabling logs now prove earlier coverage?
What should an agent ask before claiming no cloud access?
Can I save a reviewed logging-visibility boundary?
When should Google audit permissions be rechecked?
Microsoft Purview: Retention depends on licences and policies
Does buying an audit licence preserve every existing Microsoft 365 audit record for longer?
Microsoft ties audit retention to licensing, record coverage and policy priority. Custom policies can override defaults, and later changes do not update previously committed audit items. Verify the applicable identity, record type and policy at ingestion before claiming a complete extended history.
Claim to check: A premium audit purchase automatically extends all historical audit records.
Buyer evidence still required
Licence assignment and audited identity for the relevant period
Matching retention policies and their priorities
Ingestion dates and available historical records
Suggested review condition: Do not promise retrospective retention or uniform coverage from a product licence alone.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Recheck policy priority, record categories and licence assignments.
Optional saved evidence: Save the licence, policy and historical-scope questions used in an audit procurement decision.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Does buying an audit licence extend old records retrospectively?
Which user needs the retention entitlement?
Can a custom audit policy shorten a default duration?
Do all record types receive the same retention?
What evidence establishes policy priority?
When is an audit item lifetime determined?
Does a tenant subscription prove every user is covered?
How should an agent review a claim of complete annual history?
What happens when the relevant policy was introduced later?
Can a current licence screenshot prove past retention?
Can I save the scope of a Purview retention review?
Vault: Audit availability, coverage and hashed values
Does a working Vault server prove its secret-access audit trail is complete?
Vault distinguishes operational logs from audit devices, which must be enabled on a new cluster. With auditing enabled, a request requires a successful write to at least one enabled device; one device need not contain the whole history. Documented endpoint exceptions and hashed values also limit interpretation.
Claim to check: Operational server logs alone prove complete secret-access auditing.
Buyer evidence still required
Enabled audit-device configuration and dates
Combined device records and evidence of collection/retention
Relevant endpoint exceptions and hashed-field interpretation
Suggested review condition: Do not certify a complete access history from process logs, a single device or uninterpreted hashes.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Recheck device changes, availability, exceptions and version-specific logging behaviour.
Optional saved evidence: Preserve the evidence questions behind a secrets-service audit claim.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Does a running Vault server prove auditing is enabled?
Are Vault operational logs the same as audit logs?
Can one audit device miss events saved by another?
What happens when every enabled audit device fails?
Do audit hashes reveal the original secret values?
Are all Vault endpoints audited?
What evidence shows when auditing began?
Does disabling an audit device erase existing logs?
Can a new hashing key explain unmatched audit values?
What should procurement request for an audit availability claim?
Can I save the documented Vault audit boundary?
When should a secrets-service logging review be repeated?
Anthropic API: Retention scope and model-specific exceptions
Does an Anthropic API retention statement apply to every feature and model?
Anthropic describes a standard API deletion period with exceptions for features such as stored files, agreements, policy enforcement and legal obligations. Designated covered models have additional retention conditions, with eligibility exceptions described separately. Confirm the exact product, model, workspace and agreement before accepting an unconditional zero-retention claim.
Claim to check: One API retention promise covers every model, feature and saved conversation.
Buyer evidence still required
Exact product/model and feature inventory
Workspace retention controls and applicable agreement or eligibility notice
Documented exceptions, feedback handling and retained-file lifecycle
Suggested review condition: Do not generalise API or zero-retention terms across features, products or model designations.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Recheck model designation, feature use, workspace retention and agreement changes.
Optional saved evidence: Save the dated exclusions and questions behind a model-service procurement review.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Does API retention apply to every Anthropic product?
Can stored files have a different lifecycle from ordinary API calls?
Do covered models have additional retention conditions?
What evidence establishes zero-retention eligibility?
Does a workspace setting cover other workspaces?
Can feedback submissions have separate retention?
What exceptions qualify a deletion-period claim?
Do saved conversations follow the ordinary API lifecycle?
Which model designation should procurement record?
Can an agent assume a contractual exception without evidence?
Can I save the version of retention terms reviewed?
When should a model-service retention review be refreshed?
Amazon Bedrock: Invocation logging and retained content
Can Bedrock invocation logging retain prompts even when I only want operational diagnostics?
AWS documents optional invocation logging that can collect supported request/response content and metadata into configured CloudWatch Logs or S3 destinations. Coverage depends on the endpoint and operation. Logging settings therefore need their own review; neither enabled logging nor absent logs establishes universal capture or zero retention.
Claim to check: Invocation logs are only technical metadata, or cover every model endpoint.
Buyer evidence still required
Invocation-logging configuration and selected content categories
Supported endpoint/operation mapping for actual requests
Destination access, retention and removal evidence
Suggested review condition: Do not accept metadata-only or complete-capture claims without checking content settings and endpoint coverage.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Recheck endpoint changes, enabled content categories and destination lifecycle.
Optional saved evidence: Save the prompt-logging boundary behind a cloud-model data-handling decision.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Can Bedrock diagnostics store prompt and response content?
Are invocation logs enabled by default?
Does logging cover every Bedrock endpoint?
What should I verify before enabling model content logs?
Which destination could retain submitted documents?
Does no invocation log prove no model request occurred?
Can endpoint choice change capture coverage?
Which account and Region own the logging destination?
What evidence supports a metadata-only logging claim?
Does changing collection prove older destination copies are removed?
Can I save a reviewed prompt-logging configuration checklist?
When should Bedrock logging evidence be refreshed?
Dropbox: Regional file storage has a defined scope
Does a Dropbox storage region prove every data category stays in that region?
Dropbox states that the selected server location applies to team file data permanently stored at rest. Migration has eligibility conditions and needs confirmation. That statement alone does not establish the location of every metadata, processing or connected-application flow.
Claim to check: A regional storage option proves all Dropbox-related data processing is regional.
Buyer evidence still required
Team storage-location or completed-migration confirmation
A data-category map distinguishing files at rest from other flows
Applicable documentation and contractual scope for the additional categories
Suggested review condition: Keep the claim limited to confirmed file data at rest until broader evidence is supplied.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Recheck team migration, plan and connected-application data flows.
Optional saved evidence: Preserve the scope and unresolved categories behind a regional-storage review.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Does a Dropbox region cover every data category?
What does permanently stored file data mean for a residency claim?
Does migration eligibility prove migration has completed?
Which evidence confirms the team storage location?
Can a regional file copy establish where an AI connector processes it?
Should metadata and file content be reviewed separately?
Can an agent assume every plan permits migration?
Does a billing address prove the current storage region?
Which data flows remain outside a file-at-rest statement?
What should procurement ask before accepting a regional-processing claim?
Can I save the documented residency scope?
When should Dropbox storage-location evidence be checked again?
Box: Link audience and recipient actions are separate
Does sending a Box link only to a colleague keep the linked file private?
Box documents different shared-link audiences and recipient actions. The access setting controls who can use the link; editing, viewing and downloading are separate choices constrained by administrators. The people receiving the message are not sufficient evidence of the effective link audience.
Claim to check: A privately sent shared link is necessarily restricted to the named recipients.
Buyer evidence still required
Effective shared-link audience and expiration/password settings where applicable
Allowed recipient actions and administrator restrictions
Existing collaborator access and intended recipient list
Suggested review condition: Do not infer link restrictions from delivery channel; require effective audience and action settings.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Recheck link settings, folder access and administrator restrictions.
Optional saved evidence: Save the disclosure questions used before distributing a supplier document link.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Does privately sending a Box link make the link private?
What is the difference between link audience and download permission?
Can an open link be used without an invitation?
Does inviting a collaborator work like creating a shared link?
What evidence shows who can use a document link?
Can administrator settings limit recipient actions?
Does view-only mean the same as view and download?
Could existing collaborators retain access under a narrower link?
What should an agent check before forwarding a supplier file?
Can message recipients prove the effective access audience?
Twilio: Restricted keys still need an action review
Does a restricted Twilio API key make an agent communication task read-only?
Twilio Restricted API keys select permissions that map to endpoint actions. A restricted key can still permit creating calls or other state-changing operations. The feature also has SDK-token limitations. Review the actual permission mapping and task authority instead of treating the word restricted as a read-only guarantee.
Claim to check: Any restricted API key is safe to use for read-only communication analysis.
Buyer evidence still required
Non-secret key type and permission inventory
Mapping from approved task to granted endpoint actions
Evidence of task approval and the intended server or client-SDK integration
Suggested review condition: Require approved state-changing actions; do not infer a spending limit or read-only access from the key label.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Recheck permission changes, endpoint requirements and integration type.
Optional saved evidence: Save the endpoint-action review behind granting a communication agent credentials.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Does a restricted Twilio key mean read-only access?
Can a restricted key still create calls?
What endpoint actions does the key actually permit?
Does a permission label establish a spending limit?
Can restricted keys create client-side SDK Access Tokens?
What should procurement request without exposing a key secret?
Does authorising analysis permit contacting customers?
Could a denied call reflect missing permission rather than an invalid credential?
How should an agent compare granted actions with its task?
What evidence supports least-privilege communication access?
GitHub push protection: Exceptions and reviewer authority
Does enabled push protection prove no secret can be pushed?
GitHub documents bypass paths. With delegated bypass, contributors without bypass privileges need reviewer approval; without it, contributors can bypass at their discretion. Review exception permissions and decisions before interpreting the feature as a no-secret guarantee.
Claim to check: Push protection prevents every secret-containing push.
Buyer evidence still required
Effective bypass configuration and privileged identities
Designated human or app reviewers and their authority
Exception decisions for the relevant repository and period
Suggested review condition: Do not accept an absolute prevention claim from enablement alone.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Recheck reviewer permissions, bypass policy and app approvals.
Optional saved evidence: Preserve the exception checks used in a source-control procurement review.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Does push protection guarantee a repository contains no secrets?
Who can approve a blocked secret push?
Can contributors bypass without delegated review?
What evidence shows exception oversight is active?
Can a GitHub App review bypass requests?
Does a successful push prove no secret was detected?
Which roles have direct bypass privileges?
What should procurement request about secret-scanning exceptions?
Can an approved exception still contain sensitive material?
Does masking a GitLab variable prevent a job from disclosing it?
GitLab warns that masking is not a guarantee against malicious scripts and that both masked and protected variables can be compromised by code given access. Log display controls and job-access restrictions address different questions. Review the pipeline and variable availability before accepting an isolation claim.
Claim to check: Masked or protected variables cannot leave CI jobs.
Buyer evidence still required
Variable availability in the exact pipeline context
Review of code and dependencies allowed to use the variable
Relevant masking, hiding and protection settings
Suggested review condition: Do not equate log masking with isolation from executing code.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Recheck pipeline changes, variable availability and branch rules.
Optional saved evidence: Save the evidence checklist for a supplier CI-secret handling claim.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Does masking a CI variable prevent exfiltration by a job?
Can malicious pipeline code access a protected secret?
How do log masking and variable availability differ?
What evidence identifies the code allowed to receive a secret?
Does hiding a value in settings stop runtime access?
Which branch or environment rules govern CI variables?
Should an agent trust a masked-log screenshot as isolation proof?
Can pipeline changes invalidate a secret-handling review?
What should procurement ask about build-secret exposure?
How should an agent qualify a protected-variable claim?
Can I preserve a CI-secret review without storing the secret?
Slack SCIM: Deactivation is not permanent deletion
Does a successful Slack SCIM offboarding action prove user data was erased?
Slack states that SCIM can deactivate users but cannot permanently delete them. Its token authority also depends on the generating account role. A deactivation result supports an identity-lifecycle claim, not a general data-erasure claim.
Claim to check: SCIM offboarding permanently erases the user and their data.
Buyer evidence still required
Identity and organisation scope of the offboarding result
SCIM actor role and authority over the target user
Separate evidence for any claimed content or personal-data deletion
Suggested review condition: Require separate erasure evidence when the requested outcome exceeds deactivation.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Recheck SCIM actor roles and the supplier deletion process.
Optional saved evidence: Save the distinction between identity deactivation and data-erasure evidence.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Does SCIM deactivation prove user data was erased?
Can Slack SCIM permanently delete a user?
Which role controls the SCIM token authority?
Can an administrator token change an owner account?
Does Enterprise SCIM act at workspace or organisation scope?
What evidence supports an offboarding completion claim?
Should an agent report deletion after deactivation?
Can a deactivated email identity affect reprovisioning?
What should procurement ask about identity and content removal?
Which additional evidence is needed for an erasure claim?
Can I save the source-bound offboarding distinction?
Does an Atlassian app access rule block every API data category?
Atlassian distinguishes covered data from exempt data in its API references. Rules can block covered data, while exempt categories are not blocked by those rules. Map the actual API operations and data categories before accepting a complete app-isolation claim.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Recheck API coverage references and app capability changes.
Optional saved evidence: Preserve the covered-versus-exempt distinction for an app procurement review.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Does an app access rule block every data category?
What does exempt mean in an Atlassian API reference?
Which operations are covered by the buyer rule?
Can a blocked app still access exempt information?
Does rule enablement establish complete app isolation?
What evidence should an agent request for API coverage?
Can a new app capability change the review scope?
How should procurement record an uncovered data category?
Does a denied content request settle metadata access?
Which operation references should a saved review identify?
Notion sharing: Broad grants and child-page permissions
Does moving a Notion parent page to Private revoke every child-page grant?
Notion says that moving a shared page to Private removes others from that parent, while subpage grants remain. It also applies the broadest access granted to a user. Review parent, child and workspace grants separately before reporting a complete access revocation.
Claim to check: Making a parent private removes every route to its child content.
Buyer evidence still required
Current parent and subpage sharing settings
Workspace or other broader grants for affected users
Outcome checks for the intended audience after the change
Suggested review condition: Do not claim complete revocation from the parent setting alone.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Recheck page moves, subpage grants and workspace access.
Optional saved evidence: Save the sharing-scope evidence needed for a document handover or offboarding review.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Does making a parent page private revoke child-page access?
Which Notion permission wins when grants overlap?
Can workspace access broaden a direct read-only grant?
Do new subpages inherit parent permissions?
What should I check after moving a shared page?
Can an agent report revocation from one settings change?
Which users retain separate child-page grants?
What evidence supports a complete document-access review?
How should procurement assess overlapping page permissions?
Does a private sidebar location prove all content is private?
SharePoint links: Transferable access and remaining grants
Does sending a SharePoint link to one recipient limit access to that person?
Not necessarily. Microsoft describes Anyone links as transferable: another holder can use the link. Deleting a link revokes that link, while other permissions can still provide access. Review the link type and independent grants before claiming a named-only audience or complete revocation.
Claim to check: A privately sent link is restricted to its named recipient.
Buyer evidence still required
Actual link type and current link settings
Intended audience and independent resource grants
Revocation evidence for every access route within scope
Suggested review condition: Clarify link audience before sharing sensitive content or claiming revocation.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Recheck link recreation, forwarding policy and other grants.
Optional saved evidence: Save the link-audience distinction behind a collaboration procurement decision.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Does privately sending a link restrict it to one person?
Can an Anyone link be forwarded outside the organisation?
Does deleting a sharing link remove other permissions?
Which SharePoint link type was actually created?
What evidence supports a named-recipient access claim?
Can an agent infer privacy from the delivery channel?
Does revoking one link revoke every access route?
How do organisation links differ from Anyone links?
What should procurement ask about transferable file access?
Which permission evidence should a sharing review retain?
Google Drive: Folder inheritance and limited access
Can a file-level sharing change remove access inherited from a Drive folder?
Google explains that folder access is inherited by contained files and subfolders. Reducing inherited access requires addressing the folder-level permission; limited-access folders provide a separate boundary. Review the path and explicit grants rather than interpreting a single file setting in isolation.
Claim to check: Changing one file permission removes all inherited folder access.
Buyer evidence still required
Parent-folder access and relevant group membership
Direct grants and limited-access folder configuration
Observed access for the intended identities after changes
Suggested review condition: Require inherited-permission evidence before claiming file access is removed.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Recheck folder moves, group membership and limited-access changes.
Optional saved evidence: Save the inheritance checks behind a document-access procurement review.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Can a file permission override inherited folder access?
Which parent folder grants access to a document?
How does limited folder access change the review?
Can a file move alter its effective audience?
What evidence should an agent request for inherited sharing?
Does one file settings screenshot show every grant?
Can group membership preserve access after a direct grant is removed?
What should procurement ask about shared-folder boundaries?
How should an agent qualify a file revocation claim?
Which folder configuration should a saved review identify?
Dropbox recovery: Plan windows and permanent deletion
Does a Dropbox subscription guarantee every deleted file can be restored?
No. Dropbox ties recovery to the plan window, deletion type and restoration permissions. Permanently deleted files are outside normal recovery, and the page says Support cannot recover them or files outside available history. A product subscription alone does not prove recoverability of a particular file.
Claim to check: Every deleted file remains recoverable because Dropbox is subscribed.
Buyer evidence still required
Applicable recovery period and deletion timestamp
Whether deletion was permanent or recoverable
Restoration authority and outcome for the relevant file
Suggested review condition: Require file-specific recovery evidence before promising restoration.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Recheck plan changes, retention windows and deletion events.
Optional saved evidence: Preserve the conditions behind a supplier recovery claim.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Can every deleted cloud file be restored?
Does permanent deletion remain recoverable through Support?
Which Dropbox plan window applies to a lost file?
Does a subscription prove a file is still within history?
What permissions are needed to restore a shared file?
How does version recovery differ from undeleting a file?
Can an agent promise recovery without a deletion timestamp?
What evidence should procurement request about restore limits?
Does an add-on change the available recovery period?
Which deletion state should a saved review record?
Can I retain the source version for a recovery decision?
Box retention: Folder removal and retained versions
Does removing a file from a Box folder prove permanent deletion under retention?
No. Box says retained files can be removed from folders but remain in trash until retention expires. Policy, assignment and file-version retention are separate objects; expiry may remove the policy or trigger disposition. Review the actual assignments and outcome rather than treating folder absence as erasure.
Claim to check: A file removed from its folder has been permanently erased.
Buyer evidence still required
Applicable retention policies and assignments
File-version retention and trash state
Configured disposition and evidence of its completed outcome
Suggested review condition: Do not report erasure from folder absence alone.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Recheck assignments, extensions and disposition settings.
Optional saved evidence: Save the retention and disposition distinction for supplier evidence review.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Does a missing folder item prove permanent deletion?
Can a retained Box file remain in trash?
What is the difference between a policy and its assignment?
Which file version is under retention?
Does expiry always trigger automatic deletion?
What evidence shows disposition actually completed?
Can retention be extended for a file version?
What should procurement ask about retained deleted content?
Can an agent infer erasure from a successful remove operation?
Which retention object should a saved review identify?
Can I preserve a Box disposition review?
When should retention assignments be checked again?
S3 Object Lock: Protected versions and current visibility
Does locking an S3 object version prevent new versions or delete markers?
No. AWS describes Object Lock as protection for specified versions. Retention and legal holds do not prevent a new version or a delete marker above the protected version. Distinguish retained-version protection from the object currently returned by an ordinary lookup.
Claim to check: A locked object key can never be replaced or disappear from current lookup.
Buyer evidence still required
Protected version identifier and applicable lock
Current version or delete-marker state
Retrieval evidence for the exact retained version
Suggested review condition: Require version-specific evidence before claiming immutability of the current object view.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Recheck lock settings, version changes and retrieval procedures.
Optional saved evidence: Save the version and visibility distinction used in an evidence-retention review.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Does an object lock prevent new versions?
Can a delete marker hide a retained object version?
Which S3 version is actually protected?
Does an ordinary lookup prove the retained version is gone?
How do legal holds and retention periods relate to versions?
What evidence supports a specific immutable-version claim?
Can an agent confuse a key with a version identifier?
Does a lock establish current object visibility?
What should procurement ask about retained evidence retrieval?
Which version bindings should a saved review contain?
Can I preserve the object-lock visibility boundary?
When should object retrieval assumptions be reviewed?
Azure Blob soft delete: Recovery scope and exceptions
Does blob soft delete also recover a deleted container or storage account?
No. Microsoft separates blob and container protection, and blob soft delete does not cover account deletion. The documentation also lists overwrite, metadata and permanent-delete limits. Review the exact deletion scenario and enabled protection before promising recovery.
Claim to check: Blob soft delete protects every storage loss scenario.
Buyer evidence still required
Resource level and operation that caused loss
Protection enabled before the event and applicable retention
Relevant permanent-delete, overwrite and namespace settings
Suggested review condition: Require scenario-specific protection evidence before a recovery assurance.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Recheck namespace, deletion controls and retention changes.
Optional saved evidence: Preserve the recovery-scope checklist for a storage supplier review.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Does blob soft delete recover a deleted container?
Can blob protection recover a deleted storage account?
Are metadata changes covered by soft delete?
Do overwrite protections differ with hierarchical namespaces?
Can permanent deletion override a recovery window?
What evidence shows protection was enabled before the loss?
Does an empty listing prove a soft-deleted blob is unrecoverable?
Which resource level should a recovery review identify?
What should procurement ask about storage recovery exceptions?
Can an agent promise restoration from one enabled setting?
Can I save the documented Azure recovery boundary?
When should storage protection assumptions be retested?
Cloudflare R2: Location hints and jurisdiction restrictions
Does an R2 location hint guarantee a storage jurisdiction?
No. Cloudflare describes location hints as best-effort placement preferences and documents jurisdiction restrictions separately. A bucket jurisdiction cannot be changed after creation. Review the actual bucket configuration and relevant service path; a hint is insufficient evidence of a jurisdiction commitment.
Claim to check: A preferred R2 location proves jurisdiction-restricted storage.
Buyer evidence still required
Bucket jurisdiction rather than only the location hint
Jurisdiction-specific access configuration where applicable
Scope of any additional processing or connected services
Suggested review condition: Do not infer a residency or compliance conclusion from a placement hint.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Recheck bucket recreation, access configuration and service limitations.
Optional saved evidence: Save the distinction between placement preference and jurisdiction evidence.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Does a storage location hint guarantee jurisdiction?
How does an R2 hint differ from a jurisdiction restriction?
Can a bucket jurisdiction be changed after creation?
Does recreating a named bucket necessarily select a new location?
Which endpoint accesses a jurisdiction-restricted bucket?
What evidence should procurement request for storage placement?
Does a regional preference establish regulatory compliance?
Can connected services have separate location limitations?
Which bucket settings should a saved review preserve?
How should an agent qualify a location claim?
Can I retain the reviewed R2 location boundary?
When should storage-jurisdiction assumptions be rechecked?
Neon restore: History windows and eligible branches
Does Neon instant restore apply to every branch and any past time?
No. Current documentation limits instant point-in-time restore to eligible root branches within retained history and excludes branches created by snapshot restore. It restores all databases on the chosen branch. Review eligibility, history and blast radius before accepting a universal recovery claim.
Claim to check: Any Neon branch can be restored to any prior point without affecting other databases.
Buyer evidence still required
Branch type and snapshot-restore origin
Available history covering the required time
All databases affected and evidence of the intended recovery outcome
Suggested review condition: Require branch eligibility and recovery scope before promising a restore.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Recheck restore support, history settings and branch lineage.
Optional saved evidence: Save the branch/history conditions behind a database recovery review.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Can every database branch use point-in-time restore?
Does a snapshot-restored branch support instant restore?
Which history window covers the desired recovery time?
Does restoring a branch affect all its databases?
Can a child branch be restored like a root branch?
What evidence establishes recovery eligibility?
Does an automatic backup mean the original operation had no impact?
Can a restore interrupt existing connections?
What should procurement ask about branch recovery limits?
Which branch lineage should a saved review identify?
Can I preserve the reviewed Neon recovery conditions?
Pinecone namespaces: Data separation and tenant routing
Does one namespace per tenant prove an application always selects the authorised tenant?
Pinecone documents separate namespaces and requires data operations to target a namespace. That describes storage and query scope. The buyer still needs evidence that its application maps the authenticated tenant to the correct namespace; the documentation does not inspect that mapping.
Claim to check: Creating tenant namespaces proves application-level authorisation is correct.
Buyer evidence still required
Namespace assignment for each intended tenant
How authenticated tenant identity selects the request namespace
Authorised tests of cross-tenant rejection in the buyer application
Suggested review condition: Do not substitute storage separation for evidence of correct application routing.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Recheck namespace mapping, application identity handling and index changes.
Optional saved evidence: Save the separation-versus-routing distinction for a retrieval-system procurement review.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Do separate namespaces prove correct tenant authorisation?
Which namespace does a retrieval request actually target?
Can application routing select the wrong tenant namespace?
What evidence connects authenticated identity to data scope?
How do namespace separation and request authorisation differ?
Does a vendor architecture diagram test my application?
What should procurement ask about multitenant vector retrieval?
Can a saved namespace review replace cross-tenant tests?
Which mapping should an agent preserve in its decision record?
Does missing evidence prove tenant isolation has failed?
Can I save the source-bound tenant-routing checklist?
PostgreSQL RLS: Effective roles and policy exceptions
Does enabling row-level security constrain every database identity?
No. PostgreSQL documents exceptions for superusers, BYPASSRLS roles and normally table owners; owners can opt into forced row security. Whole-table operations also have distinct treatment. Review the actual role and operation before using RLS enablement as evidence of tenant isolation.
Claim to check: An RLS-enabled table restricts every caller to tenant rows.
Buyer evidence still required
Effective connecting role and relevant role attributes
Table ownership, force setting and policy definitions
Authorised tests using the application identity and operation type
Suggested review condition: Do not accept universal isolation from RLS enablement alone.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Recheck role grants, ownership, policies and database upgrades.
Optional saved evidence: Preserve the role and policy distinctions for a database-access review.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Does row-level security restrict a database superuser?
Can a table owner bypass row policies?
Which effective role does the application use?
What does forcing row security change for an owner?
Does enabling RLS without a policy allow normal row access?
Are whole-table operations covered like row reads?
What evidence supports an RLS tenant-isolation claim?
Can an administrative test represent the application role?
Which role attributes should procurement ask to inspect?
Does an RLS setting prove every operation is filtered?
Can I save the reviewed row-security exceptions?
When should role changes trigger another isolation review?
Snowflake query history: Delay, coverage and transfer status
Does an empty Snowflake query-history result prove no query ran?
No. Account Usage query history can be delayed, and some short hybrid-table queries are represented elsewhere. The documentation also says a successful PUT or GET history status indicates authorisation to proceed, not completed file transfer. Review the view, workload and outcome evidence separately.
Claim to check: Query history is immediate and sufficient proof of every completed operation.
Buyer evidence still required
Chosen view, time range and visibility after documented delay
Workload coverage and any aggregate history needed
Independent outcome evidence for file transfer or other claimed effects
Suggested review condition: Do not infer inactivity or completed transfer from a single history result.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Recheck history coverage, workload types and status definitions.
Optional saved evidence: Save the activity-evidence limitations used in a data-platform review.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Does empty query history prove no activity occurred?
How can history latency affect an audit question?
Are short hybrid-table queries always recorded individually?
Does PUT success in history prove upload completion?
Does GET success in history prove download completion?
Which Snowflake history view did the reviewer use?
How do history time windows differ between views?
What evidence supports the actual transfer outcome?
What should procurement ask about query-history completeness?
Can an agent confuse permission to proceed with completion?
Can I save the reviewed activity-history boundary?
When should workload changes trigger another history review?
MongoDB change streams: Resume tokens and retained history
Does storing a change-stream resume token guarantee recovery after any outage?
No. MongoDB requires enough oplog history to locate the relevant operation. Invalidation also affects how a stream can restart. A saved token is a position reference, not a guarantee that the required history still exists or every downstream event was processed.
Claim to check: A resume token guarantees complete replay after an arbitrary interruption.
Buyer evidence still required
Retained history covering the saved position
Invalidation or topology events relevant to the stream
Evidence of downstream processing and reconciliation after reconnect
Suggested review condition: Require retained-history and outcome evidence before a complete-replay claim.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Recheck retention, stream configuration and recovery procedures.
Optional saved evidence: Preserve the continuity conditions behind an event-feed procurement review.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Does a resume token guarantee replay after any outage?
What if the required oplog history has expired?
Can collection invalidation change how a stream restarts?
Does reconnecting prove every downstream event was processed?
Which saved position should a recovery review identify?
How does history retention constrain change-stream continuity?
What evidence supports a no-missed-events claim?
Can an agent infer complete replay from a valid token format?
What should procurement ask about event-feed recovery?
Which reconciliation outcome should be retained?
Can I save the documented change-stream boundary?
When should outage recovery assumptions be retested?
Databricks tool selection: Direct connection grants matter
Does an MCP tool allowlist constrain identities that also have direct connection access?
Databricks warns that USE CONNECTION permits direct use outside the MCP tool selection and policies. It also documents all-tools defaults and optional inclusion of future tools. Review direct grants and selector behaviour before claiming the allowlist covers every access path.
Claim to check: An MCP allowlist restricts every use of the underlying connection.
Buyer evidence still required
Effective MCP and direct connection permissions
Configured selectors and future-tool inclusion setting
Policy scope and evidence for each access path being claimed
Suggested review condition: Require direct-grant evidence before treating the MCP allowlist as universal.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Recheck direct grants, selectors and newly exposed tools.
Optional saved evidence: Save the distinction between governed tools and separate connection authority.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Does an MCP allowlist control direct connection use?
Who has USE CONNECTION outside the MCP service?
Does an empty tool selector deny every tool?
Can future tools appear without a fresh review?
Which permissions does an ordinary MCP caller need?
Do tool policies necessarily change the visible tool list?
What evidence supports a universal tool restriction claim?
Can broader direct grants invalidate an allowlist review?
What should procurement ask about alternate access paths?
Which selector settings should a saved review preserve?
Can I save the Databricks direct-access boundary?
When should connection-grant changes trigger review?
Google Cloud keys: Expiry, rotation and workload continuity
Do user-managed Google Cloud service-account keys expire automatically by default?
Google states that keys created through IAM have no expiry by default and remain valid until deleted. Expiry and rotation are separate lifecycle choices, and expiry can interrupt workloads. Request the actual key inventory and replacement process rather than assuming automatic expiration proves credential hygiene.
Claim to check: Service-account keys automatically expire and therefore need no lifecycle review.
Buyer evidence still required
Key inventory, age and configured expiry without disclosing secret values
Documented replacement and removal process
Evidence that dependent workloads use the intended current credential
Suggested review condition: Do not infer expiry or completed rotation from a policy statement alone.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Recheck key creation, rotation records and workload authentication changes.
Optional saved evidence: Save the lifecycle evidence checklist for a supplier service identity.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Do user-managed service-account keys expire by default?
Does key expiry prove rotation has completed?
Can an expiring key interrupt a production workload?
What evidence shows an old key was removed?
Which workloads still use the credential being replaced?
Can procurement review key lifecycle without seeing secrets?
Does a rotation policy prove it is followed?
What should an agent ask about temporary key access?
How do expiration and replacement differ?
Which inventory facts belong in a saved credential review?
Can I preserve the documented key-lifecycle boundary?
When should service-account authentication be reassessed?
AWS last-accessed data: Attempts and tracking limits
Does AWS last-accessed data prove a permission was successfully used?
No. AWS says service last-accessed data includes attempted calls, including denied attempts. Tracking periods, action coverage and policy types also limit interpretation. Correlate the relevant event evidence before concluding successful use, non-use or that a permission can be removed.
Claim to check: Last-accessed history proves successful use or complete non-use of a permission.
Buyer evidence still required
Report scope, tracking window and supported action coverage
Relevant successful or denied event evidence
Effective policies and workload requirements beyond the report
Suggested review condition: Do not infer safe removal or successful use solely from a last-accessed report.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Recheck report coverage, identity policies and workload changes.
Optional saved evidence: Save the attempt-versus-success distinction for an access procurement review.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Does last-accessed data prove a permission succeeded?
Can a denied API attempt appear in access history?
Does no recorded use prove a permission is unnecessary?
Which actions are tracked in the selected report?
How does the tracking period limit interpretation?
What audit evidence distinguishes denied from successful use?
Do all policy types contribute to the report?
Can an agent recommend permission removal from one empty row?
What should procurement ask about access-history claims?
Which scope facts should a saved review retain?
Can I preserve the reviewed last-accessed boundary?
When should an access-use conclusion be reassessed?
Kubernetes: Secret listing is not metadata-only access
Can a Kubernetes inventory role reveal secrets without a get permission?
Kubernetes documents that list and watch access can reveal Secret contents. It also identifies workload-creation permissions as another route to namespace resources. A review confined to the get verb therefore cannot establish secret isolation; inspect the complete role and workload authority.
Claim to check: The inventory role cannot retrieve secret values.
Buyer evidence still required
Effective roles and bindings for the inventory identity.
Secret list/watch permissions and namespace scope.
Workload creation authority and applicable admission controls.
Suggested review condition: Keep secret isolation unproven until all relevant permissions are evidenced.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. RBAC bindings, workload authority and admission policy changes.
Optional saved evidence: Save the specific permission gaps that prevent approving an inventory role as metadata-only.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Can an inventory role list secret values?
Does removing get prevent Kubernetes Secret disclosure?
What does watch permission expose for Secrets?
Can workload creation affect secret access?
Which namespace roles should a procurement review inspect?
Does read-only cluster access mean metadata-only?
What evidence supports a secret-isolation claim?
Can a service identity gain access through workloads?
Which role bindings belong in an access review?
Does one denied request prove no other access path?
When should an agent refuse a metadata-only assurance?
AWS IAM: Permission boundaries and direct resource grants
Does an IAM permissions boundary alone prove every access path is restricted?
A boundary limits identity-policy permissions and grants nothing by itself. The documentation also distinguishes direct resource grants to users, roles and sessions, including cases not limited by an implicit boundary denial. Review principal type and resource policies alongside the boundary; explicit denials are a different case.
Claim to check: The attached boundary establishes the complete effective permission limit.
Buyer evidence still required
Exact principal and session type used by the agent.
Relevant identity, resource and boundary policies.
Evidence of explicit denials and evaluated access for the intended action.
Suggested review condition: Do not infer effective access from a boundary attachment alone.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Resource grants, session identities and boundary changes.
Optional saved evidence: Preserve which policy combinations still need review before accepting an access-limit claim.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Does an IAM boundary grant access on its own?
Can a resource policy change the effective boundary review?
Why does the principal type matter for AWS access?
Are implicit and explicit denials equivalent?
Does a role-session grant behave like a role grant?
Which policies should procurement request for an agent?
Can an attached boundary prove least privilege?
What evidence supports a denied cloud operation?
Does an identity policy alone explain all permissions?
When should a boundary claim require more evidence?
Azure locks: Resource protection does not cover every data operation
Does an Azure read-only resource lock prevent changes to stored data?
Resource locks apply to control-plane operations. The documentation explicitly separates data-plane activity, including changes to database or storage contents that a resource lock does not prevent. Identify the actual operation and endpoint before accepting a claim that the locked resource is entirely immutable.
Claim to check: A resource lock prevents all changes or deletion of the data inside it.
Buyer evidence still required
Lock type and inherited resource scope.
The actual operation and service endpoint used.
Data-plane authorisation and separate retention/deletion controls.
Suggested review condition: Qualify immutability claims that rely solely on a management lock.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Lock scope, operation paths and separate data controls.
Optional saved evidence: Save why a management-lock screenshot was insufficient evidence for data immutability.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Does a cloud resource lock make its data immutable?
Can database rows change under an Azure read-only lock?
Which API plane does a resource lock protect?
Does a storage lock stop blob deletion through every endpoint?
What evidence distinguishes resource deletion from data deletion?
Can inherited locks cover management actions only?
Which permissions govern the unprotected data plane?
Does a failed management request prove the data is protected?
What should procurement ask about immutable storage claims?
Can a lock also block unexpected management reads?
When should a data-protection claim remain qualified?
S3 presigned URLs: Reuse and credential-bound lifetime
Is an S3 presigned download a single-use link valid until its stated expiry?
The documentation allows repeated use before expiry. Temporary signing credentials can expire earlier than the URL setting, and a download begun before expiry can continue afterwards. Review reuse requirements and credential lifetime separately from the displayed expiration; the URL alone does not implement single-use delivery.
Claim to check: The signed URL is single-use and its expiry is the complete access boundary.
Buyer evidence still required
Signing identity type and credential expiration.
Configured URL expiry, method and object binding.
Any separate single-use enforcement and observed download behaviour.
Suggested review condition: Do not claim single-use access without an additional evidenced control.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Credential lifetime, URL policy and any application-level use limit.
Optional saved evidence: Preserve the delivery assumptions that a signed URL does and does not support.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Is a presigned download link single-use?
Can an S3 URL stop working before its configured expiry?
Can a download continue after a signed URL expires?
What happens when a download restarts after expiry?
Which credentials determine a signed link lifetime?
Can a presigned upload replace an existing object?
Does a signed URL specify an allowed HTTP method?
What evidence proves a one-time download control?
Can anyone holding the link reuse it?
Which delivery assumptions should procurement record?
When should a link-expiry assurance remain qualified?
Azure SAS: Revocation depends on signature type and policy association
Can one stored access policy revoke every Azure shared access signature?
Stored access policies apply to associated service SAS tokens. User-delegation and account SAS tokens do not support that association. Identify the SAS type and revocation mechanism before claiming that a policy change ends access; an ad hoc signature cannot inherit a policy it was never linked to.
Claim to check: Changing a stored policy revokes every issued SAS for the resource.
Buyer evidence still required
Inventory of SAS types and signing methods.
Policy association for the specific service SAS.
Documented and tested revocation path for each unassociated token type.
Suggested review condition: Keep universal revocation claims open until every token type is covered.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. SAS issuance patterns, policy associations and key/delegation lifecycle.
Optional saved evidence: Save the evidence needed to distinguish policy-linked revocation from other SAS lifecycles.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Can a stored policy revoke every shared storage link?
Does a user-delegation SAS support stored access policies?
Is an account SAS linked to a container policy?
What distinguishes ad hoc and policy-associated SAS?
Which signature type did the supplier issue?
Does a policy change affect an unassociated token?
What evidence proves a storage token was revoked?
Can a single revocation procedure cover mixed SAS types?
Which expiry and resource scope should be recorded?
Does a storage link require the recipient to hold account credentials?
When should a universal revocation claim be refused?
Okta: Session removal and OAuth-token revocation are separate
Does removing an Okta session prove that related API tokens were revoked?
The guide separates session cookies from access and refresh tokens. Removing all user sessions can optionally include token revocation through a specific parameter. A successful revocation response also covers already-invalid tokens. Record the operation and its options, then verify the relevant access outcome.
Claim to check: Successful session removal proves all related API access ended.
Buyer evidence still required
Exact session/token revocation operation and options.
Relevant token family and application session inventory.
Authorised verification of the intended access outcome.
Suggested review condition: Do not equate a successful session API response with complete token invalidation.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Session/token inventory, operation options and application behaviour.
Optional saved evidence: Save what the offboarding action actually covered and which access outcomes still need proof.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Does identity-provider logout revoke API access?
Are Okta sessions and OAuth tokens the same credential?
Which option also revokes tokens when removing sessions?
Does HTTP success prove a token was previously valid?
Can revoking an access token leave its refresh token usable?
What happens when the refresh token is revoked?
Which offboarding operation should procurement record?
How should an agent verify the intended revocation outcome?
Can one session closure prove all sessions ended?
What evidence covers application-specific sessions?
Auth0 rotation: Reuse detection can invalidate the whole refresh family
Does refresh-token rotation let an agent safely retry any old refresh token?
The rotation documentation describes invalidation of a refresh-token family when reuse of an invalidated token is detected. The service cannot identify the legitimate actor from that replay alone. Both recovery and access-token lifetime need consideration; rotation is not permission to retry stale credentials indefinitely.
Claim to check: Automatic rotation makes stale-token retries harmless and preserves uninterrupted access.
Buyer evidence still required
Client rotation and retry configuration.
Documented handling of reuse events and token-family invalidation.
Reauthentication flow and separate access-token lifecycle evidence.
Suggested review condition: Require recovery evidence before accepting uninterrupted-session claims.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Rotation policy, client concurrency/retry behaviour and recovery flow.
Optional saved evidence: Preserve the distinction between reuse protection and successful session recovery.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Can an agent retry an old rotating refresh token?
What does refresh-token family invalidation mean?
Can reuse detection identify the legitimate client?
Does a successful refresh guarantee the next refresh succeeds?
Can stale retries interrupt an authorised session?
Does rotation immediately end every access-token lifetime?
What evidence supports recovery after token reuse?
Which logs identify a detected reuse event?
Should procurement inspect client retry behaviour?
Can an expired session be recovered without new authentication?
When should uninterrupted-access claims remain qualified?
Terraform: Sensitive display masking is separate from persistence
Does marking a Terraform value sensitive keep it out of state and plan files?
The sensitive setting masks ordinary display, but does not by itself omit values from state or plans. The documentation provides separate ephemeral and write-only mechanisms with version and provider constraints. Review the actual data path and backend rather than accepting a masked screenshot as non-persistence evidence.
Claim to check: A sensitive variable cannot persist in infrastructure artifacts.
Buyer evidence still required
Value flow and relevant variable/resource declarations.
Terraform and provider support for omission mechanisms.
State/plan storage, access and export handling.
Suggested review condition: Do not infer non-persistence from display redaction.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Provider support, language versions and state/export handling.
Optional saved evidence: Save the concrete distinction between hidden output, omitted values and protected artifact storage.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Does a masked infrastructure variable disappear from state?
Can sensitive Terraform values persist in plans?
How do sensitive and ephemeral settings differ?
Does every provider support write-only arguments?
Can JSON output expose a sensitive value?
Which backend protects stored state?
What evidence proves a secret was omitted rather than hidden?
Does remote state automatically establish all access controls?
Which Terraform version supports the proposed omission?
Pulumi secrets: Encrypted state does not prevent runtime disclosure
Does Pulumi secret encryption prove a value cannot appear in application logs?
Pulumi encrypts marked secret values in state and tracks their propagation, but runtime callbacks receive plaintext and can expose it elsewhere. The documentation also excludes resource IDs from secret encryption. Review runtime handling and value placement before accepting a blanket no-disclosure claim.
Claim to check: State encryption prevents every disclosure of a secret value.
Buyer evidence still required
Evidence that the value is marked secret in state.
Review of callbacks, logs and downstream output destinations.
Whether sensitive material appears in a resource identifier.
Suggested review condition: Do not extend a state-encryption claim to unevidenced runtime channels.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Output marking, callback changes and identifier handling.
Optional saved evidence: Save which runtime and identifier checks remain necessary beyond encrypted state.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Does encrypted infrastructure state prevent secret logging?
Can a Pulumi callback receive plaintext secrets?
Are resource IDs encrypted as secret values?
Does secret propagation protect arbitrary downstream code?
What evidence covers application logs and local files?
Can a generated identifier contain sensitive data?
Which output properties need a secret review?
Does a secure backend prove no runtime disclosure?
What should procurement ask about callback handling?
Can a state export prove all channels are protected?
Vault leases: Static KV values are not dynamic credentials
Does a Vault lease policy prove that a copied static password expires?
Vault documents leases for dynamic secrets and service tokens, while the key/value backend does not issue secret leases even when a duration is returned. A static value stored in Vault therefore needs its own credential-lifecycle evidence. Storage in a lease-capable product is not evidence of automatic downstream expiry.
Claim to check: Every value stored in Vault automatically expires or is revoked through a lease.
Buyer evidence still required
Secrets engine and whether the value is dynamic or static KV.
Actual lease identifier and revocation mechanism where applicable.
Downstream rotation or invalidation evidence for static credentials.
Suggested review condition: Do not promise expiry of a static credential solely from Vault storage.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Engine changes, credential type and downstream revocation process.
Optional saved evidence: Preserve the engine and lifecycle distinction behind a credential-expiry assessment.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Does storing a password in Vault make it expire?
Do static KV secrets have dynamic-secret leases?
Does a returned duration prove a revocable lease exists?
Which identifier supports a Vault lease review?
Can revoking a Vault token invalidate every copied static password?
What evidence proves downstream credential rotation?
How do dynamic secrets differ from stored values?
Which engine is relevant to an expiry claim?
Can product-level lease support establish this credential lifecycle?
What should procurement request for static secret expiry?
GitHub deployment approvals: Reviewer lists and independence
Does listing several required reviewers mean every reviewer must approve a deployment?
The documentation says one required reviewer can approve a job. Preventing self-review and restricting administrator bypass are separate settings, with plan and repository conditions. Review the actual environment and job reference before claiming independent multi-person approval from the reviewer list.
Claim to check: A list of required reviewers establishes unanimous independent approval.
Buyer evidence still required
Environment reviewer, self-review and bypass settings.
Plan/repository entitlement and job environment binding.
Approval evidence for the specific deployment.
Suggested review condition: Do not infer multiple approvals or independence from a reviewer list.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Environment settings, workflow references and plan conditions.
Optional saved evidence: Save the settings and observed approval evidence needed for a deployment-governance claim.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Must every required deployment reviewer approve?
Does a reviewer list prevent self-approval?
Can administrators bypass a deployment gate?
Does every workflow job use the protected environment?
Which plan supports the claimed deployment protection?
What evidence proves independent approval occurred?
Does an environment secret become available before approval?
Can naming two reviewers establish two-person control?
Which bypass setting should procurement inspect?
Can a passing workflow prove its review gate was applied?
When should approval independence remain unproven?
Can I save a deployment-review control assessment?
CodeQL: Build mode affects what analysis can establish
Does a successful CodeQL run prove generated code and every dependency were analysed?
The Action README distinguishes no-build, automatic and manual build modes. It notes that no-build analysis can miss findings involving generated code or inaccessible dependencies. A successful run alone therefore cannot establish complete coverage; review language, build mode and extraction evidence for the actual repository.
Claim to check: A green scan proves complete coverage of the deployed code.
Buyer evidence still required
Analysis configuration, languages and exact versions.
Build/extraction evidence for generated code and dependencies.
The analysed revision compared with the deployed artifact.
Suggested review condition: Do not translate successful analysis into complete coverage or absence of vulnerabilities.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Build mode, dependency access, generated code and analysed revision.
Optional saved evidence: Save the coverage qualifications behind a supplier scan-evidence review.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Does a green security scan prove all code was analysed?
Can no-build CodeQL miss generated code findings?
Which CodeQL build mode was actually used?
Do inaccessible dependencies affect scan coverage?
Does automatic build success establish vulnerability absence?
What evidence links a scan to deployed code?
Which languages does the configured mode support?
Can a summary badge replace extraction evidence?
What should procurement request with a scan report?
Does a manual build remove every analysis limitation?
Fastly soft purge: Stale marking is not immediate removal
Does a successful soft purge prove cached content can no longer be served?
Soft purge marks content stale and can leave it available during revalidation or other configured stale-serving conditions. Fastly distinguishes this from hard invalidation. Identify the purge method and cache behaviour before treating a purge response as evidence that old content is unavailable.
Claim to check: The purge response proves immediate removal of the old content.
Buyer evidence still required
Exact purge method and target scope.
Stale-while-revalidate and stale-on-error configuration.
Authorised observation of the relevant content after the operation.
Suggested review condition: Do not report immediate unavailability from a soft-purge acknowledgement.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Cache policy, purge type and origin revalidation behaviour.
Optional saved evidence: Save the difference between an accepted cache action and verified content-removal behaviour.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Does soft purging remove cached content immediately?
Can stale content still be served after a purge?
What distinguishes soft and hard cache invalidation?
Which cache setting allows stale responses on error?
Does an accepted purge prove a customer received new content?
What evidence supports an urgent content-removal claim?
Can a surrogate key select more than one object?
Does purge-all behave like a soft purge?
Which origin headers support revalidation?
What should procurement request about cache removal?
When should an agent avoid claiming content is gone?
Cloudflare Access: Gateway sessions and SaaS sessions differ
Does an Access application-session limit end the session inside a SaaS app?
Cloudflare documents that the Access duration controls entry to the SaaS application, whose own cookie manages the session inside it. Session revocation also needs to be distinguished from preventing a still-authorised identity from returning. Review both systems before accepting a complete-session-termination claim.
Claim to check: The gateway session limit guarantees the user leaves every connected application.
Buyer evidence still required
Access application type and session configuration.
SaaS-issued session lifetime and termination mechanism.
Identity disablement or policy changes and observed re-entry behaviour.
Suggested review condition: Keep complete termination unproven without application-session evidence.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Access policy, SaaS session behaviour and identity lifecycle.
Optional saved evidence: Preserve the gap between gateway reauthentication and termination of an existing SaaS session.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Does a gateway session timeout log users out of SaaS?
Which system owns the session inside a SaaS application?
Can a revoked gateway session be created again?
Does identity deactivation differ from session revocation?
What evidence covers an existing application cookie?
Can a gateway limit prove complete offboarding?
Which session durations should procurement compare?
Does logging out of one domain end every application session?
What should an agent verify before reporting access ended?
Can application policy changes affect reauthentication?
When should complete session termination remain unproven?
CircleCI contexts: Group, project and expression restrictions combine
Does adding a group restriction prove a CI secret is limited to the intended project?
CircleCI treats group, project and expression restrictions as separate checks. With no project restriction, the documentation allows use across projects in the organisation; defaults and integration support also matter. Review the complete context configuration and trigger path rather than treating group membership as a project allowlist.
Claim to check: The context group setting confines the secret to one approved project.
Buyer evidence still required
Context security groups and explicit project restrictions.
Expression restrictions and supported trigger/integration type.
Effective runtime access, including administrator authority and membership refresh.
Suggested review condition: Do not infer project confinement from a group setting alone.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Context settings, group synchronisation and trigger support.
Optional saved evidence: Save which context restrictions and trigger evidence support the approved secret-use scope.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Does a CI context group restrict which projects can use secrets?
What happens when a CircleCI context has no project restriction?
Do group and expression checks combine as alternatives?
Can multiple allowed groups broaden access?
Which integration supports context security groups?
Does changing group membership take effect immediately?
Can administrators access restricted contexts?
Which pipeline conditions can restrict secret availability?
What evidence identifies the actual trigger path?
Can a context name prove production-only use?
When should a CI secret-scope claim remain qualified?
Cloud KMS rotation: New key versions do not rewrite existing ciphertext
Does rotating a Cloud KMS key prove old encrypted data no longer depends on the old version?
The documentation separates creating a new key version from re-encrypting existing data and retiring old versions. Rotation alone does neither. Establish which data still depends on each version before asserting completion; destroying a version still in use can make its data unrecoverable.
Claim to check: Automatic rotation replaces old encryption and removes all old-key dependency.
Buyer evidence still required
Key type, active versions and rotation configuration.
Evidence of re-encryption or remaining ciphertext dependencies.
Approved retirement checks for versions still needed by data.
Suggested review condition: Do not recommend retiring a key version from rotation status alone.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Key type, version lifecycle and re-encryption coverage.
Optional saved evidence: Save why a rotation event was insufficient evidence of completed data-key migration.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Does key rotation re-encrypt existing data?
Are old Cloud KMS versions disabled automatically?
Can an old key version remain necessary after rotation?
Does asymmetric key rotation use the same automatic process?
What evidence proves ciphertext no longer needs an old version?
Can destroying a key cause unrecoverable data loss?
Which key inventory belongs in a procurement review?
Does a rotation schedule prove migration completed?
What should an agent verify before reporting key retirement?
Can newly encrypted data use a different version from old data?
Entra CAE: Revocation depends on the participating client and resource
Does Continuous Access Evaluation guarantee immediate revocation in every application?
Continuous Access Evaluation depends on participating resources and clients, including handling of claim challenges. The guide distinguishes supported scenarios and exceptions. Its presence does not establish universal instantaneous revocation; the buyer must identify the actual application and demonstrate the relevant access outcome.
Claim to check: CAE guarantees immediate access removal everywhere.
Buyer evidence still required
Application/resource and client compatibility.
Applied policies and relevant session conditions.
Authorised evidence of access after the revocation event.
Suggested review condition: Keep universal revocation claims qualified until each relevant application path is evidenced.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Client/resource support, access policies and session paths
Optional saved evidence: Save the application-specific gaps behind a revocation claim.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Does CAE work with every application?
Which clients can handle a claims challenge?
Does token lifetime alone describe revocation timing?
What resource support does CAE require?
Can a legacy client change the outcome?
Which event is expected to end access?
Does an enabled tenant feature prove client enforcement?
What should an offboarding test observe?
Can one successful denial cover other applications?
What exceptions should procurement record?
When should an agent request application-specific proof?
Workspace app controls: Trusted access is not a narrow scope grant
Does marking a third-party app Trusted prove it has only the scopes needed for my task?
Trusted apps can access restricted and unrestricted Google services, subject to the relevant authorisation. The guide separately offers Specific Google data scope selection and organisational-unit settings. A Trusted label alone therefore does not establish a narrowly scoped integration.
Claim to check: A Trusted app designation proves least-privilege access.
Buyer evidence still required
OAuth client identity and requested scopes.
Configured app access level and organisational-unit scope.
Evidence of actual granted access for the intended workflow.
Suggested review condition: Require scope and organisational-unit evidence before accepting a least-privilege claim.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. App client IDs, scopes, access levels and organisational-unit assignments
Optional saved evidence: Preserve the concrete grant questions behind an app approval.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
What does a Trusted Workspace app designation allow?
How does Specific Google data differ from Trusted?
Can Limited apps access restricted services?
Which organisational unit receives an app setting?
Does a configured app bypass unconfigured-app defaults?
Which OAuth client ID is being approved?
Can sign-in scopes differ from data scopes?
Does an allowlisted device app override an API block?
What evidence proves the actual grant?
Can an app request more access than the task needs?
IAM role revocation: Existing sessions and new assumptions differ
Does revoking active IAM role sessions prevent the role from being assumed again?
The documented operation adds a deny policy for temporary credentials issued before a cutoff time. It does not by itself remove the ability to obtain later sessions. Review the trust relationship and assumption permissions separately from invalidating existing sessions.
Claim to check: Revoking sessions permanently disables all access through the role.
Buyer evidence still required
Revocation cutoff and attached deny policy.
Role trust policy and current assumption permissions.
Evidence covering both old-session denial and new-session issuance.
Suggested review condition: Do not treat a session cutoff as permanent role disablement.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Role trust, assumption grants, revocation time and session inventory
Optional saved evidence: Retain the distinction between cancelling current sessions and closing future access.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
What time boundary does role-session revocation use?
Can a caller assume the role again afterwards?
Does revocation remove the trust policy?
Which sessions predate the cutoff?
Are later temporary credentials affected?
What evidence proves old sessions are denied?
Which identities can request a new session?
Does one denied request prove the role is disabled?
How should procurement separate sessions from trust?
Does this procedure cover every role type?
When should an agent refuse a permanent-disablement claim?
GitHub Apps: Installation and user tokens carry different authority
Does a GitHub App user token have the same effective access as its installation token?
Installation tokens act for an installation, while user tokens act on behalf of a user. The guide describes user-token access as constrained by both the app and the user. Select the token type and repository scope explicitly; an app permission list alone does not identify the complete effective actor.
Claim to check: All tokens issued to one GitHub App have equivalent authority.
Buyer evidence still required
Token type and installation or user identity.
App permissions and selected repository access.
User permissions and observed action attribution where applicable.
Suggested review condition: Do not approve an operation from app permissions alone when its identity path is unspecified.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Token type, installation scope, user rights and app permissions
Optional saved evidence: Save which actor and permission intersection were considered before approving a repository action.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Does an installation token act as a person?
How is a GitHub App user token constrained?
Which repositories belong to the installation?
Can user permissions narrow an app grant?
Does one app permission list identify the actor?
Which identity appears in the operation record?
Can a revoked user grant affect app activity?
What should a buyer record about token type?
Does app installation prove authority for every repository?
Can the same workflow use different actor types?
When should an agent clarify the intended identity?
GitLab token rotation: Old-token invalidation needs a consumer handoff
Does rotating a GitLab personal access token preserve uninterrupted access for existing consumers?
Rotation creates a replacement and invalidates the previous token immediately while retaining the original permissions and scope. Consumers still need the new credential. Rotation is a lifecycle action, not evidence that every dependent integration has switched successfully or that access was narrowed.
Claim to check: Rotating the token guarantees uninterrupted and more restricted access.
Buyer evidence still required
Original and replacement scope and expiry metadata.
Inventory of dependent integrations and their update path.
Authorised verification of old-token failure and new-token use.
Suggested review condition: Require a consumer handoff before claiming successful continuity.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Token scopes, expiry, dependent consumers and credential handoff
Optional saved evidence: Preserve the integration handoff and scope questions behind a rotation decision.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Does the old GitLab token remain usable after rotation?
Does rotation narrow token scopes?
Which integrations still hold the old credential?
Can an expired token be reactivated?
What expiry applies to the replacement?
Does a rotation response prove deployment succeeded?
How should an agent avoid logging the replacement secret?
Which service account credentials need separate review?
What evidence establishes the handoff?
Can consumers fail during an immediate invalidation?
Snowflake sessions: The primary role is not the whole access picture
Does a restricted primary Snowflake role prove the session cannot use broader privileges?
Active secondary roles contribute privileges for many SQL operations alongside the primary role and inherited grants. Creation authority is evaluated differently, through the primary role. Inspect the active role set and operation rather than infer the complete permission boundary from the primary-role name.
Claim to check: The primary role name establishes all effective session permissions.
Buyer evidence still required
Primary and active secondary role identities.
Inherited grants and object ownership.
The exact operation and its authorisation evidence.
Suggested review condition: Do not equate a narrow primary role with a narrow session without the secondary-role context.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Active roles, inherited grants, ownership and SQL operation
Optional saved evidence: Retain the actual role-combination questions needed for an access decision.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Can secondary Snowflake roles authorise a query?
Does CREATE use the same role evaluation as SELECT?
Which roles are active in the session?
Do inherited roles contribute privileges?
Can a secondary role carry object ownership?
Does a role name prove its current grants?
Can the active role set change mid-session?
Which identity should a query review record?
What evidence supports a limited-access claim?
Are database roles directly activated as session roles?
Entra logs: A licence upgrade does not recreate expired history
Does upgrading an Entra licence recover audit or sign-in records that already expired?
The retention guide says licence changes are not retroactive. An upgrade retains only data still available, unless older data was separately archived. Log types also differ; Graph activity logs require a storage or analytics integration. A new licence is not evidence that the requested historical interval exists.
Claim to check: A premium licence makes earlier expired activity available.
Buyer evidence still required
Log type, licence and applicable retention window.
Archive or analytics integration with its activation date.
Retrieved coverage for the requested historical interval.
Suggested review condition: Keep the historical interval unproven until retained or archived records are demonstrated.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Log type, licence dates, archive activation and requested interval
Optional saved evidence: Save why the requested historical interval needs archive evidence rather than a current licence screenshot.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Can an Entra upgrade recover expired sign-ins?
Do audit and risk logs have identical retention?
Which data existed when the licence changed?
Was older history archived separately?
Are Graph activity logs retained without integration?
What archive activation date matters?
Does an empty search establish no prior event?
Can external-tenant retention differ?
Which interval should procurement request?
Does a new licence backfill old data?
When should a historical audit claim be qualified?
Notion audit: Agent configuration events are not a run trace
Does the Notion audit log show everything a Custom Agent did during a run?
The audit documentation lists Custom Agent configuration and access events but explicitly excludes recording what an agent did during a specific run. Exports also follow active filters and a bounded historical window with a recent-data gap. Audit availability is not proof of a complete agent execution trace.
Separate run-level evidence for the specific agent action.
Suggested review condition: Do not claim full agent traceability from configuration events alone.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Plan, event catalogue, export filters and separate run evidence
Optional saved evidence: Retain the distinction between agent configuration history and evidence of a particular run.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Does Notion log each Custom Agent action?
Which configuration changes are recorded?
Can an audit export omit filtered events?
Does the export include the newest activity immediately?
What historical window is documented?
Which plan makes audit data available?
Can a permission-change event prove a run outcome?
How should a buyer obtain run-level evidence?
Does an empty export prove no agent action occurred?
GitLab audit streaming: Event delivery is not exactly once
Can an audit receiver count each GitLab streamed event as a unique action?
GitLab documents that one event can be streamed more than once to the same destination and recommends deduplication using its event identifier. Destinations can also be deactivated independently. Receiver counts need event identity and destination-state context before being presented as counts of distinct actions.
Claim to check: Every received audit message represents one distinct user action.
Buyer evidence still required
Event identifier handling and receiver deduplication.
Destination configuration and active-state history.
Reconciliation of unique events for the stated reporting interval.
Suggested review condition: Do not equate message count with unique action count without deduplication.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Event IDs, receiver deduplication, destination state and reporting interval
Optional saved evidence: Preserve how duplicate messages and destination state affect audit counts.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Can GitLab stream an audit event twice?
Which event field supports deduplication?
Does disabling one destination stop all streams?
Can destination configuration remain while streaming is paused?
What interval did the receiver observe?
Does a raw message count equal user actions?
How should an agent reconcile duplicate deliveries?
CloudTrail integrity: Digest delivery is separate from validation
Does enabling CloudTrail log-file integrity validation prove the delivered files were validated?
Enabling the feature delivers signed digest files. The documentation explicitly separates that from actually validating the logs, which requires a validation operation or equivalent implementation. Retain the verification result, coverage interval and file locations before asserting that an integrity check passed.
Claim to check: The enabled setting proves an integrity validation completed successfully.
Buyer evidence still required
Trail configuration and delivered log/digest identities.
Validation method, time interval and file locations.
Recorded verification outcome and any missing or invalid files.
Suggested review condition: Require an actual validation outcome before claiming validated integrity.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Trail settings, digest identity, validator result and interval
Optional saved evidence: Save the difference between having integrity material and demonstrating a completed check.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Does CloudTrail automatically validate every delivered file?
What does enabling digest delivery establish?
Which files are bound by the digest?
How are regional signing keys relevant?
Does moving logs change the validation procedure?
What interval did the validator cover?
Can a configuration screenshot prove verification passed?
Which failures or missing files were reported?
Does integrity prove every activity was logged?
What result should procurement retain?
When should an integrity claim require more evidence?
Cloud Logging: A sink exclusion is a routing decision
Does excluding a log from one Cloud Logging sink prove Google never received or stored it elsewhere?
Exclusion filters are applied after the Logging API receives entries and determine routing for the relevant sink. Other sinks and aggregated-routing rules can still matter. Review the complete routing topology before treating an exclusion as non-collection, global deletion or absence from every destination.
Claim to check: One sink exclusion proves global non-collection and non-retention.
Buyer evidence still required
Inclusion/exclusion filters on the relevant sink.
Other project and aggregated sinks and their destinations.
Evidence of destination retention for the relevant entry class.
Suggested review condition: Do not infer global erasure or non-collection from one routing filter.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Sink filters, aggregated routing, destinations and retention
Optional saved evidence: Preserve the routing evidence needed to distinguish filtering from data erasure.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
When are Cloud Logging exclusion filters applied?
Does an exclusion reduce entries.write calls?
Can another sink route the same log?
What does an intercepting aggregated sink change?
Which required logs have special routing?
Does a sink exclusion delete previously stored entries?
Which destination controls retention?
What topology should procurement inspect?
Can a filtered search prove no collection occurred?
S3 access logs: Missing records do not establish no request
Can S3 server access logs prove that every request was recorded exactly once?
S3 describes server access logging as best effort, with neither completeness nor timeliness guaranteed. Records can arrive late, be duplicated or be absent. These logs support traffic review, but a missing entry alone cannot establish that a request never occurred.
Claim to check: Server access logs are a complete, timely, exactly-once request ledger.
Buyer evidence still required
Logging configuration and destination history.
Observed delivery delays and duplicate handling.
Additional evidence for any claim based on a missing request.
Suggested review condition: Do not infer no access solely from an absent server access-log record.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Logging state, destination changes, delivery delay and independent request evidence
Optional saved evidence: Retain the completeness boundary behind a bucket-access investigation.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Are S3 server logs delivered exactly once?
Can a request record arrive late?
Can server logging omit a request?
Does a usage report necessarily match the log count?
What happens while a logging destination changes?
How should duplicate records be handled?
Does an empty interval prove no bucket access?
Which configuration was active at the time?
What evidence supports a specific request investigation?
Can these logs establish exact billing independently?
Gemini API: Data use depends on the applicable service terms
Does a free Gemini API request always have the same data-use terms as an unbilled service?
The terms distinguish Paid and Unpaid Services, with billing-account and regional provisions affecting applicability. Paid-service prompts and responses are not used for product improvement under the reviewed terms, but limited abuse-prevention logging remains described. Verify the applicable category instead of equating no charge with a universal retention or training rule.
Claim to check: A zero-cost request establishes one universal training and retention policy.
Buyer evidence still required
Cloud project billing association and applicable service category.
Relevant regional terms and feature-specific provisions.
Contractual and configuration evidence for retention and data use.
Suggested review condition: Require the applicable terms and feature context before claiming no training or no retention.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Terms version, billing association, region and API feature
Optional saved evidence: Preserve the applicable service and feature distinctions without asserting legal clearance.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Does zero price determine Gemini data-use terms?
Does an active billing account affect the service category?
Can regional provisions change the applicable treatment?
Does no product improvement mean no logging?
Which abuse-prevention handling is described?
Do grounding features have additional terms?
What project submitted the request?
Can a pricing screenshot prove retention behaviour?
Which contract version should a buyer preserve?
Are account metadata and prompt content treated identically?
When should a no-retention claim remain qualified?
Azure AI: No foundation-model training is not zero storage
Does Azure AI not training foundation models on prompts mean every feature is stateless?
The privacy documentation separates foundation-model training from feature storage and abuse monitoring. Responses and Assistants features can retain conversation state; human abuse review has a distinct handling path, with modified monitoring subject to approval. Review the actual feature and approved configuration before making a zero-storage claim.
Claim to check: No foundation-model training proves no prompt or conversation storage.
Buyer evidence still required
API feature and deployment type used by the workload.
Stateful storage and deletion configuration.
Evidence of the applicable abuse-monitoring approval and settings.
Suggested review condition: Do not substitute a training statement for proof of retention behaviour.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. API feature, deployment type, monitoring approval and storage settings
Optional saved evidence: Save the feature-specific retention questions behind a no-training statement.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Can Azure Responses retain conversation history?
Do Assistants features store state?
Is abuse monitoring separate from model training?
Does modified monitoring require approval?
Can automated review remain enabled?
Which deployment geography applies?
Do preview features have different terms?
What evidence demonstrates content logging is disabled?
Does no training prove no retention?
Which endpoint and feature should procurement identify?
Cohere Encrypted Vault: Content isolation and metadata visibility differ
Does Model Vault Encrypted mean no information about a request is visible outside its enclave?
For the documented beta, Cohere distinguishes encrypted content from routing metadata, infrastructure metrics and network observations outside the trusted execution environment. Its confidentiality claims do not eliminate those metadata categories or establish independent certification. The buyer still needs the applicable threat model and deployment evidence.
Claim to check: Encrypted inference hides every request-related fact from the operator.
Buyer evidence still required
Exact Encrypted Vault variant and beta terms.
Attestation and deployment evidence applicable to the buyer.
Metadata categories and threat-model acceptance for the workload.
Suggested review condition: Do not expand a content-confidentiality claim into universal invisibility or certification.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Vault variant, beta terms, attestation, metadata and threat model
Optional saved evidence: Retain the distinction between protected content and observable metadata for a supplier review.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Can routing metadata remain visible outside the enclave?
Can an operator observe request timing or size?
Is Encrypted Vault described as beta?
Does content encryption eliminate infrastructure telemetry?
Mistral ZDR: Stateful products and training opt-out are separate
Does enabling Mistral zero data retention cover every model and stateful product?
The reviewed documentation applies ZDR to supported stateless API calls on eligible paid plans, excluding Labs models and stateful products. It explicitly separates ZDR from training opt-out. Approval and the actual endpoint matter; one organisation setting does not establish universal non-retention across all features.
Claim to check: ZDR covers every endpoint and also establishes the training preference.
Buyer evidence still required
Organisation approval and eligible plan.
Exact endpoint/model and stateless or stateful behaviour.
Separate training preference and applicable feature terms.
Suggested review condition: Keep unsupported endpoints outside the ZDR claim.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Organisation approval, plan, endpoint, model and training preference
Optional saved evidence: Preserve the endpoint and model exceptions behind a retention decision.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Pinecone project deletion: Dependencies and accepted-state evidence
Does a project deletion request prove every Pinecone resource was already removed?
The versioned API requires associated indexes, assistants, backups and collections to be deleted before deleting a project. Its documented response is acceptance of the deletion request. Record dependency removal and subsequent state separately; an accepted response alone is not a complete erasure attestation.
Claim to check: An accepted project deletion proves all underlying data and resources were erased.
Buyer evidence still required
Exact project identity and API version.
Dependency inventory and authorised removal evidence.
Subsequent project state and applicable retention terms.
Suggested review condition: Do not treat request acceptance as a comprehensive erasure certificate.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Project identity, API version, dependencies and post-request state
Optional saved evidence: Save the dependency and completion evidence needed before asserting project removal.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Must Pinecone indexes be removed before project deletion?
Do backups and assistants count as dependencies?
What happens to project API keys on deletion?
What does the documented accepted response establish?
Which project identity was targeted?
Does acceptance prove completion?
Can a project-level action establish provider backup erasure?
Which retention terms still matter?
What state should a buyer verify afterwards?
Does this review authorise a destructive deletion?
Qdrant tiered tenancy: Shared placement has a capacity boundary
Does tiered multitenancy give every small Qdrant tenant independent physical capacity?
The guide places small tenants in a shared fallback shard and describes promotion to dedicated shards. It also documents single-shard transfer constraints and the shared fallback capacity limit. Logical tenant organisation therefore does not establish independent resources, automatic authorisation isolation or unlimited scaling for each tenant.
Claim to check: A tenant identifier proves independent capacity and complete isolation.
Buyer evidence still required
Collection, fallback and dedicated shard configuration.
Tenant placement and capacity evidence.
Separate authorisation and workload-isolation controls.
Suggested review condition: Do not infer independent capacity or access enforcement from a tenant label.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Shard configuration, tenant placement, transfer state and authorisation controls
Optional saved evidence: Retain the distinction between placement, capacity and independently evidenced access controls.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Do small Qdrant tenants share a fallback shard?
When is a tenant promoted to a dedicated shard?
What transfer constraints are documented?
Does logical partitioning prove separate compute?
Can the fallback shard become a shared capacity limit?
Which placement evidence should procurement request?
Does a tenant ID enforce application authorisation?
What happens before transfer becomes active?
Do dedicated shards introduce overhead?
Which scaling claims require measurement?
When should a tenant-isolation claim be qualified?
S3 replication: Copies and deletion propagation are different
Does S3 replication keep every source and destination deletion state identical?
Replication has documented exclusions, including specific object-version deletions and lifecycle-related behaviour. Existing objects and already replicated objects can require separate batch handling. Review the replication rule, delete-marker behaviour and version identity rather than assume a destination is a complete real-time mirror.
Claim to check: Replication guarantees identical deletion state for every object version.
Buyer evidence still required
Source/destination rules and delete-marker configuration.
Version-specific deletion and lifecycle behaviour.
Evidence of existing-object coverage and destination reconciliation.
Suggested review condition: Do not infer a complete mirror or erasure outcome from enabled replication.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Replication rules, version IDs, lifecycle and reconciliation
Optional saved evidence: Preserve the version and rule exceptions relevant to backup and erasure assumptions.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Are permanent version deletions replicated?
Do delete markers follow the same rules?
What happens to lifecycle-generated deletions?
Are pre-existing objects replicated automatically?
Can replicas be forwarded through another live rule?
Does changing the destination re-copy older objects?
Cloud Storage soft delete: Recovery has scope and retention conditions
Does Cloud Storage soft delete guarantee recovery of every deleted object and its access settings?
Soft delete preserves eligible deleted data for the configured retention period, subject to supported bucket types and permissions. The guide notes that managed-folder IAM policies are not restored and that retained deleted objects can continue to incur storage costs. Recovery of content and recovery of its access context are separate questions.
Claim to check: Soft delete guarantees complete recovery of data and all permissions.
Buyer evidence still required
Bucket type and soft-delete policy at deletion time.
Retained object identity, retention interval and restore permissions.
Managed-folder IAM and storage-cost evidence.
Suggested review condition: Require policy, retained-state and access-context evidence before promising recovery.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Bucket type, retention policy, object identity and restore permissions
Optional saved evidence: Save what must be available to recover both data and its required access context.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Which soft-delete policy applied at deletion time?
Can a retained object still incur storage cost?
Are managed-folder IAM policies restored?
Does every bucket type support soft delete?
Can retention expire before a recovery request?
How do lifecycle deletion and versioning interact?
Atlas restore: Point-in-time selection is not a harmless read
Can an agent restore an Atlas cluster to a timestamp without affecting its current data?
The Continuous Cloud Backup guide distinguishes restore scopes and warns that a cluster-level restore deletes existing target data and makes the target unavailable during restoration. Search index definitions can be restored while their data requires initial sync. Timestamp selection is not proof of a non-disruptive or immediately ready result.
Claim to check: A point-in-time restore is non-destructive and instantly ready.
Buyer evidence still required
Source backup point and exact target cluster identity.
Restore scope, required permissions and authorised replacement plan.
Completion evidence including index readiness and application checks.
Suggested review condition: Do not start a cluster-level restore without authority to replace the target state.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Source point, target identity, restore scope and index readiness
Optional saved evidence: Retain the target, scope and readiness questions needed for an authorised recovery decision.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Does a cluster restore overwrite existing Atlas data?
Is the target available during restoration?
Can database-level restore differ from cluster-level restore?
Are search index definitions and data restored identically?
Which dedicated cluster requirements apply?
Which source timestamp or oplog position is selected?
What permissions apply across projects?
Does a completed data restore prove search is ready?
Can a target configuration affect restored settings?
Snowflake Fail-safe: Support recovery is separate from Time Travel
Can an agent use Snowflake Fail-safe as routine extended historical-query access?
Fail-safe follows Time Travel and is described as best-effort recovery by Snowflake when other recovery options have been exhausted. It is not ordinary customer historical access and can take substantial time. The documented service also has exclusions and billing implications; a retention label is not a guaranteed self-service restore.
Claim to check: Fail-safe provides routine immediate access to older queryable history.
Buyer evidence still required
Object type, ingestion architecture and applicable recovery coverage.
Time Travel expiry and remaining Fail-safe interval.
Support recovery scope, expected process and completion evidence.
Suggested review condition: Do not promise self-service historical access or guaranteed recovery from Fail-safe.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Object coverage, ingestion architecture, retention interval and support recovery
Optional saved evidence: Save the recovery-service limitations behind a supplier continuity claim.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
GitHub repository recovery: Fork networks and permissions matter
Does restoring a deleted GitHub repository restore its original access configuration?
The guide describes a bounded restoration window and fork-network conditions, with some cases requiring paid-plan support. It explicitly states that team permissions are not restored. Recovering repository content therefore does not prove that collaboration access or every dependent workflow has been recovered.
Claim to check: Repository restoration recreates content and team access exactly as before.
Buyer evidence still required
Deleted repository identity, timing and fork-network state.
Plan and restoration path eligibility.
Re-established team permissions and dependent workflow checks.
Suggested review condition: Do not claim complete service recovery from repository restoration alone.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Deletion interval, fork network, plan and team permissions
Optional saved evidence: Retain the access and eligibility gaps behind a repository-recovery claim.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Are team permissions restored with a GitHub repository?
Can a non-empty fork network affect recovery?
Is support recovery available on every plan?
What deletion time determines eligibility?
Can a repository take time to appear as restorable?
Who may restore an organisation repository?
What access settings need re-establishment?
Does recovered content prove workflows are operational?
Which fork relationship should procurement record?
D1 Time Travel: Restore replaces the database in place
Can an agent use D1 Time Travel as a read-only way to inspect a past database?
The documented restore overwrites the database in place and cancels in-flight queries. It returns a prior bookmark for reversal, subject to the available history window. This operation is not a clone or a read-only historical query; restoration authority and preservation of the recovery bookmark are separate requirements.
Claim to check: Time Travel restore is non-destructive inspection of an independent copy.
Buyer evidence still required
Database identity and requested timestamp or bookmark.
Plan-dependent history window and authority to replace current state.
Prior bookmark retention and post-restore verification.
Suggested review condition: Require explicit restoration authority before replacing the database.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Database identity, bookmark, plan window and restoration authority
Optional saved evidence: Save the identity, replacement and reversal conditions behind a recovery action.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Does D1 Time Travel create a separate clone?
Can a restore cancel running queries?
What does the returned prior bookmark enable?
Is the recovery window plan dependent?
Does a timestamp map to a stable bookmark?
Can a restore be reversed within available history?
What database identity must be checked?
Does a saved bookmark extend retention forever?
Which application checks follow restoration?
Can an agent inspect history without performing this restore?
GitHub attestations: Verified provenance is not a security verdict
Does a valid GitHub artifact attestation prove the artifact is secure to run?
Attestations bind artifacts to source and build context. The documentation says they must be verified to provide benefit and explicitly rejects treating them as a guarantee of artifact security. The consumer still needs policy criteria and evaluation of the referenced build and content.
Claim to check: A published attestation independently clears an artifact for execution.
Buyer evidence still required
Exact artifact digest and verified attestation result.
Expected source, workflow and build identity.
Consumer policy evaluation and unresolved content risks.
Suggested review condition: Do not substitute signature verification for an execution-suitability decision.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Artifact digest, build identity, verification result and consumer policy
Optional saved evidence: Preserve the provenance check and remaining policy questions for an artifact decision.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Does an attestation guarantee secure software?
Must the consumer verify the attestation?
Which digest identifies the downloaded artifact?
Does the attestation identify the build workflow?
What policy checks remain after verification?
Do public and private repositories use identical transparency infrastructure?
Can a valid signature cover unwanted code?
Does publication prove a consumer checked it?
Which source revision produced the artifact?
What unresolved evidence should procurement retain?
When should an agent refuse a security-clearance claim?
Docker digest pins: Repeatable identity still needs an update process
Does pinning a container image digest automatically keep its security fixes current?
Digest pinning binds a build to a specific image even when a tag moves. The guide explains that this also opts out of automatic updates through the moving tag. Reproducibility and currency therefore require separate evidence: a fixed identity plus a reviewed process for updating it.
Claim to check: A pinned image remains automatically current with publisher fixes.
Buyer evidence still required
Exact base-image digest and platform context.
Publisher update monitoring and review ownership.
Evidence of approved digest updates and resulting builds.
Suggested review condition: Do not claim current fixes solely from a stable digest.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Image digest, platform, update ownership and build evidence
Optional saved evidence: Save the distinction between reproducible identity and maintained software.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Can a Docker tag point to a different image later?
What does a digest pin preserve?
Does pinning automatically receive new fixes?
Who reviews a newer base-image digest?
Can reproducibility and currency conflict?
Which platform image is selected?
Does a current tag prove a deployed digest changed?
What audit trail supports an approved update?
Can an agent change a pin without release authority?
Which build used the recorded digest?
When should a patch-currency claim remain qualified?
npm provenance: Source linkage is not a malware clearance
Does npm provenance guarantee that a package contains no malicious code?
The npm guide explicitly says provenance does not guarantee absence of malicious code. It provides a verifiable link to source and build instructions, with supported publishing environments and separate verification steps. Package identity and provenance verification support a review; they do not replace content evaluation.
Claim to check: A provenance badge proves the package is benign.
Buyer evidence still required
Exact package version and downloaded artifact identity.
Attestation verification with the relevant tooling.
Source/build review and the consumer acceptance criteria.
Suggested review condition: Do not infer benign content solely from provenance availability.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Package identity, attestation format, verifier and acceptance policy
Optional saved evidence: Retain the source linkage and unresolved content questions behind package acceptance.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Does npm provenance rule out malicious code?
What does its source link establish?
Which package version was verified?
Does a registry badge prove local verification happened?
Which CI environments support generation?
Can a build instruction itself be unsafe?
What consumer review remains necessary?
Does the npm CLI version affect verification support?
Which artifact was actually downloaded?
Can provenance be absent without proving maliciousness?
PyPI Trusted Publishing: Short-lived publishing identity is not package approval
Does PyPI Trusted Publishing mean PyPI has reviewed and approved the package code?
Trusted Publishing matches OIDC identities to configured project publishers and exchanges them for short-lived project-scoped upload tokens. It reduces reliance on stored long-lived tokens. That is a publishing-authentication mechanism; the reviewed description does not establish an independent assessment of package contents.
Claim to check: Trusted publisher status is an independent code-quality or safety approval.
Buyer evidence still required
Project publisher configuration and expected CI identity.
Release identity and resulting package version.
Separate code and artifact acceptance evidence.
Suggested review condition: Do not convert publishing authentication into a package-safety claim.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Publisher configuration, CI identity, release version and consumer checks
Optional saved evidence: Save the distinction between an authorised release identity and an accepted artifact.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
What identity does PyPI Trusted Publishing verify?
Does it replace stored long-lived upload tokens?
Are issued tokens scoped to matched projects?
How long is the documented upload token valid?
Does PyPI review the code through this mechanism?
Which CI configuration is trusted?
Can a trusted workflow publish an unwanted release?
What package version corresponds to the release?
Which checks remain with the consumer?
Does no stored token mean no publishing authority?
When should an agent reject a certification claim?
GitLab immutable tags: Rule scope and propagation still matter
Does an immutable container-tag rule make every tag permanently undeletable?
Immutable rules match patterns and differ from role-based protected-tag rules. The guide allows an Owner to delete an immutable rule and describes propagation delays tied to existing tokens. Inspect the actual pattern, rule state and effective time before treating a tag label as permanent or universal protection.
Claim to check: An immutable-tag setting permanently protects every registry tag.
Buyer evidence still required
Matching immutable/protected rules and current ownership rights.
Rule-change time and token propagation interval.
The exact tag and authorised evidence of enforced behaviour.
Suggested review condition: Do not claim permanent universal immutability from a rule label.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Rule patterns, owner authority, token propagation and tag identity
Optional saved evidence: Preserve the pattern and lifecycle evidence behind an image-protection claim.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
How do protected and immutable GitLab tags differ?
Does a rule pattern cover every tag?
Can an Owner remove the immutable rule?
Can token lifetime delay rule enforcement?
Can a new matching tag be created?
Does a permitted push mean overwrite is allowed?
How are direct manifest deletions constrained?
Which registry prerequisites apply?
What exact tag was reviewed?
Does immutability certify image contents?
When should a permanent-protection claim be qualified?
Artifact Registry cleanup: Dry run and keep rules affect deletion
Does configuring an Artifact Registry cleanup policy prove matching artifacts were deleted?
The service distinguishes dry-run evaluation from deletion and applies keep policies alongside delete policies. Cleanup runs as a periodic background job rather than immediate request-time deletion. Configuration alone does not establish removal of a specific version; retain policy evaluation and subsequent artifact state.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Repository mode, keep/delete matches, job evidence and version state
Optional saved evidence: Save the policy and execution evidence behind an artifact-removal claim.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
AWS Budgets: Notifications are delayed cost signals
Does an AWS budget notification threshold impose an immediate per-call spending cap?
AWS Budgets uses periodically updated billing information and documents delay between usage and notification. Additional costs can accrue beyond the threshold before notice arrives. A notification setting alone is therefore not an immediate limit on an agent call; separately configured actions and execution controls need their own review.
Claim to check: A budget alert guarantees no spend beyond the threshold.
Buyer evidence still required
Budget scope, cost basis and notification configuration.
Any separately authorised action or workload spending control.
Usage-to-billing delay and observed alert timing.
Suggested review condition: Do not authorise uncapped calls solely because a billing alert exists.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Budget scope, billing delay, actions and workload spending controls
Optional saved evidence: Preserve the difference between delayed cost awareness and authorised execution limits.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
How often is AWS budget information updated?
Can costs exceed the threshold before notification?
Does an alert stop the resource itself?
Which charges are included in the budget?
Are budget actions separately configured?
Can forecast alerts differ from actual-cost alerts?
What delay should an agent budget account for?
Which workload control limits individual calls?
Does an email prove all usage was current?
What evidence supports a maximum-spend claim?
When should an agent request a tighter spend scope?
Azure budgets: Alerts do not stop consumption by themselves
Does creating an Azure Cost Management budget stop resources when the amount is reached?
The guide explicitly states that budget notifications do not affect resources or stop consumption. Cost data and budget evaluation are delayed; action groups can support separate automation. Record any actual enforcement mechanism rather than present the budget amount as a hard execution cap.
Claim to check: The budget amount is an automatic resource-spending ceiling.
Buyer evidence still required
Budget scope, reset period and alert configuration.
Separate enforcement automation and its authority.
Observed data freshness, evaluation timing and enforcement outcome.
Suggested review condition: Do not infer resource suspension from a budget notification.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Budget scope, evaluation timing, expiry and enforcement automation
Optional saved evidence: Retain which spending controls are alerts and which actually affect execution.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Does an Azure budget stop consumption?
How frequently is budget data evaluated?
Can billing data lag resource use?
What is an action group separate from the alert?
Does a forecast notification enforce a ceiling?
Which subscription or resource group is covered?
Can an expired budget stop evaluating costs?
What automation actually changes resources?
Does a current amount prove immediate enforcement?
Google Cloud budgets: Alerts-only and spend-cap modes differ
Does every Google Cloud budget automatically pause services at its threshold?
Current documentation distinguishes Alerts-only budgets from Spend cap budgets. Alerts-only settings do not impose a cap. Spend-cap state and supported project scope require separate inspection, and usage-reporting delays remain relevant. A generic budget screenshot cannot identify the enforcement mode or prove an absolute instantaneous ceiling.
Claim to check: Every configured Google Cloud budget automatically enforces the amount.
Buyer evidence still required
Budget mode, project scope and current cap status.
Supported services and enforcement configuration for that mode.
Usage delay and observed pause or resumption evidence.
Suggested review condition: Identify the actual budget mode before claiming enforced spending limits.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Budget mode, project scope, cap state and reporting delay
Optional saved evidence: Save the current mode and enforcement evidence behind an agent spending boundary.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
How do Alerts-only and Spend cap budgets differ?
Does an Alerts-only budget pause services?
What does Configured cap status mean?
How does Enforced differ from Lifted?
Which project and services are covered?
Can usage reporting lag consumption?
Does lifting a cap resume everything instantly?
Does a generic budget amount prove enforcement?
What state should an agent inspect before spending?
Which remaining usage can exceed a reported threshold?
Vercel spend pauses: Production scope and excluded usage
Does Vercel Spend Management stop every charge as soon as the spend amount is reached?
A spend amount alone does not stop usage; production pausing must be enabled. Checks occur periodically, so usage can continue after the amount is crossed. The guide also excludes AI Gateway API-key and v0 usage from production pausing. Inspect scope and timing before treating it as a universal spending ceiling.
Claim to check: Production pausing creates an instant ceiling for all team usage.
Buyer evidence still required
Spend amount and enabled pause action.
Inventory of production, AI Gateway and other billed usage.
Observed pause timing and the separate controls for excluded usage.
Suggested review condition: Do not use production pausing as proof that all billable activity stops.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Pause setting, team usage categories, check timing and resumption
Optional saved evidence: Preserve which usage the configured pause affects and what remains outside it.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Does setting a Vercel amount enable pausing automatically?
Can spend continue between checks?
Does pausing cover AI Gateway API-key usage?
Does v0 usage stop with production deployments?
What do visitors see while a deployment is paused?
Does raising the amount automatically resume projects?
Which projects need individual resumption?
What separate control covers excluded usage?
Can an alert alone establish a spending cap?
Which workload is the agent authorised to consume?
BigQuery maximum bytes: A per-query estimate is not an account budget
Does maximum bytes billed cap every BigQuery charge for an agent workflow?
For on-demand queries, maximum bytes billed checks an estimate before execution and can reject a query above the limit. Clustered-table estimates can exceed the eventual billed amount. This query setting does not establish an account-wide budget or cover every storage and capacity charge.
Claim to check: One query byte limit bounds the entire workflow or account bill.
Buyer evidence still required
Billing model and per-query maximum-bytes setting.
Estimated query bytes and rejection/acceptance evidence.
Separate storage, capacity and multi-query workflow costs.
Suggested review condition: Keep account-wide cost claims separate from a single-query byte guard.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Billing model, byte estimate, query settings and other cost categories
Optional saved evidence: Save the exact guard and remaining cost categories for an authorised query workflow.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Which billing model uses maximum bytes billed?
Is the estimate checked before execution?
Can a clustered-table query be conservatively rejected?
Does LIMIT always reduce scanned bytes?
Does the setting cap storage charges?
Can several individually allowed queries exceed a workflow budget?
What estimate did the agent receive?
Does a rejected query prove the actual bytes would exceed the limit?
Snowflake monitors: Warehouse suspension is not a universal credit cap
Does an account-level Snowflake resource monitor stop all serverless and cloud-services charges?
Resource monitors control the documented user-managed virtual warehouses, not every Snowflake-provided serverless feature. Warehouse-level monitors cannot suspend cloud-services usage, and further cloud-services cost can arise after warehouse suspension. An account-level label therefore does not prove every credit-consuming path is capped.
Claim to check: An account monitor enforces a complete credit ceiling across all features.
Buyer evidence still required
Monitor assignment, thresholds and suspension actions.
Inventory of user-managed and serverless consumption.
Cloud-services and excluded-feature controls with observed outcomes.
Suggested review condition: Do not treat warehouse suspension as proof that all credit usage ended.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Warehouse assignments, monitor actions, serverless features and cloud-services usage
Optional saved evidence: Preserve which consumption paths remain outside the monitor used in a purchasing decision.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Does a resource monitor control Snowpipe consumption?
Are automatic clustering charges covered by warehouse suspension?
Can cloud-services costs continue afterwards?
Which warehouses are actually assigned?
Does an account-level label imply all services are controlled?
Can a monitor observe costs it cannot suspend?
Which action is configured at the threshold?
What serverless controls are separate?
Does suspension prove the final bill is fixed?
What consumption path does an agent request?
When should a universal credit-cap claim be qualified?
Snowflake external access: Destinations and credential grants
Does a Snowflake function with external access have unrestricted internet access?
External access integrations select allowed network destinations and authentication secrets. Creating a handler that uses them also requires relevant integration and secret privileges. The integration is an outbound capability; its existence alone does not demonstrate the buyer's effective destination list or the data the handler sends.
Claim to check: External access grants unrestricted outbound access.
Buyer evidence still required
Enabled integration and network-rule inventory.
Secret references and role grants.
Handler purpose and permitted data recipients.
Suggested review condition: Require the destination and data-disclosure scope before approving external calls.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Enabled integration, network rules, secret grants and handler data flow
Optional saved evidence: Preserve the destination, credential and disclosure questions used for a data-platform decision.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Which destinations can a Snowflake handler contact?
Which integration is attached to the function?
Are allowed secrets separately selected?
Who may use the integration?
Does the creator need access to referenced secrets?
Is external access an inbound network policy?
Can a private connection change the network path?
What data does the handler send?
Does an integration name prove the effective allowlist?
Which source version supports the access claim?
When should an agent stop before an external call?
Databricks catalogs: Workspace binding and user grants
Does a SELECT grant prove an agent can access a catalog from any Databricks workspace?
Catalog binding can deny access from an unassigned workspace despite a user's explicit grants. A binding can also restrict that workspace to reads. Ordinary catalogs are open across the metastore by default, while automatically created workspace catalogs have a narrower default. Both binding and identity evidence are needed.
Claim to check: A catalog grant establishes access from every workspace.
Buyer evidence still required
Catalog isolation mode and assigned workspaces.
Binding access level.
User grants and metastore association.
Suggested review condition: Require both workspace and identity scope before asserting access.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Catalog type, isolation mode, workspace binding and user privileges
Optional saved evidence: Keep the identity and execution-location conditions together in a saved review.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Can a catalog binding override SELECT access?
Is a catalog open to every workspace by default?
Does the default workspace catalog behave differently?
Can a binding be read-only?
Which metastore contains the catalog?
Which workspace will the agent use?
Does binding a workspace grant user privileges?
Can a workspace-local admin group apply elsewhere?
BigQuery authorized views: Shared results and query authority
Does a BigQuery authorized view require giving the reader direct access to source tables?
An authorized view can expose selected query results without giving readers direct access to the source dataset. Authorization on the source, access to the view and permission to run a query job are separate. Underlying row and column policies remain relevant; a view name alone is insufficient evidence of the exposed data.
Claim to check: Using a view requires full underlying dataset access.
Buyer evidence still required
View definition and source authorization.
Reader access and query-job project.
Applicable row and column policies.
Suggested review condition: Require the actual view definition and effective grants before approving disclosure.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. View definition, source authorization, reader grants and underlying policies
Optional saved evidence: Preserve a bounded data-sharing decision without overstating source-table authority.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Can an authorized view avoid source-dataset access?
Which project runs the BigQuery job?
Does a viewer need query-job permission?
Who authorized the view on the source?
Which columns does the view expose?
Do underlying row policies still matter?
Are column policies independent of view authorization?
Who can alter the view definition?
What changes when source authorization is removed?
Does a successful query prove every row is permitted?
Redshift RLS: Cross-database and sharing exceptions
Can an agent assume a Redshift RLS policy follows every cross-database or shared-data access path?
The reviewed limitations distinguish ordinary RLS access from cross-database queries and datasharing. Cross-database reads of protected relations are blocked for users without IGNORE RLS; sharing also has explicit restrictions and configuration. Inspect the caller privilege and access path instead of assuming one filter covers all consumers.
Claim to check: One RLS policy proves identical filtering on every data access path.
Buyer evidence still required
Relation RLS and sharing configuration.
Caller privileges including IGNORE RLS.
Cross-database or consumer query path.
Suggested review condition: Require path-specific evidence before claiming row isolation.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Relation settings, RLS exception privileges and sharing path
Optional saved evidence: Retain the access-path exceptions that procurement must resolve for row-level isolation.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Does Redshift RLS apply identically across databases?
What does IGNORE RLS change?
Can a protected relation be shared without configuration changes?
Which consumer cluster runs the query?
Is the caller privileged to bypass a restriction?
Does a blocked query establish a missing row?
What happens when sharing restrictions are changed?
Which relation has the policy attached?
Does a table flag prove consumer isolation?
Which test should the buyer supply for its access path?
When should an agent avoid claiming tenant separation?
IAM changes: Acknowledgement and propagation differ
Does an accepted IAM policy update prove the new permission is effective everywhere immediately?
IAM documents eventual consistency across replicated services and caches. An accepted change can take time to become visible. The buyer needs effective-access evidence for the intended operation; neither an immediate denial nor a successful configuration response alone proves the final permission state.
Claim to check: An accepted IAM change is immediately enforced everywhere.
Buyer evidence still required
Change identifier and intended permission.
Affected service and identity.
Subsequent effective-access observation.
Suggested review condition: Do not retry a consequential operation blindly while permission state is uncertain.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. IAM change, affected identity, service and propagation evidence
Optional saved evidence: Save the distinction between configuration acknowledgement and observed authority.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Can an IAM change be acknowledged before propagation?
Can cached permissions delay visibility?
Which service must observe the new policy?
Does an immediate denial mean the policy is wrong?
Does a configuration success prove effective access?
Should a workflow depend on instantaneous IAM updates?
How should a buyer record a permission transition?
What observation confirms the intended identity is affected?
Can repeated mutation retries cause duplicate effects?
When should the agent pause for state confirmation?
Does this review provide a propagation-time guarantee?
Does an eligible PIM assignment mean an agent's user already has the privileged role?
Eligible assignments require activation before use; active assignments permit use within their assigned duration. Approval is conditional on role settings, not inherent in every activation. Review assignment type, activation state, duration and configured approval rather than treating the word PIM as proof of just-in-time approval.
Claim to check: Every PIM assignment is inactive until independently approved.
Buyer evidence still required
Assignment type and duration.
Current activation evidence.
Role activation and approval settings.
Suggested review condition: Require actual activation and approval evidence appropriate to the role.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Assignment type, activation state, expiry and approval policy
Optional saved evidence: Retain the time and approval conditions behind a privileged-action decision.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Is an eligible Entra role currently active?
Can PIM assignments be permanently active?
Does every activation require approval?
Which activation duration was selected?
When does the assignment expire?
What role settings apply?
Who approved the activation if approval was required?
Can eligibility alone justify an admin action?
Is group activation separate from role activation?
Workload federation: Trusted issuer and accepted identities
Does trusting an external identity provider let every identity from it access Google Cloud?
Workload Identity Federation uses attribute mapping and can apply conditions to accept only selected external identities. Resource access then depends on direct IAM grants or service-account impersonation. Removing a stored service-account key does not establish a narrowly scoped trust relationship by itself.
Claim to check: Keyless federation automatically establishes least privilege.
Buyer evidence still required
Issuer and attribute mapping.
Provider condition and accepted identity set.
Direct grants or impersonated account permissions.
Suggested review condition: Require accepted-identity and resource scope before approving federation.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Issuer, mappings, provider conditions and resource authorization
Optional saved evidence: Preserve the identity-selection and resource-permission evidence for keyless access.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Which external identities pass the provider condition?
Does issuer trust select a repository or tenant?
What attributes are mapped?
Can an attribute condition reject a credential?
Is access granted directly or through impersonation?
Which account is impersonated?
What permissions does that account have?
Does keyless access prove least privilege?
Can two workloads share an overly broad identity mapping?
Which resource grants should procurement inspect?
When should an agent refuse an unidentified workload identity?
GitHub tokens: SSO authorization has its own lifecycle
Does possessing a GitHub personal token prove it can access an SSO-linked organization?
Classic personal tokens need SSO authorization for the organization; fine-grained tokens are authorized during creation. A linked SSO identity can require authorized credentials even without enforced SSO. Scope edits, regeneration, expiry or revocation can change that authorization.
Claim to check: A valid personal token automatically retains organization SSO access.
Buyer evidence still required
Token type and linked organization identity.
SSO authorization state.
Token changes, expiry and organization membership.
Suggested review condition: Require current organization authorization without asking the user to disclose the token.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Token type, SSO linkage, authorization and lifecycle
Optional saved evidence: Save the authorization-state checks needed to diagnose access without widening credentials.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Does a classic token need separate SSO authorization?
When is a fine-grained token authorized?
Can linked identity matter without enforced SSO?
What happens after token scope changes?
Does token regeneration preserve authorization?
Can organization removal affect access?
Who may revoke credential authorization?
Does token validity prove SSO eligibility?
Which organization is the token authorized for?
What evidence can be shared without exposing the token?
When should an agent request reauthorization instead of broader scopes?
GitHub runners: One-job registration and host cleanup
Does an ephemeral self-hosted runner registration prove the underlying machine was wiped?
The runner reference recommends ephemeral autoscaling and describes one-job assignment with automatic deregistration. Host cleanup and external preservation of runner logs remain operator responsibilities. A vanished runner registration is therefore not evidence that residual workspace data or host state was destroyed.
Claim to check: Ephemeral runner registration proves complete host disposal.
Buyer evidence still required
One-job runner configuration.
Host cleanup/disposal evidence.
External runner-log retention.
Suggested review condition: Require host lifecycle evidence before asserting isolation between jobs.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Runner registration, host lifecycle, log forwarding and version
Optional saved evidence: Preserve the distinction between scheduler lifecycle and demonstrated environment disposal.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Does ephemeral registration erase the runner machine?
How many jobs does an ephemeral runner receive?
What does automatic deregistration establish?
Who cleans up the host after the job?
Where are runner diagnostic logs retained?
Can workspace data survive deregistration?
What evidence proves a new host was used?
Does autoscaling imply ephemeral workers?
Which update requirements affect job availability?
Can a reused host bridge trust boundaries?
When should an agent withhold a clean-runner claim?
GitLab runners: Executor choice and cross-job trust
Does running a GitLab job in Docker establish isolation from the runner host?
GitLab distinguishes shell, non-privileged and privileged container execution. Privileged mode exposes substantially more host authority; reusable runners can also carry effects across projects. A container label alone is insufficient: executor, privileges, reuse and network reach determine the review scope.
Claim to check: A Docker executor is automatically an adequate isolation boundary.
Buyer evidence still required
Executor and privilege configuration.
Runner reuse and project assignment.
Host identity and network access.
Suggested review condition: Do not approve untrusted execution based only on the word container.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Executor, privileges, reuse, project scope and host network
Optional saved evidence: Retain the concrete executor and reuse evidence behind CI access approval.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Is the GitLab runner using privileged mode?
Does the job share the host process namespace?
Which user executes a shell job?
Is the runner reused by multiple projects?
Can repository-controlled scripts access host resources?
What network segment can the runner reach?
Does protected-branch selection replace isolation evidence?
Are workspaces reused between jobs?
Which secrets can enter the environment?
What disposal evidence is available?
When should an agent decline untrusted job execution?
CircleCI caches: Immutable keys can preserve the wrong result
Does an immutable CircleCI cache prove a build used the correct dependencies?
A cache key cannot be overwritten after its first write. Parallel writers can therefore make the selected content depend on completion order, while later writes are discarded. Correctness requires appropriate keys and workflow ordering; immutability alone neither validates dependencies nor guarantees freshness.
Claim to check: Cache immutability proves dependency correctness and freshness.
Buyer evidence still required
Cache-key inputs and lockfile identity.
Writer/reader job ordering.
Installation and dependency verification evidence.
Suggested review condition: Require dependency identity before treating a cache hit as a reproducible build.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Cache keys, writer ordering, dependency lock and verification
Optional saved evidence: Save the dependency identity and workflow assumptions behind a build claim.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Buildkite hooks: Repository control can affect enforcement
Does an agent-wide Buildkite hook alone enforce the same security policy for every repository?
The security guide warns that repository-local hooks can evade policies enforced by agent hooks. Disabling local hooks also disables plugins, and a checkout containing a local hook then fails. Policy review must include repository influence, job environment and the trade-off of disabled extensions.
Claim to check: An agent hook alone proves untrusted jobs cannot alter enforcement.
Buyer evidence still required
Agent and local-hook settings.
Permitted plugins and environment overrides.
Repository trust and containment evidence.
Suggested review condition: Require repository-influence evidence before accepting a hook as an enforced boundary.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Hook settings, plugins, environment overrides and repository trust
Optional saved evidence: Preserve the repository and extension conditions behind a CI policy claim.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Are local Buildkite hooks still enabled?
Can repository hooks affect an agent policy?
Does disabling local hooks also disable plugins?
What happens when a forbidden local hook is present?
Who can change repository hook files?
Can job environment variables override settings?
Which containment surrounds untrusted code?
Is a hook a policy or evidence of enforcement?
Which plugins are allowed?
How are policy failures recorded?
When should an agent stop before running an untrusted build?
Notion export: Accessible content is not an instant restore
Does a Notion workspace export prove that the whole workspace can be restored?
Exports omit pages the exporter cannot access and can be limited by teamspace settings. The guide also states that uploading exported content does not instantly recreate the workspace. Export coverage and a demonstrated restoration workflow are separate evidence requirements.
Claim to check: A workspace export is a complete restorable backup.
Buyer evidence still required
Exporter access and teamspace restrictions.
Export contents and excluded pages.
Documented restoration procedure and trial evidence.
Suggested review condition: Do not claim complete recovery from an export file alone.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Exporter permissions, teamspace settings, formats and recovery procedure
Optional saved evidence: Keep export coverage and outstanding recovery evidence attached to an exit or continuity decision.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Does a Notion export include other users' private pages?
Can teamspace settings limit export content?
Which identity performed the export?
Does exported HTML recreate workspace settings?
Can reuploading instantly restore the workspace?
Are uploaded files present in the archive?
Which formats were selected?
Was the export download retrieved before expiry?
What is missing from the inventory?
Has a restoration path actually been demonstrated?
When should an agent describe the file only as an export?
Airtable CSV: Attachment links are not archived files
Does an Airtable CSV export preserve everything needed to leave the service?
CSV export is view/table based and includes visible field values. It omits several non-field objects, and attachments appear as filenames and expiring URLs rather than embedded files. A full exit plan needs separate attachment capture, view-filter checks and an inventory of omitted content.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Exported view, filters, attachments, omitted objects and target import
Optional saved evidence: Save the file and non-tabular gaps that a procurement exit plan must resolve.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Does Airtable export a whole base as one CSV?
Are hidden or filtered records included?
Are attachments embedded in the CSV?
Can attachment URLs expire?
Are record comments included?
Are field descriptions preserved?
What extension data is omitted?
Which tables were exported?
Were linked files downloaded successfully?
Does CSV import reproduce the original base behaviour?
Jira Cloud export: App data and automation need separate handling
Does a Jira Cloud backup include third-party app data and automation configuration?
The export guide excludes third-party apps and app data, and automation flows require their own export/import. Cloud and Data Center destinations have different compatibility constraints. A backup file therefore needs an inventory and target-specific restore evidence before it supports a full migration claim.
Claim to check: The native backup captures the entire operational Jira environment.
Buyer evidence still required
Backup type and intended destination.
App-data and automation export inventory.
Restore validation and missing configuration list.
Suggested review condition: Require excluded-component evidence before approving migration completeness.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Backup type, destination, app data, automation and restore eligibility
Optional saved evidence: Preserve the excluded integrations and destination constraints behind a migration decision.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Does Jira backup include third-party app data?
Are automation flows exported automatically?
Which restore destination is intended?
Are Cloud and Data Center formats interchangeable?
What attachments were selected?
Can cross-application links still point to the old site?
Which credentials need reconfiguration?
Are team-managed objects compatible with the destination?
Does backup age affect restore eligibility?
What was verified after import?
When should an agent avoid promising complete migration?
Confluence exports: Format and exporter identity change coverage
Can a Confluence PDF or HTML export stand in for a complete space backup?
Export formats preserve different content. PDF omits comments; HTML has additional exclusions, and Team Calendars are not included. Visibility and administrator exceptions also affect coverage. Record the format and exporter identity instead of assuming every space export is a complete archival copy.
Claim to check: All Confluence space export formats preserve the same evidence.
Buyer evidence still required
Format and selected content.
Exporter role and visibility.
Comments, calendars and unpublished-content inventory.
Suggested review condition: Require format-specific coverage before claiming archive completeness.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Export format, selected objects, exporter identity and import destination
Optional saved evidence: Retain the coverage limitations behind a knowledge-system retention or exit decision.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
S3 private paths: Endpoint existence and enforced restriction
Does creating an S3 VPC endpoint prove the bucket can only be reached through it?
The documented restriction uses a bucket policy tied to a VPC or endpoint condition. Endpoint existence is not that policy evidence. An explicit deny can also block console access and cause lockout if the identifier is wrong, so the effective policy and intended alternate access require review.
Claim to check: An S3 endpoint automatically restricts every bucket access path.
Buyer evidence still required
Bucket policy and referenced endpoint/VPC.
Identity permissions and alternate access paths.
Authorized validation and recovery access plan.
Suggested review condition: Require the enforcing policy before claiming private-path-only access.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Bucket policy, endpoint identity, callers and alternate access
Optional saved evidence: Save the policy and access-path evidence behind a private-storage claim.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Does endpoint creation restrict the S3 bucket policy?
Which endpoint ID does the policy reference?
Is an explicit deny present?
Can the console be blocked by the restriction?
What happens if the VPC identifier is wrong?
Does a VPC condition cover multiple endpoints?
Which principals still have bucket permissions?
How are service access paths handled?
What evidence confirms the intended network path?
Is there an authorized recovery path for lockout?
When should an agent avoid changing the policy automatically?
VPC Service Controls: A perimeter is separate from IAM
Does a Google Cloud service perimeter replace resource permissions?
VPC Service Controls supplies context-based perimeter checks in addition to IAM. Ingress/egress rules and supported-service scope determine which paths it covers. A perimeter configuration does not establish least-privilege identities or coverage for every service operation.
Claim to check: A service perimeter replaces identity authorization for all services.
Buyer evidence still required
Restricted services and resource inventory.
Ingress, egress and access-level rules.
Effective IAM permissions.
Suggested review condition: Require both identity and perimeter evidence before approving data isolation.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Perimeter resources, supported services, access rules and IAM
Optional saved evidence: Preserve two separate control layers in a cloud data-sharing decision.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Does VPC Service Controls replace IAM?
Which services are restricted?
Which resources are inside the perimeter?
What ingress rule admits the client?
Which egress operations are allowed?
Are unsupported services covered identically?
Does network origin alone establish identity authority?
Azure private endpoints: Public access and service targets remain separate
Does adding an Azure Storage private endpoint automatically disable public network access?
The storage guide treats the private endpoint and public-endpoint access rules separately. Storage services need their applicable endpoints, and name resolution must reach the private address. An endpoint's existence alone does not prove all service traffic uses it or that public access is blocked.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Storage service, endpoint, DNS and public access settings
Optional saved evidence: Keep the endpoint, DNS and public-access conditions behind a private-network claim.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Does a private endpoint disable the storage public endpoint?
Which storage service has an endpoint?
Can Blob and DFS operations need separate endpoints?
What address does the client resolve?
Should the normal storage hostname remain in use?
Do firewall rules govern private traffic identically?
Which VNet is associated?
Can custom DNS change the selected path?
Does successful Blob access prove every service works?
What evidence confirms public access is blocked?
When should an agent avoid claiming complete network isolation?
Snowflake network rules: Definition is separate from activation
Does creating a Snowflake network rule make it an enforced account restriction?
The network guidance requires activation at the relevant account, user or integration scope. It also distinguishes inbound access from external-access egress, and integration-level policies have storage-stage limitations. A defined rule is not proof of the applicable active policy.
Claim to check: A stored network rule is an active universal restriction.
Buyer evidence still required
Rule-to-policy membership.
Active policy association and scope.
Covered service/stage and separate outbound configuration.
Suggested review condition: Require the active association before relying on the rule.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Rule membership, active policy association and covered endpoint
Optional saved evidence: Save the active-scope evidence behind a vendor network-control claim.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Is the Snowflake network rule active anywhere?
Which policy includes it?
Is the policy attached to the account or user?
Does a user association replace an earlier policy?
What does an integration-level policy cover?
Are internal stages covered identically?
Does an inbound policy restrict outbound handlers?
Which active association can the buyer show?
Can a stored definition be unused?
What scope should an agent report?
When should a network restriction remain unverified?
Langfuse deletion: Accepted requests and completed removal differ
Does a Langfuse trace deletion response prove all related personal data is gone?
Tracing deletion is asynchronous and the guide recommends querying again to check completion. Removing traces does not necessarily remove data held in other objects such as datasets, and later ingestion can add data again. Scope, timing and verification need separate evidence.
Claim to check: A trace-deletion request proves complete immediate erasure.
Buyer evidence still required
Selected trace IDs and related object inventory.
Ingestion state and completion checks.
Separate dataset and other retained-object review.
Suggested review condition: Do not convert deletion acceptance into a complete-erasure assertion.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Deletion selection, ingestion, related objects and completion evidence
Optional saved evidence: Preserve deletion scope and outstanding completion checks without inventing an erasure guarantee.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Is Langfuse trace deletion synchronous?
Is a deletion confirmation sent?
How can completion be checked?
Do datasets remain outside trace deletion?
Can later ingestion recreate related data?
Which trace IDs were selected?
Does deleting a project revoke its keys immediately?
Can project deletion continue in the background?
What objects were outside the requested scope?
Does missing UI content prove complete backend removal?
LangSmith shared traces: Read-only links can widen the audience
Does a read-only LangSmith trace link keep its content restricted to account members?
A publicly shared trace can be viewed by anyone holding its link without a LangSmith account. Self-hosted network constraints can limit reach. Read-only describes editing, not confidentiality; inspect the trace and deployment before sharing, and distinguish unsharing from deleting the underlying trace.
Claim to check: Read-only trace sharing preserves account-only confidentiality.
Buyer evidence still required
Public sharing state and deployment reachability.
Trace content review.
Unshare and deletion procedures.
Suggested review condition: Require disclosure authority before sharing a trace outside its existing audience.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Sharing state, network reachability, trace content and revocation
Optional saved evidence: Retain the audience and content-disclosure decision for diagnostic collaboration.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Can a person without a LangSmith account view the link?
Does read-only mean confidential?
Which trace inputs or outputs are exposed?
Does a private self-hosted network limit access?
Who has the shared URL?
Can the workspace list shared traces?
Is unsharing the same as deleting a trace?
Which deployment created the link?
Was sensitive content reviewed first?
Does revocation retract copies already obtained?
When should an agent decline public trace sharing?
Datadog Audit Trail: Enablement, retention and archive are separate
Does enabling Datadog Audit Trail guarantee indefinite searchable audit history?
The guide provides configurable retention and a separate optional archive path. Archive upload has an interval and setup delay; it is not immediate evidence that every event is retained in the buyer's bucket. Enablement, retention and verified archive delivery need distinct checks.
Claim to check: Enabled Audit Trail guarantees permanent searchable history.
Buyer evidence still required
Audit Trail enablement and retention selection.
Archive destination and permissions.
Observed archive delivery and downstream retention.
Suggested review condition: Require retained-event evidence for the required review period.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Enablement, retention, archive configuration and delivery evidence
Optional saved evidence: Save the retention and export assumptions behind an audit-evidence requirement.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
What retention is configured for Datadog Audit Trail?
Is archiving separately enabled?
Which destination receives events?
Can archive uploads be delayed?
Who controls bucket retention?
What happens to retention when Audit Trail is disabled?
Does a current event prove historic coverage?
Which product actions are audited?
Was archive delivery actually observed?
Does storage existence prove searchable history?
When should an agent avoid promising indefinite evidence?
Sentry outcomes: Missing events need ingestion context
Does an empty Sentry event search prove that no error occurred?
The reviewed experimental endpoint reports received-but-dropped events alongside accepted volume. It distinguishes filtering, rate limits and other drop reasons. These counts describe ingestion outcomes, not every event generated by an application; missing events require telemetry and filtering context before a conclusion.
Claim to check: No matching stored events proves no application error occurred.
Buyer evidence still required
SDK/ingestion coverage.
Accepted and dropped outcomes for the interval.
Filters, quotas and query scope.
Suggested review condition: Require collection and outcome evidence before making an absence claim.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Experimental API version, collection scope, outcomes and query interval
Optional saved evidence: Preserve the ingestion limitations behind a monitoring or incident-evidence conclusion.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Can Sentry receive an event and still drop it?
Which outcome indicates filtering?
Which outcome indicates rate limiting?
Are accepted counts filtered in the same way?
What interval and dataset were queried?
Does the experimental API have a stable contract?
Can client-side losses be absent from server counts?
Were project or environment filters applied?
Does accepted volume equal complete application coverage?
What explains a missing stored event?
When should an agent refuse a no-error conclusion?
Kubernetes service tokens: Audience, lifetime and object binding
Can an agent reuse a projected Kubernetes service-account token as a permanent general API credential?
Projected tokens obtained through TokenRequest are time-bound and normally bound to the Pod and Kubernetes API audience. Long-lived manually created tokens are a different mechanism. Credential review must identify token type, audience and object lifetime rather than assume all service-account tokens behave alike.
Claim to check: Every service-account token is a permanent general credential.
Buyer evidence still required
Token issuance mechanism and audience.
Expiry and bound object identity.
Effective service-account permissions.
Suggested review condition: Decline reuse outside the token's intended audience or lifetime.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Token type, audience, expiry, object binding and RBAC
Optional saved evidence: Retain issuance, lifetime and audience boundaries for workload identity procurement.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Was the token issued through TokenRequest?
Is it a legacy Secret-based credential?
Which audience is intended?
Which Pod is it bound to?
What happens when the bound Pod is deleted?
Does the kubelet rotate projected credentials?
Does token validity prove broad RBAC authority?
Can a service-account UID change invalidate tokens?
Should a temporary token be stored as a permanent secret?
Which relying service validates the audience?
When should an agent request an appropriate credential instead?
GitHub App keys: Rotation requires retiring the old signer
Does generating a new GitHub App private key automatically retire the old one?
The guide supports multiple concurrent private keys for rotation and states that keys do not expire automatically. A new key therefore does not establish that the old signer is revoked. Inventory, consumer handoff and explicit old-key removal need evidence separate from successful generation.
Claim to check: Generating a replacement key completes key retirement.
Buyer evidence still required
Current key inventory without secret values.
Consumer migration evidence.
Old-key deletion/revocation record.
Suggested review condition: Require retirement evidence before declaring rotation complete.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Key inventory, consumers, storage and explicit retirement
Optional saved evidence: Preserve the migration and retirement evidence for application signing credentials.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Can a GitHub App have multiple valid private keys?
Do private keys expire automatically?
Does adding a key revoke the old one?
Which consumers have switched signers?
Can the last key be deleted without a replacement?
What evidence identifies a key without exposing it?
Who can manage app keys?
Is private-key retirement the same as installation-token expiry?
Vault wrapping: Delivery-token expiry is not secret expiry
Does a short-lived Vault wrapping token make the underlying secret expire at the same time?
Response wrapping delivers a single-use token with its own lifetime instead of the original response. That lifetime is separate from the wrapped secret. Creation-path inspection and unwrap status help review delivery, but failed unwrapping alone does not prove interception; expiry is another possible cause.
Claim to check: A wrapping token's lifetime is the lifetime of the wrapped credential.
Buyer evidence still required
Wrapping creation path and expiry metadata.
Underlying secret or lease lifecycle.
Authorized unwrap outcome.
Suggested review condition: Keep delivery-token and underlying-credential lifetime claims separate.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Wrapping metadata, origin, unwrap state and secret lifecycle
Optional saved evidence: Retain separate delivery and credential-lifetime evidence for a secret handoff.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Is a wrapping token single-use?
Does its TTL equal the secret lifetime?
Can the creation path be inspected before unwrap?
Does failed unwrap prove interception?
Could the token have expired first?
Which Vault server validates the token?
Does the wrapping response contain the original secret?
Can a relay inspect the wrapped secret without unwrapping?
What separate lease evidence is needed?
Who is authorised to unwrap it?
When should an agent investigate an unexpected unwrap failure?
Secret Manager schedules: Notification is not completed rotation
Does configuring a Secret Manager rotation schedule replace the credential and update every application?
The schedule sends a Pub/Sub rotation notification. A subscriber must perform the required work, such as creating a new secret version and deploying it to consumers. Notification retries and skipped in-flight schedules also matter; the configured timer alone is not proof of completed rotation.
Claim to check: A rotation schedule automatically replaces and deploys the credential.
Buyer evidence still required
Schedule and Pub/Sub delivery evidence.
Subscriber action and new-version evidence.
Consumer rollout and old-credential retirement.
Suggested review condition: Require completion evidence beyond the scheduled notification.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Schedule, topic delivery, subscriber action, rollout and retirement
Optional saved evidence: Preserve the notification-to-rollout chain behind a credential-rotation claim.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Does SECRET_ROTATE contain a new credential?
Who subscribes to the rotation topic?
Which workflow creates the replacement version?
How do applications receive it?
Can a schedule be skipped while delivery is in flight?
Are delivery retries guaranteed to succeed?
Which permissions allow the subscriber to act?
What proves consumers changed credentials?
Was the old credential retired?
Does next_rotation_time prove a completed rotation?
SQS visibility: Temporary hiding is not completion
Does an SQS visibility timeout prove a task was processed once?
Visibility temporarily hides a received message. Without deletion it becomes available again when the timeout expires, and standard-queue delivery can still duplicate messages. A lease period is not proof that downstream work committed or that repeating the work is harmless.
Claim to check: A visibility timeout guarantees one completed business action.
Buyer evidence still required
Queue type and visibility settings.
Consumer deletion and lease-extension behaviour.
Business-operation identity and retry evidence.
Suggested review condition: Require business completion evidence before treating an invisible message as a finished action.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Queue type, visibility lease, consumer acknowledgement and business idempotency.
Optional saved evidence: Preserve the evidence questions separating queue state from a completed customer action.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
What does SQS visibility actually guarantee?
Does receiving a message delete it?
What happens when a worker crashes before deletion?
Can a standard queue still deliver duplicates?
Can long processing outlast the lease?
Is extending visibility the same as committing a result?
Which worker deletes the message?
How are repeated external effects detected?
Can in-flight limits stall consumers?
What proves the downstream operation finished?
Should an agent retry a timed-out action blindly?
Can I save the reviewed queue-completion boundary?
SQS FIFO: Deduplication scope and business effects
Does FIFO deduplication prevent every duplicate business action?
SQS suppresses repeated sends within its documented deduplication interval. Content-based IDs use the message body rather than message attributes. This queue admission behaviour does not establish a transaction across the consumer and an external service, or protection for retries beyond that interval.
Claim to check: FIFO queue deduplication proves end-to-end exactly-once effects.
Buyer evidence still required
Deduplication mode and message-ID construction.
Retry timing and body-versus-attribute use.
Consumer-side commit and replay handling.
Suggested review condition: Do not equate duplicate-send suppression with atomic downstream processing.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Deduplication configuration, message identity, retry interval and consumer transaction boundary.
Optional saved evidence: Save the source basis for evaluating exactly-once claims in a queued service.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
How long does FIFO deduplication remember a send?
Are message attributes included in the content hash?
Can changed attributes share one deduplication identity?
Who assigns the deduplication ID?
What happens to a retry outside the interval?
Does FIFO coordinate a payment transaction?
Can a worker crash after its external action?
What evidence proves safe consumer replay?
Are queue admission and business completion separate?
Does an accepted send prove a new message was added?
EventBridge: Retry exhaustion and retained failures
Does an EventBridge rule guarantee eventual delivery to its target?
EventBridge retries retriable target failures within configured age and attempt limits. The documented defaults are bounded, and exhausted delivery attempts can end in a dropped event. A dead-letter queue needs separate configuration; a rule existing is not evidence that undelivered events are retained or recovered.
Claim to check: A configured rule retries until delivery succeeds.
Buyer evidence still required
Target retry age and attempt settings.
Dead-letter destination and permissions.
Failure monitoring and replay ownership.
Suggested review condition: Require an exhaustion and recovery plan before asserting eventual delivery.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Rule target, retry policy, dead-letter configuration and operational replay ownership.
Optional saved evidence: Retain the documented delivery limits used to assess a supplier event integration.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Can EventBridge stop retrying a target?
Which retry age is configured?
Which attempt limit applies?
Does every failure qualify for retry?
Where do exhausted events go?
Is a dead-letter queue actually configured?
Can EventBridge write to that queue?
Who checks retained failures?
Does target acceptance prove business processing?
Is replay authorized and deduplicated?
What evidence supports a delivery assurance claim?
Can I preserve the reviewed failure-retention basis?
Lambda async: Accepted events, duplicates and expiry
Does successful asynchronous Lambda invocation prove the function completed?
Asynchronous invocation uses a service queue. Function errors and throttling follow different retry behaviour; duplicate delivery is possible even without a function error. Events can expire or exhaust attempts. Dead-letter queues and failure destinations capture different failure information and require configuration.
Claim to check: An accepted asynchronous request guarantees one completed function execution.
Buyer evidence still required
Asynchronous retry and maximum event-age settings.
Failure destination or dead-letter configuration.
Function idempotency and completion evidence.
Suggested review condition: Keep request acceptance separate from verified completion and failure recovery.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Invocation mode, event age, retry policy, concurrency and failure destinations.
Optional saved evidence: Preserve the acceptance-versus-completion boundary for automated integration review.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Can Lambda deliver an asynchronous event twice?
Does a successful invocation request prove completion?
Are function errors and throttles retried alike?
Can an event expire before execution?
What happens after all processing attempts fail?
Is a dead-letter queue configured?
Does a failure destination contain invocation context?
Can a saturated function lose aged events?
How does the handler detect repeated work?
Which identifier ties acceptance to completion?
What should procurement request for failure recovery?
Step Functions redrive: Original execution identity
Does redriving a failed workflow use the newly deployed fix?
Eligible Standard Workflow redrives retain the original execution identity, input and state-machine definition. Successful steps are generally preserved while failed work resumes according to state-specific rules. Updating an alias does not make a redrive use its new version; redrive and starting a new execution are different decisions.
Claim to check: Redrive automatically picks up the latest workflow deployment.
Buyer evidence still required
Original execution version and input.
Failure state and state-specific redrive behaviour.
External side-effect and reconciliation evidence.
Suggested review condition: Check the original definition and prior side effects before approving recovery.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Workflow type, original version, execution history, eligibility and external effects.
Optional saved evidence: Save the recovery decision basis without implying that retrying applies a new software fix.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Does Step Functions redrive follow an updated alias?
Is the original execution ARN preserved?
Are successful steps always started again?
Which failed state resumes?
Does redrive reuse the original input?
Is this a Standard or Express workflow?
Is the execution still eligible for redrive?
Can a task have committed externally before failure?
Which state-specific rules apply?
When is a new execution a different operation?
What evidence should an agent retain for recovery?
Does an expired DynamoDB TTL make a record immediately unavailable?
TTL deletion occurs asynchronously, typically within days. Expired items awaiting deletion can still be updated and appear in reads unless the application filters them. The attribute must have the documented numeric timestamp format. An expired timestamp alone does not establish removal or fulfil an erasure commitment.
Claim to check: An expired TTL timestamp proves immediate record deletion.
Buyer evidence still required
Table TTL attribute and item value type.
Read filtering and update behaviour.
Deletion evidence and any separately retained copies.
Suggested review condition: Require actual deletion evidence for an erasure claim; do not infer it from expiry alone.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Table TTL configuration, item attributes, reads, replicas and retained-copy scope.
Optional saved evidence: Preserve the evidence needed to challenge an immediate-erasure claim.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
S3 Lifecycle: Billing changes and physical removal
Does storage billing stopping prove an S3 object has already been deleted?
Lifecycle actions can be queued after an object becomes eligible. Billing changes normally follow eligibility even if the action happens later, with documented exceptions for some transitions. Therefore billing status or a scheduled expiration is not an object-level deletion receipt.
Claim to check: Lifecycle billing state proves completed physical deletion.
Buyer evidence still required
Lifecycle rule filters and action type.
Object version and eligibility date.
Object-level action evidence and retained versions.
Suggested review condition: Do not use a billing change as proof that all object versions were removed.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Lifecycle filters, action, storage class, versioning and object-level state.
Optional saved evidence: Save a bounded retention review that distinguishes invoices from removal evidence.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Can an expired S3 object await Lifecycle processing?
Does billing stop before the object is removed?
Which transitions have different charging rules?
Does the rule cover existing objects?
Which object versions match the rule?
Is the action expiration or transition?
Are minimum storage duration charges relevant?
Does an expiration date constitute a deletion receipt?
Can old versions require separate handling?
What verifies the actual object state?
Which evidence should a procurement reviewer request?
Can I preserve this lifecycle evidence distinction?
Pub/Sub exactly-once: Acknowledgement and regional scope
Does Pub/Sub exactly-once delivery cover every subscription and external action?
The documented feature applies to pull subscriptions within a cloud region. Successful acknowledgement prevents redelivery of that message, while expired acknowledgement deadlines can lead to a new valid delivery. It does not establish an atomic transaction with an external business system or deduplicate separate publisher messages.
Claim to check: Exactly-once delivery guarantees every business effect happens once globally.
Buyer evidence still required
Subscription type and feature enablement.
Subscriber region and acknowledgement results.
Publisher identity and downstream commit handling.
Suggested review condition: Require the regional, subscription and business-transaction scope before accepting an exactly-once claim.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Subscription mode, region, acknowledgement handling, publisher IDs and downstream transaction.
Optional saved evidence: Preserve the precise delivery guarantee and excluded business effects for supplier evaluation.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Does Pub/Sub exactly-once support push subscriptions?
Which cloud region contains subscribers?
Was acknowledgement actually successful?
What happens after an acknowledgement deadline expires?
Can an old acknowledgement ID fail?
Are separate publishes the same message?
Does delivery guarantee an external database commit?
Can subscriber progress be recovered after a crash?
Is the feature enabled on this subscription?
What evidence links processing to acknowledgement?
Which claims remain outside the delivery guarantee?
Does assigning a Cloud Tasks name make the handler operation exactly-once?
A caller-selected task name supports task-creation deduplication. It does not demonstrate that a handler's external work committed once. Delivery headers distinguish retries from executions, and the scheduled ETA changes on retries; the publisher explicitly says ETA is not a deduplication key.
Claim to check: A task name or ETA guarantees one completed handler effect.
Buyer evidence still required
Task naming and creation path.
Handler operation identity and commit evidence.
Retry and execution counters used in reconciliation.
Suggested review condition: Require a stable business identity rather than using ETA as proof of unique work.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Task creation method, naming, handler authentication, counters and downstream commit semantics.
Optional saved evidence: Retain the distinction between queue identity and a completed business operation.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Can a named Cloud Task suppress duplicate creation?
Does that prove the handler ran once?
Is ETA stable across retries?
Can the retry count include attempts before execution?
How does execution count differ?
Who supplies the task name?
Is BufferTask the same as CreateTask?
Does a handler response prove an external commit?
What identifies repeated business work?
Can deduplication affect creation latency?
Which delivery evidence should a buyer retain?
Can I save the task-versus-business identity boundary?
BigQuery deletion: Recovery windows remain material
Does deleting a BigQuery table immediately remove all retained history?
Changed or deleted table data remains within the configured time-travel window, followed by a separate fail-safe period. A deleted table uses the window in force at deletion; increasing the setting later does not simply extend that earlier deletion's recovery window. These are retention boundaries, not a legal erasure conclusion.
Claim to check: Delete removes all history immediately or later settings automatically extend recovery.
Buyer evidence still required
Dataset time-travel setting at deletion.
Deletion time and required recovery point.
Fail-safe and separately retained-copy scope.
Suggested review condition: Distinguish ordinary query visibility, recoverability and final retention before asserting removal.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Dataset and table identity, deletion timestamp, configured window and separate copies.
Optional saved evidence: Save the dated retention evidence used to assess deletion and recovery commitments.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Can deleted BigQuery data remain recoverable?
Which time-travel window applied at deletion?
Does extending the window later restore expired history?
Is fail-safe the same as normal time travel?
Can I query every fail-safe version directly?
What permissions are needed for recovery?
Was the dataset or just a table deleted?
Are snapshots and exports separately retained?
Does a missing table prove erasure?
Which deletion timestamp should be recorded?
What evidence supports the retention statement?
Can I preserve the reviewed recovery-window basis?
Secret Manager: Scheduled destruction and recoverability
Does a destroy request always mean secret material is already irrecoverable?
Secret-version destruction is immediate by default, but a configured destruction delay preserves a recovery interval. During that delay the version is scheduled for destruction and authorized administrators can cancel it. A request acknowledgement must therefore be interpreted with the secret's delay configuration and actual version state.
Claim to check: A destroy request proves irreversible destruction in every configuration.
Buyer evidence still required
Secret destruction-delay setting.
Version state and scheduled destruction time.
Authorized recovery actions and final-state evidence.
Suggested review condition: Do not claim irreversible destruction while a configured recovery interval remains.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Secret and version identity, destruction delay, administrator grants and state timestamps.
Optional saved evidence: Preserve the evidence distinguishing access disablement, pending destruction and final destruction.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Is delayed destruction enabled on this secret?
Does the default behaviour differ?
What state follows a delayed destroy request?
Who can cancel scheduled destruction?
Can the version be restored during the delay?
When does destruction become irreversible?
Are notifications configured separately?
Which version was targeted?
Does disabling a version destroy its material?
What proves the final state?
Can an agent infer destruction from an API acknowledgement alone?
Service Bus: Accepted sends and duplicate suppression
Does a successful Service Bus send prove a new message was enqueued?
With duplicate detection enabled, a repeated message identity within the configured window can receive a successful send response while the duplicate is discarded. The feature is tier-dependent and identity construction matters. It does not prove that a downstream consumer completed a unique business action.
Claim to check: Every successful send acknowledgement represents a new queued operation.
Buyer evidence still required
Service tier and duplicate-detection window.
Message identity and partition settings.
Consumer completion and replay records.
Suggested review condition: Reconcile stable message identity before counting accepted retries as new work.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Tier, entity, detection window, message ID, partitioning and consumer effects.
Optional saved evidence: Save the evidence needed to interpret ambiguous sends and prevent inflated completion counts.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Can Service Bus accept and drop a duplicate send?
Which tiers support duplicate detection?
Is the feature enabled on this entity?
How long is the configured history window?
Does message body content determine duplication?
How do partition settings affect identity?
Are scheduled messages included?
Can changing IDs defeat deduplication?
Does deduplication affect throughput?
What proves the consumer completed the action?
Which evidence prevents double-counted orders?
Can I retain the reviewed send-acknowledgement boundary?
Event Grid: Order, bounded retries and dead letters
Does Event Grid guarantee ordered delivery until a subscriber succeeds?
Event Grid attempts at-least-once delivery without guaranteeing event order. Retry behaviour depends on error type and configured limits; some failures are not retried. Events can be dropped when limits are reached or no dead-letter destination exists. Consumers need evidence of ordering and recovery appropriate to their workflow.
Claim to check: Event Grid guarantees ordered, indefinitely retried processing.
Buyer evidence still required
Subscription retry limits and endpoint error handling.
Dead-letter storage and write permissions.
Consumer ordering, deduplication and replay policy.
Suggested review condition: Do not infer ordered business processing from durable event delivery.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Endpoint type, subscription limits, dead-letter destination and consumer state handling.
Optional saved evidence: Preserve the delivery limitations used to assess an event-driven supplier integration.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Can Event Grid events arrive out of order?
Can duplicate deliveries still occur?
Which errors are not retried?
Does either retry limit stop delivery?
Is dead-lettering enabled?
Can the service reach dead-letter storage?
Does a late acknowledgement remove every retry?
How does the consumer recognize stale events?
Who replays failed deliveries?
Does endpoint acknowledgement prove business completion?
Cosmos DB TTL: Hidden from queries before deletion
Does an expired Cosmos DB item disappear physically as soon as queries stop returning it?
Expired items stop appearing in query responses immediately, while background deletion can wait for resources. TTL is measured from the last modification, and item-level values depend on container TTL being enabled. Query absence is therefore not proof of completed physical deletion or deletion from other stores.
Claim to check: No query result proves immediate complete data erasure.
Buyer evidence still required
Container and item TTL configuration.
Last-modified time and deletion evidence.
Throughput mode and separately retained data.
Suggested review condition: Keep query invisibility separate from completed deletion and wider retention claims.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Container TTL, item override, last modification, throughput mode and retained copies.
Optional saved evidence: Retain the exact lifecycle boundary behind a data-retention procurement decision.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Does Cosmos TTL start at creation or last modification?
Can an item override the container value?
Does item TTL work when container TTL is disabled?
Can expired data remain pending background deletion?
Why might deletion wait for request units?
Are serverless deletion charges different?
Does a query returning no rows prove physical removal?
Can an update extend the expiry point?
Which items are exempted from expiry?
Are mirrored or backup copies separately considered?
Key Vault recovery: Soft delete and purge protection
Does recovering a Key Vault restore every surrounding integration?
Soft deletion retains recoverable vault objects for a configured interval, and purge protection prevents early permanent removal during that interval. Recovering the vault does not automatically restore associated Azure RBAC assignments or Event Grid subscriptions. Recovery of secret material and recovery of the surrounding service are separate checks.
Claim to check: Soft-delete recovery restores the entire integrated service automatically.
Buyer evidence still required
Vault retention and purge-protection settings.
Recovered objects and required permissions.
RBAC and event-subscription restoration evidence.
Suggested review condition: Require integration verification before declaring the recovered service operational.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Vault identity, retention, purge protection, RBAC assignments and dependent event subscriptions.
Optional saved evidence: Save a recovery checklist grounded in the documented limits of vault restoration.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Is soft delete the same as purge protection?
Can purge protection be disabled after enabling it?
Which retention interval applies?
Can the vault name be reused during retention?
Does recovering a vault restore role assignments?
Are Event Grid subscriptions restored automatically?
Who can recover or purge objects?
Does recovered material prove applications can read it?
Which dependencies need reconfiguration?
Is object recovery separate from service recovery?
What evidence should procurement require after a restore?
Actions concurrency: Serialisation and cancelled work
Does a concurrency group guarantee every queued workflow will run?
The default single-pending behaviour replaces an earlier pending run when a new one arrives. The documented larger queue mode has a bound and cannot be combined with cancelling in-progress work. Serialisation is not a guarantee that every dispatch executes or that external side effects are rolled back when a run is cancelled.
Claim to check: A concurrency group preserves and completes all requested work.
Buyer evidence still required
Workflow group expression and queue mode.
Cancellation settings and observed run outcomes.
Recovery of effects from interrupted jobs.
Suggested review condition: Check cancellation and queue semantics before interpreting a missing run as completed work.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Workflow and job groups, queue mode, cancellation expressions and external side effects.
Optional saved evidence: Retain the actual queue policy used to assess a deployment or automation service.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Can a new Actions run cancel an older pending run?
Is queue mode single or max?
Can max queue combine with cancel-in-progress?
Are group names case sensitive?
Can unrelated workflows share a group accidentally?
Does serialisation preserve dispatch order exactly?
What happens when the larger queue is full?
Does cancelling a run undo external changes?
Which run outcomes count as completed?
Can an agent assume pending work will eventually run?
What evidence supports an automation-completion claim?
GitHub webhooks: Failed deliveries need recovery ownership
Does GitHub automatically retry every failed webhook delivery?
GitHub documents that failed webhook deliveries are not automatically redelivered. Manual redelivery or a separately implemented scheduled recovery process is required. Failure records and available delivery APIs depend on webhook type. A configured webhook alone does not establish an automatic recovery service.
Suggested review condition: Require evidence of a working recovery process before claiming automatic redelivery.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Webhook type, delivery records, recovery scheduler and receiver idempotency.
Optional saved evidence: Preserve the evidence basis for an integration recovery commitment.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Does GitHub retry failed webhooks automatically?
Who owns redelivery after an outage?
Can a slow receiver cause delivery failure?
Which delivery API covers this webhook type?
Are Marketplace and Sponsors delivery APIs available?
Is a scheduled recovery job configured?
Does the job check failure status?
Can replay repeat a previously committed operation?
Which delivery identifier is retained?
Does endpoint recovery replay older failures by itself?
GitLab protected tags: Matching rules and deletion authority
Does a protected GitLab tag mean nobody can create or delete a matching release tag?
Protected tags restrict creation to authorized roles or users; matching wildcard rules require joint review rather than assuming one restrictive pattern wins. Authorized maintainers can delete protected tags through GitLab's UI or API. Protection is an access-control setting, not evidence that a release reference is immutable.
Claim to check: Protected release tags are unchangeable by every project user.
Buyer evidence still required
All matching protected-tag rules.
Allowed creators and project roles.
Tag deletion history and release identity binding.
Suggested review condition: Do not treat tag protection as an immutable release seal.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Project roles, matching tag patterns, allowed creators and release commit identity.
Optional saved evidence: Retain access-rule evidence without overstating release immutability.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Who can create a protected GitLab tag?
Can a wildcard grant broader access?
Which matching rules apply to this name?
Does a restrictive pattern always override another rule?
NetworkPolicy: Declared rules and effective enforcement
Does a Kubernetes NetworkPolicy object prove an agent pod cannot reach the internet?
NetworkPolicy needs a supporting network implementation. Pods are not isolated for egress by default, and applicable policy allowances combine rather than overriding each other by order. A saved policy object is therefore insufficient: selection, direction, implementation support and the combined allowed traffic must be checked.
Claim to check: A NetworkPolicy object alone establishes enforced outbound isolation.
Buyer evidence still required
Network implementation and supported policy features.
Pod labels, namespace and all applicable egress policies.
Observed permitted and denied paths in the intended environment.
Suggested review condition: Require effective enforcement evidence before claiming the agent is network-isolated.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Cluster network implementation, pod selection, direction, policies and tested traffic paths.
Optional saved evidence: Save the source-backed evidence requirements for an agent isolation procurement check.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Does the cluster plugin enforce NetworkPolicy?
Are pods egress-isolated by default?
Does this policy select the agent pod?
Is Egress present in the policy types?
Do multiple policies combine their allowed traffic?
Can rule order establish a deny override?
Does ingress isolation also restrict outbound traffic?
Are host-network pods handled differently?
Which protocols does the implementation enforce?
Does API acceptance prove a policy has taken effect?
Does a Kubernetes CronJob guarantee exactly one run for each scheduled time?
CronJob scheduling can create duplicate jobs or miss a run in some circumstances; jobs should be designed for idempotent work. Its concurrency policy applies only to jobs from the same CronJob. It does not coordinate another CronJob or prove that a scheduled business operation completed.
Claim to check: A CronJob schedule guarantees one completed operation per interval.
Buyer evidence still required
Schedule, timezone, deadline and suspension settings.
Concurrency policy and other job producers.
Job outcomes and business-operation reconciliation.
Suggested review condition: Check actual jobs and business results instead of inferring completion from the schedule.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. CronJob identity, schedule, timezone, deadlines, concurrency and downstream result identity.
Optional saved evidence: Preserve the distinction between schedule configuration and verified task completion.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Can a CronJob create more than one job for a schedule?
Can a scheduled run be missed?
Does Forbid coordinate different CronJobs?
What happens to an overlapping run?
Is the schedule suspended?
Which starting deadline is configured?
Does job creation prove task completion?
How are repeated effects prevented?
Can restoring a schedule trigger missed work?
Which timezone defines the intended interval?
What evidence shows the scheduled operation succeeded?
Does each Semantic Layer service token use an independent warehouse identity?
Service tokens map to configured Semantic Layer credentials. Multiple tokens can share a credential, and available credential mappings depend on the plan. Queries follow the linked warehouse credential's data policies. Different token names alone do not establish separate warehouse access or user-specific row restrictions.
Claim to check: Different service tokens necessarily provide separate warehouse identities.
Buyer evidence still required
Token-to-credential mapping for the project.
Warehouse grants and data policies for that credential.
Plan entitlement and downstream client use.
Suggested review condition: Require the actual mapping before asserting separate data access for different clients.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Project, environment, plan, token mapping and underlying warehouse grants.
Optional saved evidence: Retain the credential-mapping evidence behind an analytical data-access decision.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Can multiple dbt service tokens share one credential?
Which warehouse identity executes a metric query?
Does a token name prove separate grants?
Can a token map to multiple credentials in one project?
Which plan supports multiple credentials?
Are underlying warehouse policies applied?
What happens when a linked credential is deleted?
Does a read-only recommendation prove effective grants?
Delta VACUUM: File retention, history and cached data
Does keeping Delta history guarantee old table versions remain queryable after VACUUM?
VACUUM removes eligible unreferenced data files, which can remove the files needed by older table versions. Log retention is a separate process. Metadata-only deletes and cached copies have additional considerations. Retained history entries alone are not proof of recoverable data or complete removal from every execution environment.
Claim to check: Retained transaction history guarantees recovery after data-file cleanup.
Buyer evidence still required
Data-file and log retention settings.
VACUUM history and required recovery versions.
Deletion-vector, clone and cache scope where applicable.
Suggested review condition: Require necessary data files and applicable cache evidence before claiming recovery or erasure.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Table type, runtime, data-file retention, log retention, cleanup history and caches.
Optional saved evidence: Save a bounded recovery and retention review before depending on historical data.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Can VACUUM remove files needed for time travel?
Is transaction-log retention governed by VACUUM?
Does a retained history row prove data remains recoverable?
What retention window applies to data files?
Are metadata-only deletes physically rewritten?
Can cached Parquet data remain queryable?
Are shallow clones subject to different rules?
Can predictive optimization run cleanup?
Which recovery version does the buyer require?
Is cleanup completion a universal erasure certificate?
What evidence should be retained before maintenance?
Can I save the reviewed history-versus-files boundary?
Slack rotation: Expiring access and refresh continuity
Does enabling Slack token rotation provide uninterrupted access without further state handling?
Rotation introduces expiring access tokens and replacement refresh tokens. The new refresh token must be retained after exchange; repeatedly using the original token breaks subsequent refreshes. Slack also limits simultaneously active refreshed tokens. Rotation requires a tested credential-lifecycle implementation, not merely an enabled setting.
Claim to check: Token rotation can be enabled without changing refresh-state handling.
Buyer evidence still required
Supported token type and rotation configuration.
Secure atomic storage of replacement credentials.
Refresh, expiry and recovery test evidence.
Suggested review condition: Require working replacement-token handling before treating rotation as operationally complete.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. App installation, token type, refresh storage, concurrent consumers and recovery behaviour.
Optional saved evidence: Retain the evidence required to assess an integration's credential continuity.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Does a rotated Slack access token expire?
Must the replacement refresh token be saved?
Can the original refresh token be reused indefinitely?
What happens if credentials expire before refresh?
Can repeated early refreshes revoke older tokens?
Is token exchange the same as reinstalling the app?
Can revoking the original token disrupt installation?
Which installation does the token represent?
Do concurrent workers share refresh state safely?
Were expiry and recovery paths tested?
Does enabling rotation prove continued service access?
Can I preserve the reviewed credential-lifecycle boundary?
Notion webhooks: Event metadata and retrieved content
Does a Notion webhook contain the full page content as it existed when the event occurred?
The documented flow sends event metadata and then retrieves updated content through the Notion API. That retrieval is a separate operation, not proof of an event-time content snapshot. Signature checking authenticates the received bytes; it does not establish the completeness or historical identity of subsequently fetched page content.
Claim to check: A verified webhook is a complete immutable page-content snapshot.
Buyer evidence still required
Subscribed event and exact received payload.
Signature verification over original bytes.
API retrieval time, permissions and saved content version.
Suggested review condition: Date and identify the retrieved content separately from the notification event.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Connection, subscription, event payload, signature verification and follow-up content retrieval.
Optional saved evidence: Preserve the boundary between authenticated notification and a separately captured document version.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Does a Notion webhook include full page content?
Which API call retrieves the updated data?
Is retrieval time the same as event time?
Can content change before the follow-up fetch?
What does the webhook signature prove?
Does reserializing JSON preserve signed bytes?
Which connection permissions govern the fetch?
Can an inactive subscription stop notifications?
Can the webhook URL change after verification?
Does a valid signature prove a complete historical snapshot?
Which timestamps should an evidence workflow retain?
CloudWatch masking: Old events and privileged reads
Does enabling CloudWatch masking hide sensitive content in every stored log?
Data protection detects and masks matching data as it is ingested. Earlier log events are not masked by a newly applied policy, and principals with logs:Unmask can view unmasked content. This is a presentation and access-control boundary, not evidence that the original content was erased.
Claim to check: A new masking policy removes sensitive content from all stored logs.
Buyer evidence still required
Policy activation time and managed identifiers.
Log ingestion dates and policy coverage.
Principals with unmask authority and retained copies.
Suggested review condition: Check historical events and privileged reads before accepting an all-logs redaction claim.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Log group, ingestion dates, data identifiers and unmask permissions.
Optional saved evidence: Preserve the difference between masked viewing, historical coverage and removal.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Are earlier CloudWatch logs masked retroactively?
When was the data protection policy applied?
Which sensitive identifiers are selected?
Can authorized users unmask values?
Does masking delete the original content?
Are account and log-group policies both active?
Do both policies contribute identifiers?
Which log streams predate the policy?
Does a clean view prove every value was detected?
Who can retrieve unmasked content?
What evidence supports a historical-redaction claim?
Does Datadog sensitive-data scanning prove raw content never leaves our environment?
Cloud scanning receives data in the Datadog backend before redaction. Scanning within the customer environment is a different deployment choice. The supported fields differ across logs, APM, RUM and events, and optional sampling reduces the scanned fraction. A masked interface alone does not establish pre-egress redaction or complete coverage.
Claim to check: A redacted Datadog view proves all sensitive data was removed before transmission.
Buyer evidence still required
Scanner location and data-flow diagram.
Product-specific fields, rules and sampling.
Evidence from the source-side pipeline.
Suggested review condition: Require source-side evidence before describing redaction as pre-egress.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Scanner placement, product, selected fields, rules and sampling.
Optional saved evidence: Save the evidence questions for a supplier data-disclosure review.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Does cloud scanning happen before data leaves us?
Can scanning run within our environment?
Which fields are scanned for APM?
Are RUM bodies and attributes treated alike?
Is sampling enabled?
Does every event pass the same rule set?
Is a redacted UI evidence of source-side filtering?
Snowflake masking: Query context and retained data
Does Snowflake Dynamic Data Masking replace the underlying sensitive values?
Dynamic Data Masking applies policy at query time. Depending on conditions, execution context and role hierarchy, a query can receive raw, partial or fully masked values. The feature requires Enterprise Edition or higher. Its presence does not establish erasure of source values or the effective output for every identity.
Claim to check: A masking policy removes raw values and masks every user identically.
Buyer evidence still required
Edition and column-policy attachment.
Policy logic and effective role hierarchy.
Representative query results for intended identities.
Suggested review condition: Inspect the actual query identity and policy before accepting a universal masking claim.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Edition, columns, masking logic, execution context and role hierarchy.
Optional saved evidence: Retain the documented masking basis for an analytical-access decision.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Does Snowflake masking alter stored source values?
Does replacing raw-data access with Masked Reader immediately hide earlier query results?
BigQuery documents a query-cache caveat when a user queries raw data, then loses Fine-Grained Reader and gains Masked Reader within the cache period. An identical query can still return cached raw data. Masking rules and base table permissions also matter; a role-change screenshot does not establish every result is masked.
Claim to check: Revoking raw-column access immediately masks every repeated query result.
Buyer evidence still required
Prior raw query and role-change timing.
Cache usage and query configuration.
Policy bindings and effective table permissions.
Suggested review condition: Require a cache-aware check before asserting that a role change removed raw-result access.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Data policy, role transition, query identity, timing and cache usage.
Optional saved evidence: Preserve the precise access-transition caveat used in a data-sharing review.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Can a cached BigQuery result retain raw column values?
Was raw access used before the role change?
Does the repeated query use cache?
When was Fine-Grained Reader revoked?
When was Masked Reader granted?
Are base table permissions still present?
Which data policy applies to the column?
Does a broad Masked Reader grant cover other policies?
Does a CODEOWNERS file prove the right owner must approve every change?
Code-owner review must be required through the applicable branch controls. Invalid lines are skipped, later matching patterns take precedence, and owners need suitable repository access. A file in the repository therefore does not prove complete matching or enforced review of the target branch.
Claim to check: The presence of CODEOWNERS guarantees all changes receive mandatory owner approval.
Buyer evidence still required
Target-branch CODEOWNERS version and syntax errors.
Matched file patterns and owner access.
Applicable required-review configuration.
Suggested review condition: Confirm matching and enforcement separately before asserting owner approval coverage.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Target branch, ownership file, matched paths, team access and review settings.
Optional saved evidence: Save the versioned ownership and enforcement questions for release procurement.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Does a green pull-request check prove the queued merge combination passed?
A merge queue creates a temporary combined change with a different SHA. GitHub Actions must handle merge_group for required checks; third-party CI must handle the queue branch. A pull-request result is not automatically evidence for that combined state, and missing required reports can prevent the merge.
Claim to check: An approved pull-request check automatically validates the queued merge SHA.
Buyer evidence still required
Pull-request and merge-group SHAs.
Required-check trigger configuration.
Check reports for the temporary merge group.
Suggested review condition: Bind acceptance evidence to the merge-group identity rather than reusing an unrelated green check.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Queue configuration, CI provider, triggers, required checks and merge-group identity.
Optional saved evidence: Preserve the source-bound distinction between isolated and combined release validation.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Which SHA did the successful check test?
Does the workflow handle merge_group?
Is that distinct from pull_request?
Does third-party CI recognize queue branches?
Can another queued change affect the combined state?
Are required checks reported for the group?
Why can a green pull request still leave the queue?
Is the target branch included in testing?
Which temporary branch identifies the group?
Does the provider report the correct status context?
GitLab approvals: Independent people and revisions
Does a GitLab approval count prove independent review of the latest revision?
Approval settings separately govern authors, committers, rule overrides and reset behaviour after changes. Committers can approve by default unless restricted. Changed diffs normally reset approvals, but that behaviour can be changed. Counts alone do not identify reviewer independence or the revision accepted.
Claim to check: Two recorded approvals prove independent acceptance of the current code.
Buyer evidence still required
Author and committer identities.
Approval-rule override and reset settings.
Approved revision and later diff changes.
Suggested review condition: Bind approvers and approvals to the accepted revision before claiming independent review.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Project tier, approval settings, identities and revision history.
Optional saved evidence: Retain the documented evidence required to substantiate a supplier review claim.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Can a committer approve this merge request?
Is approval by the author prevented?
Can request-level rules override project rules?
Are approvals reset after changed diffs?
Was the approval recorded before commit processing finished?
Does a rebase change approver eligibility?
Which patch identity was approved?
Were later changes added?
Is re-authentication required?
Does an approval count show distinct independent people?
GitLab deployment: Approval and execution are distinct
Does an approved GitLab deployment mean the deployment job has run?
Protected-environment approvals allow a deployment to proceed, but the job must then be run manually. Pipeline-triggerer self-approval is separately configurable, and administrators can approve or reject deployments. Approval state is not execution success or proof of the resulting environment.
Claim to check: Approved deployment status proves successful release to the environment.
Buyer evidence still required
Environment approval rules and approver identities.
Job execution and completion status.
Resulting deployment identity and environment evidence.
Suggested review condition: Keep authorization, execution and environment verification as separate evidence.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Protected environment, approval rules, identities and job outcome.
Optional saved evidence: Save a release-review record that does not confuse approval with delivery.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Does disabling a KMS key immediately stop every read of the protected data?
Disabled customer-managed keys cannot perform KMS cryptographic operations, subject to eventual consistency. Resources already using data keys are not affected until they need KMS again, for example to decrypt a data key. Disabling the parent key is not evidence that every application has discarded plaintext or cached key material.
Claim to check: Disabling the KMS key immediately revokes all access to every protected resource.
Buyer evidence still required
Key state and change time.
Service use of data keys and caching.
Observed application access and retained plaintext scope.
Suggested review condition: Check the consuming service and cached material before claiming immediate universal revocation.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Key type, service, data-key caching, transition time and retained copies.
Optional saved evidence: Preserve the distinction between a KMS state change and effective application access.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Secret rotation: Stored value and external service
Does enabling rotation for a non-database secret prove the external credential changed?
Lambda-based rotation must update credentials in both Secrets Manager and the target service. The generic function needs service-specific code, permissions and network access. A configured schedule or newly stored value alone does not establish a successful external change or that applications use the replacement.
Claim to check: A rotation schedule proves the external credential and all consumers are current.
Buyer evidence still required
Service-specific rotation implementation and execution outcome.
Target-service credential evidence.
Consumer retrieval and authentication evidence.
Suggested review condition: Require evidence of the target update and consumer use before treating rotation as completed.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Secret type, Lambda code, permissions, connectivity, target state and consumers.
Optional saved evidence: Save the evidence checklist for a supplier credential-rotation assurance claim.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Does the generic rotation function contain target-specific logic?
Was the external service updated?
Did the rotation function complete?
Does it have network access to the target?
Which execution permissions are required?
Is the pending value usable?
Did the application retrieve the replacement?
Is a schedule equivalent to a successful rotation?
Are database and other secrets configured alike?
What evidence ties the two credential states together?
Does denying GetParameter prevent an agent from reading the current parameter value?
Parameter Store authorizes retrieval operations separately. GetParameterHistory can expose the current version as well as earlier values, including SecureString values when decryption is permitted. A denial of other retrieval actions is not evidence that the history path is closed. Parameter and KMS permissions require joint review.
Claim to check: Denying the ordinary read API closes every route to a current parameter value.
Buyer evidence still required
Effective permissions for each retrieval operation.
Version-history access.
Applicable KMS decryption grants.
Suggested review condition: Inspect history and decryption authority before approving metadata-only access.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Parameter identities, retrieval actions, history permissions and KMS grants.
Optional saved evidence: Preserve the access-path distinction behind a least-privilege review.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Can GetParameterHistory return the current version?
Is history access only metadata?
Are SecureString values included when decryption is allowed?
Are retrieval permissions evaluated separately?
Does denying GetParameter deny history too?
Which KMS grants apply?
Can earlier credentials remain in history?
Does an inventory role include value-reading actions?
IAM validation: Policy checks and effective authority
Does a clean IAM policy-validation result prove the deployed role has only intended access?
Policy validation checks grammar and AWS best-practice findings. It does not itself execute the buyer workflow or establish the combined effect of every deployed grant. A separate custom check can compare new access with a baseline; AWS still calls for testing new or edited policies before production use.
Claim to check: A policy with no validation findings is a completed effective-access assessment.
Buyer evidence still required
Exact validated policy and check type.
All deployed permission sources and intended tasks.
Positive and negative operational access evidence.
Suggested review condition: Keep static validation separate from effective-authority and workflow testing.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Policy version, validator mode, baseline, deployed grants and intended operations.
Optional saved evidence: Save an evidence-bound interpretation of policy-check output.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Did the check validate grammar or compare access?
Which policy version was checked?
Are all deployed grants included?
Does no warning prove least privilege?
Was a custom baseline comparison run?
Can a syntactically valid policy grant unwanted access?
Were allowed tasks tested?
Were denied tasks tested?
Are resource policies part of the review?
Does a check outcome establish production state?
What validation evidence should procurement retain?
Does a Teleport login also authorize the upstream MCP service?
Some upstream servers need a separate OAuth token. Teleport still applies its own roles and tool permissions, while the upstream token satisfies that service. The documented login stores credentials locally and contacts the authorization server from the workstation. Changing the upstream URI requires a new login.
Claim to check: One proxy login establishes all upstream permissions and contains every authentication flow.
Buyer evidence still required
Teleport roles and allowed tools.
Upstream OAuth issuer, scopes and server URI.
Client version and local credential handling.
Suggested review condition: Confirm both authority layers and authorization-server access before connecting.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Teleport version, roles, upstream URI, OAuth issuer, scopes and client credentials.
Optional saved evidence: Retain the two-layer identity boundary for a managed connector review.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Is upstream OAuth separate from Teleport login?
Which layer restricts MCP tools?
Where are upstream tokens stored?
Does the authorization request leave from the workstation?
Which scopes did the upstream server request?
What happens after the server URI changes?
Does tsh refresh expired access tokens?
Can a custom Authorization header replace stored credentials?
Admission webhooks: Failure policy and explicit denial
Does an unavailable admission webhook always stop a Kubernetes change?
Failure policy controls webhook errors: Ignore permits the API request to continue, while Fail rejects it. This differs from a valid webhook response that explicitly denies the request, which is rejected regardless of failure policy. Matching rules and selectors also determine whether the webhook is called.
Claim to check: Installing an admission webhook proves every matching change is blocked when checks fail.
Buyer evidence still required
Matching rules, selectors and failure policy.
Timeout and error behaviour.
Admission outcome for the requested resource and operation.
Suggested review condition: Distinguish a missing check, a call failure and an explicit denial before claiming enforcement.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Webhook rules, selectors, failure policy, availability and request outcome.
Optional saved evidence: Preserve a precise enforcement review for cluster admission controls.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Does Ignore allow requests after a webhook timeout?
Does enabling Kubernetes auditing prove every request body is retained?
The first matching audit rule selects the level. None omits events; Metadata excludes bodies; Request and RequestResponse include different content. Policy and stage exclusions govern coverage, and omitting the API-server audit-policy flag means no policy-based events are logged. Export and retention are separate evidence.
Claim to check: An audit feature being enabled guarantees complete request and response evidence.
Buyer evidence still required
Effective ordered audit policy and omitted stages.
Backend configuration and delivery health.
Retained event samples for intended operations.
Suggested review condition: Confirm event and content coverage before relying on an audit export as complete.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. API-server configuration, ordered policy, event stages, backend and retained samples.
Optional saved evidence: Save the distinction between audit availability and usable evidential coverage.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Does an assigned Azure policy prove non-compliant changes are blocked?
DoNotEnforce evaluates compliance without enforcing the policy effect. Disabled effect is different because it avoids evaluation. Assignment exclusions and scoped overrides also matter. Remediation tasks for deployIfNotExists can still be started in DoNotEnforce mode; that mode is not a blanket no-change guarantee.
Claim to check: A policy assignment proves blocking, or DoNotEnforce prevents every change.
Buyer evidence still required
Assignment mode, definition and effect.
Scope exclusions and overrides.
Remediation tasks and actual enforcement evidence.
Suggested review condition: Check evaluation, enforcement and remediation separately before describing the control.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Assignment mode, definition version, scope, overrides and remediation.
Optional saved evidence: Preserve the evidence boundary between a compliance report and enforced prevention.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Is the assignment in DoNotEnforce mode?
Does it still evaluate compliance?
Is Disabled a different effect?
Can a remediation task still run?
Which child scopes are excluded?
Do overrides change the effect?
Is the definition version fixed?
Does a compliance result prove a change was blocked?
Does a new Google organization policy automatically correct existing violations?
Organization policies are usually not retroactive unless the specific constraint says otherwise. A service already in a newly prohibited state can continue its earlier behaviour and require separate correction. Constraint-specific applicability and dry-run evidence matter; assignment alone does not establish that old resources were remediated.
Claim to check: New organization policy immediately makes every existing resource conform.
Buyer evidence still required
Exact constraint and retroactivity documentation.
Existing-resource inventory and effective policy.
Remediation outcomes and dry-run results.
Suggested review condition: Require evidence for existing resources rather than inferring correction from assignment.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Constraint, inherited policy, existing resource state and remediation evidence.
Optional saved evidence: Save the source-bound applicability review for organization-wide control claims.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Is this constraint retroactive?
Can an existing prohibited state continue?
Which resources predate the policy?
Does the constraint document exceptions?
Was a dry run reviewed?
Which descendants inherit the policy?
Does assignment itself remediate resources?
Who owns correction of old violations?
What proves the current resource state?
Does a future creation block prove historical compliance?
Does AWS Config daily recording preserve every resource configuration change?
Daily recording captures the most recent state over the preceding day when it differs from the previous recorded configuration. Continuous recording and resource-type selection are separate settings. A daily record is not a complete transition history, and unsupported or unselected types remain outside the asserted coverage.
Claim to check: A daily Config record proves every intermediate configuration state was captured.
Buyer evidence still required
Recorder resource-type selection and frequency.
Region and global-resource coverage.
Configuration items and independent event evidence.
Suggested review condition: Do not infer a complete change history from daily state snapshots.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Resource type, region, selection, recorder health and recording frequency.
Optional saved evidence: Preserve the difference between periodic inventory and a complete change trail.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Does daily recording capture intermediate changes?
S3 public-access blocks: Retained grants and scope
Does enabling S3 Block Public Access remove the old public grants?
The settings can reject new public grants or ignore their effects without rewriting existing ACLs and policies. Their behaviours differ, and the most restrictive applicable combination governs access. A blocking setting is not evidence that underlying grants were cleaned up or that every non-public access path is appropriate.
Claim to check: A public-access block deletes the underlying public grants and proves least privilege.
Buyer evidence still required
All applicable block settings and policy levels.
Retained bucket policies and ACLs.
Authorized access paths and change history.
Suggested review condition: Inspect retained grants and effective settings before relying on later removal of a block.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Organization, account, bucket and access-point settings, ACLs and policies.
Optional saved evidence: Save the difference between disabling a grant effect and removing the grant.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Are existing public ACLs deleted by the setting?
Does IgnorePublicAcls prevent new ACLs from being stored?
Does BlockPublicAcls reject new public grants?
Do bucket and account settings combine?
Can organization settings be stricter?
What happens if a blocking setting is removed?
Are retained bucket policies still present?
Does public-access blocking prove least privilege?
Restore testing: Completion and workload validation
Does a completed AWS Backup restore test prove the application works?
Restore-test completion can trigger a separate, optional validation workflow. The buyer defines checks such as a health endpoint and reports their result. A COMPLETED restore job and a successful workload validation are distinct evidence; the sample validation code is not itself proof that useful checks were implemented.
Claim to check: Restore completion automatically establishes usable application recovery.
Buyer evidence still required
Restore-job identity and completion event.
Actual validation logic and execution logs.
Reported validation status and workload scope.
Suggested review condition: Require executed validation of the needed behaviour before asserting application recovery.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Restore job, validation workflow, resource identity and tested workload behaviour.
Optional saved evidence: Save the evidence requirements behind a supplier recovery claim.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Was a validation workflow configured?
Does it run after the completed restore event?
Which restored resource was tested?
Is the sample TODO replaced with actual checks?
What application behaviour was validated?
Were validation logs retained?
Was the result posted for the correct job?
Can a validation status be changed after setting it?
Does a health check cover all dependencies?
Was the test result merely assumed?
What distinguishes restore and validation evidence?
Does deleting an RDS instance also remove every recoverable database copy?
Deletion offers separate choices for a final snapshot and retained automated backups. Earlier manual snapshots and a created final snapshot remain. Retained automated backups follow the retention period effective at deletion. Instance absence alone therefore does not establish removal of all recovery copies.
Claim to check: Deleting the database instance proves all recoverable copies were erased.
Buyer evidence still required
Deletion options and effective backup retention.
Manual and final snapshot inventory.
Cross-region or separately copied backup scope.
Suggested review condition: Reconcile retained copies before claiming complete deletion or guaranteed recovery.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Instance, deletion options, snapshot inventory and retained backup period.
Optional saved evidence: Preserve the source-linked copy-retention boundary for a supplier exit decision.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Was a final snapshot requested?
Do earlier manual snapshots remain?
Were automated backups retained?
Which retention period applied at deletion?
Does a final snapshot replace other backups?
Can the deleted instance be restored from an earlier point?
Is the instance state eligible for a final snapshot?
Are separately copied backups included in the review?
Does instance absence prove erasure?
Which snapshot identity will be used for recovery?
What evidence confirms deletion of retained copies?
Does a Vault retention arrangement survive deletion of the user or required licence?
Vault requires appropriate licences for users and administrators. The overview warns that deleting a user or required licence can irreversibly purge data and remove Vault availability. Retention rules act on supported service data; an export or retained matter should not be assumed to cover an unverified offboarding change.
Claim to check: A retention arrangement guarantees data remains available after any offboarding action.
Buyer evidence still required
User status and applicable Vault licences.
Retention or hold scope and supported services.
Preservation evidence before the proposed lifecycle change.
Suggested review condition: Confirm the documented user and licence lifecycle before relying on retained evidence.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Account lifecycle, licences, supported services and preservation scope.
Optional saved evidence: Save the documented preservation questions before a supplier account-exit decision.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Does deleting a user affect Vault data?
Can removing a required licence cause purging?
Which users have Vault licences?
Which administrators can use Vault?
What service data is covered?
Are retention rules applied to the intended accounts?
Does an export prove all future data is preserved?
Is the proposed action suspension or deletion?
Who owns preservation during offboarding?
What evidence confirms the account is still covered?
Purview retention: Conflicts and permanent deletion
Does a short deletion policy prove Microsoft 365 content will be permanently removed on that date?
Ordinary retention conflict rules favour retention over deletion and the longest retention period. Deletion labels and policies have further precedence rules. Priority cleanup is a documented exceptional path. A short deletion setting alone does not determine the effective outcome for an item subject to other retention or hold conditions.
Claim to check: The shortest configured deletion period establishes the effective removal date.
Buyer evidence still required
All applicable policies, labels and holds.
Item-level scope and effective precedence.
Any exceptional cleanup action and observed disposition.
Suggested review condition: Reconcile all applicable retention conditions before claiming a permanent-deletion date.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Workload, item, retention policies, labels, holds and exceptional cleanup.
Optional saved evidence: Save the source-based precedence analysis without making a legal erasure conclusion.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Can retention override a deletion policy?
Does the longest retention period win?
Can content disappear from a user view while still retained?
Do labels and policies have different precedence?
Which policies apply to this item?
Is a hold also relevant?
Is priority cleanup being used?
Does a container policy cover every workload alike?
What determines the effective deletion action?
Is a configured date evidence of actual disposition?
Does an ILM minimum age mean each log is deleted that long after its event timestamp?
After rollover, ILM phase minimum ages use the previous index rollover time rather than its creation time. The policy acts on indices, while individual events can have different timestamps. A phase-age setting alone is not evidence of exact per-event deletion timing.
Claim to check: An index lifecycle minimum age guarantees a matching event-age retention period.
Buyer evidence still required
Rollover timestamp and lifecycle policy.
Index membership and event timestamps.
Phase progress and deletion evidence.
Suggested review condition: Check the lifecycle reference time and index contents before asserting per-event retention.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Index lifecycle policy, rollover time, event membership and phase state.
Optional saved evidence: Preserve the distinction between index lifecycle settings and event-level retention claims.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Does any valid Cosign signature establish the supplier artifact we intended to accept?
Identity-based verification checks the expected certificate identity and OIDC issuer. Container verification normally checks the signed image digest; disabling claim checks changes what is established. A cryptographically valid signature without the intended identity and artifact binding is insufficient for the buyer acceptance decision.
Claim to check: Any valid signature is enough to accept an artifact as the intended supplier release.
Buyer evidence still required
Expected signer identity and issuer.
Artifact digest and signed payload.
Verification flags and policy result.
Suggested review condition: Require the intended signer and artifact binding; do not treat signature validity as a safety assessment.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Artifact identity, expected signer, issuer, bundle and verification options.
Optional saved evidence: Save the acceptance criteria and source version behind an artifact-origin review.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Which signer identity is expected?
Which OIDC issuer is trusted?
Does the signature bind the requested image digest?
Were claim checks disabled?
Does a valid key prove the intended supplier identity?
SLSA provenance: Trusted builder and expected inputs
Does possessing SLSA provenance prove the package came from the expected build?
The reviewed SLSA v1.2 guidance requires verification against expectations: trusted builder identity, provenance signature, build type and external parameters. Unrecognized external parameters should fail verification. Merely retaining a provenance document does not perform those checks or establish the buyer-specific expected build.
Claim to check: A provenance attachment alone proves the expected supplier build was used.
Buyer evidence still required
Trusted builder mapping and expected source/build criteria.
Signed provenance and artifact identity.
Parameter comparison and verifier outcome.
Suggested review condition: Form and check expectations before relying on provenance as acceptance evidence.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. SLSA v1.2 guidance, artifact, builder trust, build type and external parameters.
Does having no Dependabot alerts prove all dependencies are free of known issues?
Alerts depend on the default-branch dependency graph, supported ecosystems and advisories reviewed by GitHub. New disclosures can take time to appear, archived repositories are not scanned, and GitHub Actions SHA references are outside the documented semantic-version alert case. No alert is therefore not a complete dependency-safety verdict.
Claim to check: Zero Dependabot alerts establishes a clean result for every deployed dependency.
Buyer evidence still required
Default branch and dependency graph completeness.
Repository status and supported package references.
Advisory timing and independent deployed inventory.
Suggested review condition: Identify coverage and timing gaps before interpreting a zero-alert result.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Repository status, default branch, package references, graph and advisory timing.
Optional saved evidence: Save the documented coverage basis behind a dependency-risk procurement review.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Which branch does Dependabot scan?
Does the graph include deployed dependencies?
Are all ecosystems supported?
Are only reviewed advisories used?
Can a newly disclosed issue be absent temporarily?
npm ignore-scripts: Explicit commands still execute
Does ignore-scripts make every npm operation safe from project script execution?
In npm CLI v11, ignore-scripts suppresses package.json scripts during operations such as installation. Commands explicitly intended to run a script, including npm test and npm run, still run the requested script while omitting pre- and post-scripts. This setting is not an execution sandbox for later agent commands.
Claim to check: Once ignore-scripts is set, no npm command can run project code.
Buyer evidence still required
npm version and effective configuration.
Exact proposed command and requested script.
Project trust and execution environment.
Suggested review condition: Require separate execution authority for explicit scripts even when installation scripts are disabled.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. npm CLI version, effective setting, exact command and project script authority.
Optional saved evidence: Preserve the execution boundary used when approving a coding-agent workflow.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Does npm test still run with ignore-scripts?
Does npm run execute its requested script?
Are pre- and post-scripts skipped?
Is the flag an execution sandbox?
Which npm version is installed?
Was the setting effective during installation?
Can a later command execute project code?
What script body will be invoked?
Is the repository trusted for execution?
Does installation success establish safe script behaviour?
Snyk ignores: Scope and expiry are not remediation
Does a Snyk ignore rule establish that a vulnerability was fixed?
The ignore command changes policy treatment of an issue; it does not document a code fix. Paths and expiry determine scope. The .snyk issue-ignore mechanism is not supported for Snyk Code, which has a separate workflow. An invalid expiry can leave an ignore in place indefinitely, so inspect the effective policy.
Claim to check: An ignored issue has been remediated.
Buyer evidence still required
Exact issue, scanner and policy file.
Applicable paths, reason and parsed expiry.
Separate evidence of a fix or accepted exception.
Suggested review condition: Do not treat an ignore as remediation; require the scoped exception or fix evidence.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Scanner, issue ID, policy path, resource scope, expiry and fix evidence.
Optional saved evidence: Save the exception boundary used in a supplier vulnerability review.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
SonarQube tokens: Analysis scope and user authority
Does a SonarQube token used by a scanner have only analysis permissions?
User tokens carry the issuing user permissions, including administrative rights where applicable. Project analysis tokens restrict analysis to the associated project and depend on the author retaining Execute Analysis permission. Connected-mode clients require user tokens, so a project-token assumption cannot be applied to every integration.
Claim to check: Every scanner integration token is restricted to one project.
Buyer evidence still required
Token type and issuing identity, without the secret.
Effective permissions and associated project.
Client authentication requirements and revocation checks.
Suggested review condition: Inspect token type and effective grants before calling an integration least-privileged.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Client purpose, token type, issuing identity, project and effective grants.
Optional saved evidence: Preserve the credential-scope review without storing the credential.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Does a resolved GitGuardian incident prove the exposed credential was revoked?
Integrated revocation requires a supported provider, a valid secret and Full Access to the incident. The documented auto-resolution path also depends on a playbook. Many provider APIs do not directly confirm revocation; GitGuardian uses later validity checks. Preserve the revocation and validity evidence separately from the incident label.
Claim to check: A resolved incident is sufficient proof of credential revocation.
Buyer evidence still required
Provider support and revocation event.
Subsequent validity result with time.
Incident timeline and enabled resolution playbook.
Suggested review condition: Require provider and validity evidence before asserting the credential is no longer usable.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Provider, incident timeline, revocation event, validity timestamps and playbook configuration.
Optional saved evidence: Save the distinction between workflow closure and credential invalidation.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Is this provider supported for integrated revocation?
GitHub validity checks: Issuer contact and unknown results
Does an unknown GitHub secret-validity result mean the credential is inactive?
GitHub checks supported secrets by contacting issuer APIs and may need host or URL context. Results can be active, inactive or unknown. Coverage varies by provider. An unknown result does not establish inactivity, and enabling verification involves disclosure to the issuer rather than a wholly local check.
Claim to check: Unknown validity establishes that a detected secret cannot be used.
Buyer evidence still required
Supported secret type and enabled validity checks.
Check time, returned state and required context.
Approved issuer-contact and remediation process.
Suggested review condition: Keep unknown unresolved; do not interpret missing validation as an inactive credential.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Provider, secret type, validity setting, context and dated check result; exclude secret values.
Optional saved evidence: Retain a dated interpretation of a secret alert without exposing the secret.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Trivy offline mode: Network and database boundaries
Does Trivy --offline-scan guarantee no network access and current vulnerability data?
The air-gap guide treats remote Java identification, database availability, version checks and telemetry separately. The offline-scan flag prevents remote dependency-identification requests; it is not an all-network switch. Database acquisition and freshness need their own evidence. Version checks and telemetry have independent disabling controls.
Claim to check: One offline flag proves both isolation and up-to-date scan coverage.
Buyer evidence still required
Trivy version and all network-related settings.
Imported database version and capture date.
Network observation and dependency identification limits.
Suggested review condition: Require separate isolation and database-age evidence before accepting an offline coverage claim.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Trivy revision, command options, database identity, capture date and observed connectivity.
Optional saved evidence: Preserve the network and freshness boundary behind an offline scan.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Does an empty Semgrep findings list prove every relevant file was scanned?
File or folder exclusions prevent findings from being generated for that scope. Ignoring through triage is different: a finding exists but has an Ignored state. Default and configured ignore patterns affect coverage. A buyer needs scan scope and triage evidence, not just the visible findings count.
Claim to check: No displayed findings establishes complete clean coverage.
Buyer evidence still required
Included and excluded paths for the exact revision.
Applied ignore patterns and rule selection.
Finding states and scan completion evidence.
Suggested review condition: Separate unscanned scope from ignored findings before accepting a clean-result claim.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Revision, scan scope, ignore configuration, rules and finding states.
Optional saved evidence: Save the scan-coverage and exception basis used in procurement.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
OpenTelemetry redaction: Exceptions and attribute scope
Does configuring the OpenTelemetry redaction processor prove every sensitive attribute is masked?
The processor supports key and value policies with explicit exceptions. Ignored keys pass without redaction; allowed values are not masked. Enabling allow_all_keys disables the key allowlist but still applies blocked-value rules. Review the effective exceptions and processed attributes before treating the processor name as evidence of complete removal.
Claim to check: Installing a redaction processor establishes complete sensitive-data removal.
Buyer evidence still required
Collector revision and active processor configuration.
Allowed, ignored and blocked keys or values.
Representative output and all downstream paths.
Suggested review condition: Require evidence for exception paths and output scope before approving sensitive telemetry export.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Collector version, processor configuration, attribute scope, exceptions and downstream destinations.
Optional saved evidence: Save the specific policy exceptions behind a telemetry-disclosure decision.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Vector remap: Failed redaction and original events
Can a Vector remap error send the original sensitive event downstream?
By default, a processing error forwards the original unmodified event because drop_on_error is false. Explicit aborts have a separate drop_on_abort setting. Rerouted dropped events can also carry original data. Review normal, error and dropped outputs separately before relying on a remap transformation as a disclosure barrier.
Claim to check: A remap redaction program prevents raw data from leaving on every path.
Buyer evidence still required
Effective drop_on_error and drop_on_abort settings.
Rerouted-output destinations and access controls.
Failure-case output for representative inputs.
Suggested review condition: Do not approve a no-raw-data claim without reviewing error and reroute paths.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Vector revision, remap configuration, failure inputs and every output destination.
Optional saved evidence: Preserve the failure-path questions behind a log-processing purchase.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
What happens if the remap program errors?
Is drop_on_error explicitly set?
Does an abort use a different setting?
Can the original event be forwarded?
Where do rerouted dropped events go?
Does that output contain unredacted data?
Were failure cases tested?
Can an enrichment error bypass a required transformation?
Elasticsearch redaction: Licence and skip behaviour
Does a successful ingest pipeline prove the redact processor changed the document?
The redact processor can quietly leave a document unchanged when skip_if_unlicensed is enabled and the licence does not support it. Conditional execution and failure handling also affect what runs. The trace_redact option can mark actual redaction, but absence of that marker alone is not a complete coverage assessment.
Claim to check: Pipeline success proves sensitive text was redacted.
Buyer evidence still required
Licence eligibility and effective skip settings.
Conditional and failure-handler configuration.
Representative input/output and redaction trace where enabled.
Suggested review condition: Check actual processor execution and output before accepting pipeline success as redaction evidence.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Elasticsearch version, licence, processor settings, patterns and failure paths.
Optional saved evidence: Save the execution and licensing boundary behind a redaction claim.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Presidio: Detection coverage and residual information
Does a clean Presidio result prove a document contains no sensitive information?
Presidio combines configurable recognizers and can use external detection models. Its maintainers explicitly warn that automated detection does not find all sensitive information. The selected recognizers, languages and input types need buyer validation; a clean result cannot alone establish complete anonymization or permission to disclose the document.
Claim to check: No detected entities means a document is safe to disclose.
Buyer evidence still required
Recognizer and model configuration.
Representative language and input-type coverage.
Residual-data review and authorized disclosure scope.
Suggested review condition: Require additional protections and relevant coverage evidence before relying on complete removal.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Presidio revision, recognizers, models, languages, input types and disclosure purpose.
Optional saved evidence: Retain the detection limits used when reviewing a privacy-processing workflow.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Which recognizers were enabled?
Which model processed the text?
Was an external model used?
Does the configuration cover our language?
Were image inputs handled separately?
Can sensitive information be missed?
Does zero entities mean no personal data?
Were domain-specific identifiers considered?
Which residual checks were performed?
Who authorized disclosure of the output?
What revision and configuration produced the result?
Does Macie automated discovery prove every object in an S3 bucket was inspected?
Automated discovery evaluates bucket inventory and selects representative objects through sampling. Discovery jobs allow more targeted scope and depth. The existence of automated discovery or no findings does not establish exhaustive inspection. Keep selected objects, configured identifiers and analysis results distinct from the total bucket inventory.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Discovery mode, object inventory, selection criteria, identifiers and dated analysis results.
Optional saved evidence: Save the distinction between sampled discovery and an exhaustive-inspection claim.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Pseudonymization: Reversible tokens and key authority
Does tokenizing data with Sensitive Data Protection permanently erase the original meaning?
AES-SIV and format-preserving encryption support re-identification with the required key and context. HMAC-SHA-256 is a separate one-way option. Deterministic transformations can preserve links between records. Review the selected method and who can re-identify or correlate values; tokenization alone is not proof of erasure.
Claim to check: All pseudonymization is irreversible deletion.
Buyer evidence still required
Exact transformation and context configuration.
Key custody and re-identification permissions.
Cross-record linkage and retained original copies.
Suggested review condition: Do not describe reversible tokenization as erasure or assume transformed records cannot be linked.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Transformation, structured or unstructured input, key custody, context and recipient authority.
Optional saved evidence: Preserve the reversibility and linkage facts used in a data-sharing review.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Which pseudonymization method was used?
Can AES-SIV tokens be re-identified?
Is this HMAC hashing instead?
Who controls the cryptographic key?
What context is needed to reverse tokens?
Are surrogate annotations required for this input?
Purview DLP: Simulated matches and enforced controls
Does a Purview DLP simulation alert prove the attempted transfer was blocked?
Simulation runs policies without actual enforcement and reports matched items and alerts separately. It helps evaluate policy impact but does not prove that a transfer was prevented. Procurement should distinguish simulation evidence from the active policy state and observed enforcement in the intended workload.
Claim to check: A simulated DLP match establishes successful prevention.
Buyer evidence still required
Policy mode and relevant workload scope.
Separate simulation and enforced-policy results.
Dated evidence of actual blocking when claimed.
Suggested review condition: Keep simulated matches labelled as simulation; request enforcement evidence for a blocking claim.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Policy version, mode, workload, dates and observed enforcement events.
Optional saved evidence: Save the distinction between policy evaluation and operational prevention.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Snowflake tags: Applicable types and policy precedence
Does assigning a masking tag prove its policy governs every tagged column?
Tag-based masking depends on the column type matching a policy signature; a tag can hold one masking policy per supported type. If a column also has a directly assigned masking policy, that direct policy takes precedence. Review the effective policy per column rather than treating tag presence as sufficient evidence.
Claim to check: A masking tag always determines the result for every tagged column.
Buyer evidence still required
Tagged columns and actual data types.
Tag policies and direct column-policy assignments.
Effective query-role output for the intended columns.
Suggested review condition: Confirm type coverage and precedence before asserting consistent tag-based masking.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Column inventory, data types, tag inheritance, direct policies and query-role context.
Optional saved evidence: Preserve the effective-policy questions behind a supplier masking claim.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
GitHub checks: Successful status and skipped execution
Does a passing required GitHub check prove its test job actually ran?
Required checks accept success, skipped and neutral conclusions. A job skipped by a condition can report success, while a whole workflow skipped by path or branch filtering can remain pending. Review job execution and the applicable commit, not just the merge badge, before claiming a release passed a specific test.
Claim to check: A green required-check badge proves test execution.
Buyer evidence still required
Required check identity and applicable commit.
Job conditions, execution steps and conclusion.
Test output bound to the accepted revision.
Suggested review condition: Require actual execution evidence before describing a skipped or neutral check as a passed test.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Branch rules, workflow version, check identity, conditions and commit-bound test output.
Optional saved evidence: Preserve the difference between merge eligibility and demonstrated test execution.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Can a reusable GitHub workflow grant itself broader GITHUB_TOKEN permissions than its caller?
Nested reusable workflows can retain or reduce the caller token permissions, not elevate them. The actual permission chain therefore matters when diagnosing an operation or reviewing claimed isolation. This constraint concerns GITHUB_TOKEN; it does not establish the scope of other credentials supplied to the job.
Claim to check: A called workflow can independently elevate its inherited job token.
Buyer evidence still required
Caller and nested workflow references.
Effective GITHUB_TOKEN permissions at each call.
Inventory of other credentials available to the job.
Suggested review condition: Review the complete credential set before treating the token ceiling as total privilege isolation.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Caller/callee revisions, token permissions and separately supplied credentials.
Optional saved evidence: Save the authority chain used to review a reusable deployment workflow.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Does passing secrets to one reusable GitHub workflow automatically pass them to every nested workflow?
Secrets are passed only to the directly called workflow. In a caller-to-intermediate-to-nested chain, the intermediate workflow must also forward the relevant secrets. Explicit mappings and secrets: inherit have different breadth. Review each call boundary without exposing the values when assessing credential disclosure.
Claim to check: Secrets automatically propagate through the entire workflow chain.
Buyer evidence still required
Caller/callee chain and exact workflow revisions.
Named secret mappings or inherit settings per hop.
Authorized recipients and required credential purpose.
Suggested review condition: Require a per-hop disclosure map before approving secret inheritance across workflow owners.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Workflow ownership, references, secret names and per-hop forwarding; never include values.
Optional saved evidence: Preserve credential-routing evidence without retaining sensitive credentials.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Which workflow directly receives the secret?
Is secrets: inherit used?
Which named secrets are mapped?
Does the next nested workflow receive them?
Was forwarding explicit at each hop?
Who owns each reusable workflow?
Are all forwarded secrets needed?
Could an environment secret change the effective source?
Does a valid GitHub OIDC token prove an approved reusable deployment workflow ran?
For reusable workflows, ordinary workflow and ref claims describe the caller, while job_workflow_ref identifies the called workflow. Cloud trust policies must use the supported claim or subject conditions for the intended restriction. Token validity alone does not establish that the buyer configured an approved-workflow boundary.
Claim to check: A valid token proves the expected reusable workflow was authorized.
Buyer evidence still required
Caller identity and called-workflow reference.
Cloud-provider claim support and actual trust policy.
Dated token-claim evidence with sensitive token material removed.
Suggested review condition: Check caller and callee restrictions separately before accepting workflow-specific cloud access.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Caller, reusable workflow revision, provider-supported claims and effective trust conditions.
Optional saved evidence: Save the identity binding behind a deployment-credential decision.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Which claims describe the caller?
What does job_workflow_ref identify?
Does the provider support that claim?
Is the expected workflow reference constrained?
Is the audience checked?
Does the subject include the intended boundary?
Is the workflow pinned to a revision?
Can another caller meet the policy?
What proves the active cloud trust rule?
Does token validity prove policy correctness?
Were sensitive token values excluded from the review?
Build artifacts: Names, replacement and object identity
Does reusing an artifact name mean a later download contains the same approved build?
The upload-artifact documentation describes immutable artifacts and an overwrite option that deletes and replaces the named artifact with a new ID. A name alone is therefore not a durable identity. Bind acceptance to the artifact ID, digest and producing run, and distinguish retention availability from content identity.
Claim to check: An unchanged artifact name proves unchanged build content.
Buyer evidence still required
Artifact ID and digest at approval.
Producing run and source revision.
Replacement history, retention and retrieved digest.
Suggested review condition: Do not accept name-only matching as proof that the downloaded artifact was approved.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Action version, artifact ID, digest, producing run, revision and retention policy.
Optional saved evidence: Preserve the artifact identity needed to compare approval with later retrieval.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
GitLab manual jobs: Optional steps and blocking gates
Does a manual GitLab job necessarily block release until someone approves it?
Manual jobs can be optional or blocking. Outside rules, when: manual defaults to allow_failure true; inside rules, its default is false. Explicit configuration can alter the outcome. A pipeline can succeed despite optional manual-job failures, so inspect the effective gate rather than relying on the manual button.
Claim to check: Every manual job is a mandatory approval gate.
Buyer evidence still required
Expanded job configuration and effective allow_failure.
Rules matched for the release event.
Pipeline state and authorized operator evidence.
Suggested review condition: Require evidence of a blocking gate before treating a manual job as mandatory release approval.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. GitLab version, expanded rules, allow_failure, release event and operator permissions.
Optional saved evidence: Save the enforcement basis behind a manual-release-control claim.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Cross-project artifacts: Successful history and current builds
Does GitLab needs:project wait for the current upstream pipeline before downloading its artifact?
needs:project retrieves artifacts from the latest successful specified job for the selected ref. It does not wait for an already-running pipeline on that ref. A consumer can therefore receive an earlier successful result. Record the producing job, commit and digest before equating that artifact with the current release.
Claim to check: A cross-project dependency always retrieves the current upstream build.
Buyer evidence still required
Project, job and ref used for retrieval.
Actual producer job and commit identity.
Artifact digest compared with the release expectation.
Suggested review condition: Require producer identity reconciliation before accepting a cross-project artifact as the current build.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Project, job, ref, actual producer run, source commit, entitlement and digest.
Optional saved evidence: Preserve the source-to-artifact binding used to approve an external pipeline result.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Build provenance: Detail level and argument disclosure
Does publishing a Docker provenance attestation keep build arguments private?
The min mode omits build-argument values, while max mode contains additional build detail including argument values and the Dockerfile. Secrets should use the documented secret mechanism rather than build arguments. Review the actual attestation and intended audience; provenance presence alone does not establish confidentiality or an approved build.
Claim to check: Provenance metadata never exposes build inputs.
Buyer evidence still required
Buildx mode and generated attestation.
Argument usage and secret-handling configuration.
Publication destination, audience and subject digest.
Suggested review condition: Review disclosure and subject identity before publishing or accepting provenance.
This condition is a VAREXIS review rule, not a statement of the vendor's policy.
The buyer configuration, contract, effective entitlement and operational evidence have not been inspected. Missing evidence does not establish absence or failure of the feature.
Procurement evidence support only; no supplier clearance, legal conclusion, configuration audit or verification of the buyer's claim is supplied.
Recheck: A saved purchase does not recheck the source or buyer configuration. Buildx version, mode, argument usage, secret handling, output payload and audience.
Optional saved evidence: Save the disclosure and artifact-binding basis for accepting build provenance.
Single purchase: Existing server-saved version-bound route snapshot for later authenticated retrieval.
Evidence Receipt: The same snapshot plus the existing unsigned delivery receipt.
Hashes identify content versions; they do not prove truth or provide a signature.
Source response hashes and review dates are included in the JSON. The publisher documentation can change; a purchase does not refresh it.
Practical agent questions
Was provenance generated in min or max mode?
Are build-argument values included?
Does the attestation contain the Dockerfile?
Were credentials passed as build arguments?
Was the dedicated secret mechanism used?
Who can read the attestation?
Does its subject digest match the image?
Was the actual payload inspected?
Can detailed provenance expose internal build context?