top companies

{
  "id": "P11-C-001",
  "evidence_class": "observed",
  "source": "https://www.useparagon.com/blog/secure-integration-platforms-enterprise-ai-agents",
  "observed": "2026-08-27",
  "name": "Paragon",
  "category": "embedded-ipaas",
  "claim": "Embedded iPaaS with managed integration auth; markets an explicit AI-agent security posture (tokens never exposed to agent runtime).",
  "tenancy_isolation": "Vendor claims per-end-user token isolation enforced at the connection layer / in the data path rather than configured after the fact; tokens encrypted at rest; VPC-deployable and EU-region options.",
  "approval_model": "Not observed as a per-action approval queue. Consent is the OAuth grant at connect time; RBAC/SCIM/SAML govern the admin console, not individual agent actions.",
  "idempotency_retry": "Not observed on the pages read. No documented idempotency-key contract found.",
  "receipts_audit": "Per-action audit logs, forwardable to customer SIEM (vendor claim).",
  "limitations": "Primary evidence is Paragon's own marketing/blog, not docs.useparagon.com; docs security URL 404'd on fetch. SOC 2 Type II + HIPAA are claims, not inspected reports. Competitor (Nango) alleges opaque 5-figure pricing. Isolation mechanism described in prose, not architecture detail.",
  "disposition": "register"
}

{
  "id": "P11-C-002",
  "evidence_class": "observed",
  "source": "https://docs.merge.dev/basics/authentication/",
  "observed": "2026-08-27",
  "name": "Merge.dev",
  "category": "unified-api",
  "claim": "Unified API across HRIS/ATS/CRM/file-storage etc.; per-end-user Linked Accounts addressed by account_token.",
  "tenancy_isolation": "account_token in X-Account-Token header scopes every request to one Linked Account; token obtained only after the end user completes Merge Link. Default posture is MULTI-tenant (three shared AWS regions); single-tenant is a premium add-on. Two encryption layers (storage + application), extra application-layer encryption for PII.",
  "approval_model": "Consent at Link time. Link Token creation can set per-Common-Model permissions for the account being linked — a scope-narrowing primitive at connect time, not per action.",
  "idempotency_retry": "Webhooks: 5XX or >30s timeout retried up to two more times with exponential backoff; 4XX not retried. Merge may disable a receiver after sustained failures. Merge recommends webhooks PLUS polling because retries can still drop changes.",
  "receipts_audit": "X-Merge-Webhook-Signature is unique per event and is Merge's documented recommendation for receiver-side dedupe. Rate limits applied per Linked Account.",
  "limitations": "IMPORTANT: Merge documents no idempotency KEY for writes; dedupe is pushed onto the receiver via signature uniqueness. Merge stores end-user data and credentials by default and retains indefinitely until actively deleted; revoking an integration does NOT delete existing data. Encryption/compliance details come from Help Center articles, not an inspected report.",
  "disposition": "top10"
}

{
  "id": "P11-C-003",
  "evidence_class": "observed",
  "source": "https://pipedream.com/docs/connect/managed-auth/quickstart",
  "observed": "2026-08-27",
  "name": "Pipedream Connect",
  "category": "embedded-ipaas",
  "claim": "Managed auth + connector runtime where the host app's own user identity is the isolation key.",
  "tenancy_isolation": "external_user_id supplied by the host app is the primary isolation key; credentials saved per external_user_id per environment. Two hard environments (development / production) keep dev and prod credentials separate; dev capped at 10 unique external user IDs. Deletion via DELETE /v1/connect/{project_id}/users/{external_user_id} is permanent and removes all connected accounts.",
  "approval_model": "OAuth consent at connect time via short-lived Connect token generated server-side; the same user ID must be passed on the frontend connectAccount() call. No per-action approval observed.",
  "idempotency_retry": "Not observed. No idempotency-key contract found in the pages read.",
  "receipts_audit": "Not observed as an audit-trail product surface. Accounts are queryable/filterable by external_user_id and app.",
  "limitations": "Documented sharp edge: when running a workflow on behalf of an end user, only ONE account per app can be used — with multiple connected accounts Pipedream silently picks the MOST RECENTLY CREATED. That is an ambient-authority hazard for an agent runtime. Also cannot resolve external user ID at runtime on a timer trigger; it must arrive in the triggering event.",
  "disposition": "register"
}

{
  "id": "P11-C-004",
  "evidence_class": "observed",
  "source": "https://docs.arcade.dev/en/get-started/about-arcade",
  "observed": "2026-08-27",
  "name": "Arcade.dev",
  "category": "agent-actions",
  "claim": "Explicitly positions as an actions/MCP runtime for agents, with per-tool OAuth scopes and token injection so the model never sees a token.",
  "tenancy_isolation": "Tokens stored per end user; agent acts as the end user, not a shared service account. Identity federated from the host IdP via User Sources (Auth0, Clerk, Microsoft Entra ID, Okta, Stytch). In production the END USER IS VERIFIED BY THE CUSTOMER'S CODE, not by Arcade — client.auth.confirm_user(flow_id, your_user_id). Multi-user production requires bringing your own OAuth app credentials.",
  "approval_model": "Per-tool declared scopes (@tool(requires_auth=OAuth2(provider_id=..., scopes=[...]))). On a call lacking scope, the engine INTERRUPTS and drives the OAuth challenge; execution resumes only after the user consents. Token injected into tool Context — client and LLM never see it. Authorization is remembered until expiry/revocation, so it is consent-per-scope, NOT consent-per-invocation.",
  "idempotency_retry": "Not observed. No idempotency contract documented on the pages read.",
  "receipts_audit": "OpenTelemetry audit logs; dedicated Audit Logs governance surface; MCP Gateways for centralized routing/policy; Contextual Access hooks supporting rate limiting and webhook-based policy checks.",
  "limitations": "The only human-in-loop mechanism observed is the OAuth consent interrupt; NO separate per-action approval queue is documented. '7,500+ tools across 81 MCP servers' is a vendor claim, uncounted. Registry and 'Warp Pipes' are early access. Deployment: cloud, AWS/Azure marketplaces, self-host via Helm, hybrid.",
  "disposition": "top10"
}

{
  "id": "P11-C-005",
  "evidence_class": "observed",
  "source": "https://docs.zapier.com/ai-actions/how-tos/stored/run-stored-action",
  "observed": "2026-08-27",
  "name": "Zapier AI Actions",
  "category": "agent-actions",
  "claim": "Exposes Zapier actions to AI apps with a first-class preview-before-execute contract.",
  "tenancy_isolation": "API-key auth via x-api-key header; connections tied to the Zapier account. Per-end-user isolation NOT observed — this is account-scoped, not tenant-scoped.",
  "approval_model": "STRONGEST OBSERVED PRIMITIVE: preview_only boolean on POST /api/v2/ai-actions/{id}/execute/. When true the response returns the resolved parameters the AI WOULD have used and an EMPTY results list — a dry-run that shows the exact bound arguments without side effects. UI flow: preview, inspect each field, Edit to correct, then Run. 'Require preview before running AI action' is on by DEFAULT and the action developer can force it always-on so the end user cannot disable it. Notable exception: inside GPTs, preview is OFF by default.",
  "idempotency_retry": "Not observed.",
  "receipts_audit": "Not observed as a durable receipt surface.",
  "limitations": "MATERIAL: a Zapier help article states AI Actions is no longer being developed and supported — treat as a design reference for the preview_only pattern, NOT as an adoptable dependency. Regenerating the API key breaks existing connections.",
  "disposition": "top10"
}

{
  "id": "P11-C-006",
  "evidence_class": "observed",
  "source": "https://help.openai.com/en/articles/11509118-admin-controls-security-and-compliance-for-plugins-and-apps",
  "observed": "2026-08-27",
  "name": "OpenAI ChatGPT Apps / Actions",
  "category": "agent-actions",
  "claim": "Ships a tiered, admin-governable consent model graded by action consequence rather than a binary allow/deny.",
  "tenancy_isolation": "OAuth 2.1 authorization-code flow per end user; guidance is to use an established IdP exposing a discovery document, supporting CIMD or DCR, and echoing the resource parameter into issued tokens. In agentic browsing, credentials are entered by the human into a surfaced login screen and are never seen by the model nor used in training.",
  "approval_model": "BEST-IN-CLASS OBSERVED TIERING: four levels — 'Always ask' (asks before ANY action including reads), 'Any changes' (auto-read, ask before any write), 'Important actions' (auto-read, ask before consequential/hard-to-undo/sensitive-exposure actions), and admin-only 'Never ask'. DEFAULT is 'Important actions'. Admins additionally get RBAC, action control (allow all / read-only / custom action set). Agentic browsing always confirms before consequential acts such as a reservation or payment. Apps SDK adds readOnlyHint per tool and per-tool securitySchemes.",
  "idempotency_retry": "Not observed.",
  "receipts_audit": "Not observed as a per-action receipt surface in the pages read; admin controls are policy-side.",
  "limitations": "The consequence classification ('important', 'meaningful effect outside ChatGPT') is defined in prose, not by a machine-checkable predicate — the platform, not the developer, adjudicates it. App directory migrated to the Plugin directory 2026-07-09. AgentKit-specific approval docs were NOT reached; Workspace Agents reportedly use per-agent builder-set controls (inferred, unverified).",
  "disposition": "top10"
}

{
  "id": "P11-C-007",
  "evidence_class": "observed",
  "source": "https://developers.basistheory.com/docs/concepts/proxies/",
  "observed": "2026-08-27",
  "name": "Basis Theory",
  "category": "credentials",
  "claim": "Tokenization vault whose Proxy lets a system USE a secret in an outbound call without ever holding the plaintext.",
  "tenancy_isolation": "Sensitive values replaced by tokens; plaintext lives only in the vault. Proxy TERMINATES the inbound TLS connection and initiates a NEW TLS connection to the destination, so plaintext is never returned to the caller. Inbound direction also supported: requests routed through the proxy are tokenized BEFORE reaching the customer's servers.",
  "approval_model": "Destination allowlisting is the control: Ephemeral Proxy (zero setup, destination specified in-request) can be DISABLED PER TENANT so that only Pre-Configured Proxies — fixed, pre-registered destinations — are usable. That is a deny-by-default egress boundary.",
  "idempotency_retry": "Not observed.",
  "receipts_audit": "Not observed in pages read. BT-PROXY-DESTINATION-STATUS surfaces destination status distinctly from proxy status.",
  "limitations": "PCI/payments-shaped rather than OAuth-connector-shaped; not a catalog. '95% PCI scope reduction' is vendor marketing. Proxy Expressions allow injecting computed headers (e.g. signatures) referencing the detokenized body — powerful but a code-execution surface (Node.js transforms) worth threat-modelling.",
  "disposition": "top10"
}

{
  "id": "P11-C-008",
  "evidence_class": "observed",
  "source": "https://prismatic.io/docs/instances/integration-marketplace/",
  "observed": "2026-08-27",
  "name": "Prismatic",
  "category": "embedded-ipaas",
  "claim": "Embedded iPaaS built on an integration/instance split: one definition deployed as many per-customer instances.",
  "tenancy_isolation": "An 'integration' is the productized definition; an 'instance' is a configured deployed copy for ONE customer, carrying that customer's credentials and config with no code copying. Prismatic itself argues (against competitors) that application-layer-only isolation enforced by code convention rather than architectural boundary is 'one bug away' from cross-tenant exposure, and warns that sharing one encryption key across customer credentials exposes the whole base on a single failure.",
  "approval_model": "Not observed as per-action approval. Marketplace activation by the customer is the consent event; embeddable as iframe, via embedded SDK for a custom marketplace, or by giving customers Prismatic logins.",
  "idempotency_retry": "Customer-facing SELF-SERVE RETRY of failed executions, with the vendor's customer choosing how much retry access end customers get. Alert monitors catch connection exceptions proactively.",
  "receipts_audit": "Execution logs recording what ran, when, and for which customer; connection and instance logs. Notably logs capture execution METADATA, not customer-sensitive data unless explicitly logged — a deliberate receipt/PII separation.",
  "limitations": "Isolation architecture detail is asserted in Prismatic's own competitive blog posts; the docs page read covers the marketplace, not the isolation internals. Compliance claims (SOC 2/GDPR/HIPAA/CJIS) not inspected.",
  "disposition": "register"
}

{
  "id": "P11-C-009",
  "evidence_class": "observed",
  "source": "https://developers.apideck.com/get-started",
  "observed": "2026-08-27",
  "name": "Apideck Vault / Unify",
  "category": "unified-api",
  "claim": "Unified API where a single consumer ID drives server-side token look-up and injection.",
  "tenancy_isolation": "Connections are ALWAYS scoped to a consumer; consumer ID may be a user/account/device ID. Caller passes only the consumer ID (X-APIDECK-CONSUMER-ID plus X-APIDECK-APP-ID and Authorization) and Vault performs the token look-up and injection server-side — the calling app never handles the third-party token. Multiple consumers per application supported.",
  "approval_model": "Consent at connect time via a short-lived Vault SESSION: POST /vault/sessions returns a session_uri containing a bearer token, plus a redirect_uri for return. Three strategies: Vault API (own UI), Vault JS (embeddable), Hosted Vault (no-code at vault.apideck.com). Data minimization — Vault requests only the minimum scopes needed. OAuth connectors get full Authorization Code flow, browser-based only.",
  "idempotency_retry": "Not observed.",
  "receipts_audit": "Not observed as an audit product surface.",
  "limitations": "Apideck claims it does NOT store your data (calls proxied in real time source-to-app) — a materially different posture from Merge, which stores by default; this is a vendor claim not independently verified. API key regeneration is the compromise remedy.",
  "disposition": "register"
}

{
  "id": "P11-C-010",
  "evidence_class": "observed",
  "source": "https://www.browserbase.com/templates/context",
  "observed": "2026-08-27",
  "name": "Browserbase + Stagehand",
  "category": "browser-automation",
  "claim": "Productizes the browser itself as a connector runtime for services with no usable API.",
  "tenancy_isolation": "Every session runs in full isolation with encrypted connections and NO DATA PERSISTENCE BETWEEN RUNS by default. Enterprise adds SSO/SAML, RBAC, per-project isolation, encrypted storage, private networking. Credentials injected via a 1Password integration rather than hardcoded. Regional routing supports data residency.",
  "approval_model": "Not observed — no consent or approval primitive. This is the category's defining gap: authority is whatever the injected session can reach, with no scope narrowing.",
  "idempotency_retry": "Not observed, and structurally hard: UI actions are not idempotent and there is no action-level dedupe key. Stagehand v3 self-healing actions retry at the DOM level, which is retry WITHOUT idempotency — a double-submit hazard.",
  "receipts_audit": "Session-level recording/observability rather than per-action receipts.",
  "limitations": "Contexts DELIBERATELY defeat the no-persistence default: cookies, tokens and storage are saved and replayed, and MFA can be completed once and reused across future sessions — a durable bearer-credential blob outside any OAuth scope model. Known local bug: stagehand.close() deletes userDataDir (issue #794). Proxy/stealth/IP-rotation features exist to evade bot detection, which carries ToS and legal exposure distinct from the technical risk.",
  "disposition": "top10"
}

{
  "id": "P11-C-011",
  "evidence_class": "observed",
  "source": "https://support.anthropic.com/en/articles/11697096-anthropic-mcp-directory-policy",
  "observed": "2026-08-27",
  "name": "Anthropic MCP / Connectors Directory",
  "category": "agent-actions",
  "claim": "Curated registry of MCP servers gated by a published safety policy, with initial AND ongoing review.",
  "tenancy_isolation": "Not a credential broker — isolation is the MCP server's responsibility. Directory policy is a governance layer over third-party servers.",
  "approval_model": "Policy REQUIRES that for sensitive operations (e.g. financial transactions) developers clearly disclose capabilities and provide user control options. Guidance to users is to connect only to trusted servers. Servers run only with permissions the user explicitly grants.",
  "idempotency_retry": "Not specified by the directory policy.",
  "receipts_audit": "Not specified by the directory policy; vulnerability reporting path exists for malicious servers.",
  "limitations": "NOTABLE ANTI-PROMPT-INJECTION RULES, directly relevant to P11: servers must not evade Claude's safety guardrails; must not call or COERCE Claude into calling other servers; must not interfere with Claude calling other servers' tools; and must NOT direct Claude to dynamically pull behavioural instructions from external sources to execute. Requires OAuth 2.0 with recognized CA certs and Dynamic Client Registration. The '439 connectors' figure is from a third-party blog, NOT counted from source — do not quote it.",
  "disposition": "register"
}

{
  "id": "P11-C-012",
  "evidence_class": "observed",
  "source": "https://docs.runalloy.com/platform",
  "observed": "2026-08-27",
  "name": "Alloy Automation",
  "category": "embedded-ipaas",
  "claim": "Embedded iPaaS plus unified/connectivity API; connector actions follow discover -> schema -> create credential -> execute.",
  "tenancy_isolation": "End users managed as distinct entities with per-user tokens; frontend SDK auth uses SHORT-LIVED JWTs minted server-side via GET /users/{userId}/token. Vendor claims credential isolation, automatic token refresh, detailed logging.",
  "approval_model": "Not observed as per-action approval; consent occurs at credential creation.",
  "idempotency_retry": "Connectivity API is claimed to handle 'OAuth, schema mapping, retries, versioning and monitoring' — retries asserted, semantics NOT documented in what was read. No idempotency key observed.",
  "receipts_audit": "Embedded API exposes workflow execution monitoring and lifecycle control; 'detailed logging' claimed.",
  "limitations": "Much of the security framing comes from vendor summary and competitor (Truto) comparison posts rather than inspected security docs. '1000+ apps' vs '20+ platforms' for the Connectivity API is an inconsistency in the vendor's own material — the smaller number is the one to trust for the unified surface. Encryption-at-rest and SOC 2 specifics NOT verified.",
  "disposition": "register"
}

{
  "id": "P11-C-013",
  "evidence_class": "observed",
  "source": "https://docs.workato.com/oem.html",
  "observed": "2026-08-27",
  "name": "Workato Embedded",
  "category": "embedded-ipaas",
  "claim": "Enterprise embedded iPaaS with nested per-customer workspaces and an explicit agentic layer.",
  "tenancy_isolation": "Embedded Customer workspaces nested beneath an Admin workspace, using Workato's multi-tenancy architecture, surfaced through secure iframes. Each customer carries a partner-assigned external ID plus a Workato-assigned workspace ID. Per-customer app access restriction via Settings > App access. Custom OAuth profiles can be applied per customer workspace, replacing the default profile — explicitly supporting access isolation per team/environment/customer. OAuth 2.0 preferred so no credentials are stored; where storage is required, 256-bit key encryption.",
  "approval_model": "HUMAN APPROVAL STEPS are a first-class workflow primitive: recipes can require human input before continuing. Agentic layer (Workato GO) builds forms, approvals and user confirmations into the interface, plus 'Guardrails' for agent policy. Access-control caveat observed: genies using verified-user-access skills CANNOT be used with the 'Assign task to genie' action.",
  "idempotency_retry": "Not observed in the pages read.",
  "receipts_audit": "Not observed in detail; job/recipe execution history implied.",
  "limitations": "Enterprise pricing and complexity put this well outside Actionist's likely build envelope; value here is the PATTERN (approval-step-as-workflow-primitive, per-customer OAuth profile) not the product. Agentic 'Guardrails' inspected only via FAQ summary, not a spec.",
  "disposition": "register"
}

{
  "id": "P11-C-014",
  "evidence_class": "observed",
  "source": "https://developer.hashicorp.com/vault/docs/concepts/lease",
  "observed": "2026-08-27",
  "name": "HashiCorp Vault",
  "category": "credentials",
  "claim": "Reference implementation of dynamic, leased, auto-revoked credentials.",
  "tenancy_isolation": "Machine identity authenticates (AppRole / Kubernetes SA) and requests a dynamic secret; Vault mints a BRAND-NEW backing credential per request, so two instances of the same service hold two different database users. Namespaces/tenants separate environments.",
  "approval_model": "Fine-grained policy engine gates which identity may reach which secret path. Not an end-user consent model.",
  "idempotency_retry": "N/A to actions; leases are renewable with routine check-in.",
  "receipts_audit": "Detailed audit logging; the lease model itself strengthens audit because consumers must check in to renew, making the trail continuous rather than point-in-time.",
  "limitations": "KEY ARCHITECTURAL LESSON AND ITS LIMIT: ALL dynamic secrets are REQUIRED to carry a lease — even eternally-valid data — specifically to force routine check-ins. Revocation invalidates immediately and blocks renewal (e.g. AWS access keys deleted on revoke). BUT: once a lease is issued Vault does not follow the credential into the target system — which rows were touched is outside its trail. Licence: BSL since 2023; IBM completed the HashiCorp acquisition early 2025.",
  "disposition": "register"
}

{
  "id": "P11-C-015",
  "evidence_class": "observed",
  "source": "https://infisical.com/docs/documentation/platform/dynamic-secrets/overview",
  "observed": "2026-08-27",
  "name": "Infisical",
  "category": "credentials",
  "claim": "MIT-licensed community edition with a Vault-shaped dynamic-secrets model.",
  "tenancy_isolation": "Same shape as Vault — machine identity via Universal Auth or Kubernetes auth requests a dynamic secret and receives a unique per-request database user, delivered by SDK, API, or K8s operator. Emphasises client-side decryption to limit server-side breach blast radius.",
  "approval_model": "RBAC; access requests. Not an end-user action-consent model.",
  "idempotency_retry": "N/A.",
  "receipts_audit": "RBAC, audit logs, secret versioning, secret scanning, single audit trail across clouds/K8s/CI.",
  "limitations": "Dynamic DB secrets are NEWER than Vault's and cover FEWER engines — do not treat as at-parity. Licence advantage is real and relevant: MIT community edition vs Vault's BSL. Comparison evidence is largely third-party blog roundups, not inspected code or licence text — the MIT claim should be verified against the repo LICENSE before it enters a client deliverable.",
  "disposition": "register"
}

{
  "id": "P11-C-016",
  "evidence_class": "observed",
  "source": "https://www.doppler.com/blog/secrets-management-tools-2025",
  "observed": "2026-08-27",
  "name": "Doppler",
  "category": "credentials",
  "claim": "Static-secret storage and sync with strong developer ergonomics.",
  "tenancy_isolation": "Project/environment scoping only.",
  "approval_model": "RBAC, SAML SSO on Team plan.",
  "idempotency_retry": "N/A.",
  "receipts_audit": "Audit logs (90 days on Team plan), secret versioning.",
  "limitations": "REJECTED AS A MODEL FOR THIS PLANE: centres on storing and syncing STATIC secrets rather than minting short-lived ones (dynamic secrets in beta). Cannot be self-hosted. Only one organizational layer, making multi-tenant configurations difficult. Permissions are PROJECT-based, not per-secret — anyone with a project's production access reads every secret in it, which is precisely the ambient-authority failure a per-tenant connector plane must avoid.",
  "disposition": "rejected"
}

{
  "id": "P11-C-017",
  "evidence_class": "observed",
  "source": "https://www.anon.com/",
  "observed": "2026-08-27",
  "name": "Anon",
  "category": "browser-automation",
  "claim": "User-permissioned auth layer letting agents act as the user inside services with no clean API.",
  "tenancy_isolation": "Vendor claims credentials are NEVER STORED, instead streamed through isolated environments; authenticated sessions held under a zero-trust architecture supporting SSO/OAuth/2FA; claims complete tenant separation and comprehensive audit logging.",
  "approval_model": "Developers can manage, track, TRANSFER and REVOKE access to user accounts — revocation as a first-class control. Per-action approval not observed.",
  "idempotency_retry": "Not observed.",
  "receipts_audit": "'Comprehensive audit logging' claimed; not inspected.",
  "limitations": "EVIDENCE IS WEAK — findings rest on the company's own marketing site plus third-party directory listings; official docs (docs.anon.com) were NOT reached. 'Never stores credentials' is a strong claim made without an inspected mechanism and should not be repeated to Cena as fact. SOC 2 reported July 2025, not inspected. DISAMBIGUATION: anon.im is an unrelated product, not this company.",
  "disposition": "register"
}

{
  "id": "P11-C-018",
  "evidence_class": "inferred",
  "source": "https://docs.merge.dev/basics/webhooks/merge-webhooks/",
  "observed": "2026-08-27",
  "name": "Cross-vendor idempotency gap",
  "category": "unified-api",
  "claim": "SYNTHESIS ROW, not a company: across every surface read, documented WRITE-side idempotency keys were essentially absent.",
  "tenancy_isolation": "N/A.",
  "approval_model": "N/A.",
  "idempotency_retry": "Of the surfaces inspected, none documented a write idempotency-key contract for agent actions. Merge documents webhook retry policy and pushes dedupe onto the receiver via per-event signature uniqueness. Alloy asserts 'retries' without semantics. Prismatic offers operator-initiated retry of failed executions. Browser automation retries at the DOM level with no dedupe key at all.",
  "receipts_audit": "N/A.",
  "limitations": "This is an INFERRED absence from a partial survey (18 of ~33 planned surfaces; Stripe's idempotency-key contract was queued as the positive control but NOT retrieved before the run was cut short). Absence of evidence in docs read is not proof the contracts do not exist. Must be re-checked against Stripe, Nango, Kombo, Hotglue, Tray and Composio before this is asserted in a client deliverable.",
  "disposition": "register"
}

{
  "id": "P11-C-019",
  "evidence_class": "observed",
  "source": "https://docs.stripe.com/api/idempotent_requests + https://docs.stripe.com/error-low-level#idempotency + https://docs.stripe.com/rate-limits",
  "observed": "2026-08-27",
  "name": "Stripe (idempotency-key contract)",
  "category": "reference-contract",
  "claim": "THE positive control for the whole P11 idempotency question: a fully specified, publicly documented client-supplied idempotency-key contract on a high-volume money-moving API. Every other surveyed surface should be measured against this.",
  "tenancy_isolation": "Keys are scoped per Stripe account (docs: keys must 'unambiguously identify a single operation within your account over the last 24 hours'). Connect platforms and connected accounts have distinct request allocations. Key scope is the account, not a per-end-user tenant, so a multi-tenant caller must namespace keys itself.",
  "approval_model": "No human-in-loop approval primitive in the idempotency layer itself; this contract is about exactly-once execution, not authorisation. Docs advise against using sensitive data (emails, personal identifiers) as key material.",
  "idempotency_retry": "FULL CONTRACT, observed: (1) SUPPLY - client-generated key in the `Idempotency-Key` HTTP header, up to 255 chars; Stripe suggests UUIDv4 or another high-entropy random string, or deriving from a user-attached object such as a cart ID to protect against double submission. (2) LIFETIME - keys are pruned after at least 24 hours; docs state 'We generate a new request if a key is reused after the original is pruned', so replay protection SILENTLY LAPSES rather than erroring. (3) REPLAY, IDENTICAL PARAMS - Stripe saves the status code and body of the first request 'regardless of whether it succeeds or fails' and returns the same result on retry, INCLUDING cached 500s; a replayed response carries the header `Idempotent-Replayed: true`, which is the machine-readable receipt that dedupe fired. (4) REPLAY, DIFFERENT PARAMS - the idempotency layer compares incoming parameters to the original and errors if they differ; 'Sending the same idempotency with different parameters produces an error indicating that the new request didn't match the original.' (5) METHODS - all POST requests accept keys; GET and DELETE are idempotent by definition and keys there have no effect. (6) CONCURRENCY - HTTP 409 Conflict is documented as 'The request conflicts with another request (perhaps due to using the same idempotent key)'. (7) SAVE BOUNDARY - results are saved 'only after the execution of an endpoint begins'; if params fail validation or the request conflicts with a concurrent one, no idempotent result is saved and the request may be retried. (8) RETRY SIGNAL - `Stripe-Should-Retry: true|false` header tells the client whether a retry is worthwhile; absent means undetermined, fall back to status code. SDKs respect it automatically. (9) 500s - treat as INDETERMINATE; the cached response will not change, but Stripe may reconcile (roll forward or back) and fire webhooks for objects created during reconciliation, so a cached 500 is not proof nothing happened. Recommended mitigation: send a local identifier in `metadata` so reconciliation webhooks can be cross-referenced to local state.",
  "receipts_audit": "`Idempotent-Replayed: true` response header is the explicit replay receipt. Request IDs are assigned per request (notably NOT assigned to lock-timeout 429s, which Stripe does not process). Webhooks are the documented backstop for objects created during post-500 reconciliation.",
  "limitations": "CRITICAL CAVEAT, observed and directly load-bearing for Actionist: RATE LIMITERS RUN BEFORE THE IDEMPOTENCY LAYER. Docs: 'a request that's rate limited with a 429 can produce a different result with the same idempotency key because rate limiters run before the API's idempotency layer.' The same applies to a 401 with a missing API key and most 400s with invalid params. So the key does NOT make a request universally replay-stable - it stabilises only requests that reached endpoint execution. Stripe's own advice for 4xx: 'the safest strategy where 4xx errors are concerned is to always generate a new idempotency key.' Second caveat: the 24h window means an idempotency key is a SHORT-TERM crash-safety device, not a durable exactly-once ledger; any agent needing longer-horizon dedupe must keep its own record. Third: 429 can also mean `lock_timeout` (object lock contention, no rate-limit headers, no request ID) - a different failure needing serial mutation of the same object, not backoff alone. Rate limits observed: 100 req/s live, 25 req/s sandbox global; 25 req/s per endpoint; separate concurrency limits with `Stripe-Rate-Limited-Reason` header values global-rate/endpoint-rate/global-concurrency/endpoint-concurrency/resource-specific.",
  "disposition": "top10"
}

{
  "id": "P11-C-020",
  "evidence_class": "observed",
  "source": "https://composio.dev/pricing",
  "observed": "2026-08-27",
  "name": "Composio (as paid hosted dependency)",
  "category": "agent-actions",
  "claim": "Re-surveyed deliberately as a PAID HOSTED DEPENDENCY rather than as OSS. The MIT badge covers an SDK that calls a metered hosted API; the economics and credential custody below are the real integration decision.",
  "tenancy_isolation": "Credentials are custodied in Composio's cloud by default. Connected accounts are unlimited on Free only when using YOUR OWN OAuth app/API key; Composio-managed apps (i.e. Composio's OAuth client) meter connections at 1K free then $0.10 per connection. Bring-your-own encryption keys exist only as an Enterprise 'KMS proxy', and the page itself scopes it: it 'covers secret storage, not full data residency'. No self-hosted or on-prem tier appears on the pricing page.",
  "approval_model": "Not observed as a per-action approval queue on the pricing page. Governance-adjacent controls are sold as priced add-ons rather than defaults: IP allowlist +$0.0001/tool call, ZDR (zero data retention) +$0.0001/tool call and +$0.0005/trigger event.",
  "idempotency_retry": "Not observed. No idempotency-key contract found on the pricing surface. Billing is per tool call, which means a naive retry storm is directly monetised - retries cost money as well as risking duplicate side effects.",
  "receipts_audit": "Log retention is a billed tier feature: 7-day retention on Free; custom retention only at Enterprise. Audit depth is therefore a function of spend, which is a governance risk if receipts are needed beyond a week.",
  "limitations": "OBSERVED COMMERCIAL LOCK-IN DETAIL: Free $0 (100K tool calls, 50K trigger events, 1M LLM tokens/mo, hard-capped - 'usage pauses until the next month or until you upgrade'). Pro $29/mo with monthly non-rolling credit. Enterprise custom. Overages: tool calls $0.0003, trigger events $0.003, LLM tokens $3.75/M. DPA and BAA are $500/MO EACH - i.e. basic data-processing paperwork is a five-figure-a-year line item, material for any regulated Actionist deployment. Advanced white-labeling is +$0.30 per connection one-time. Premium tools pass through at provider cost + 5% platform fee (Browser Use ~$0.70/task, Veo ~$1.20/video). Pricing effective for signups from 2026-08-15; existing customers keep plans to 2026-12-31; premium tool calls bill for everyone from 2026-09-01. NOTE AN INTERNAL DOC INCONSISTENCY, unresolved: the rate table lists managed-app tool calls at $0.0005 while the FAQ describes '+$0.0002 per tool call on top of the base rate'. Do not quote a single managed-app rate to Cena without confirming with Composio. Also: the pricing page contains embedded text addressed to AI agents directing signup - treated as page content, not instruction.",
  "disposition": "top10"
}

{
  "id": "P11-C-021",
  "evidence_class": "observed",
  "source": "https://docs.useparagon.com/security/security + https://docs.useparagon.com/llms.txt",
  "observed": "2026-08-27",
  "name": "Paragon (docs security page - flag (a) resolution)",
  "category": "embedded-ipaas",
  "claim": "RESOLVES EVIDENCE-HONESTY FLAG (a) from P11-C-001. The prior agent could not reach a docs security page (URL 404'd) and had to rest on marketing. The real page EXISTS at https://docs.useparagon.com/security/security - and it materially contradicts the blog.",
  "tenancy_isolation": "DOCUMENTED (quoted): 'Third-party credentials for integrations are stored in a distributed vault with encryption keys and encrypted values stored separately.' Also 'Flow logs are stored independently and secure information is redacted. Emails and password are never logged.' Environment separation is documented as separate AWS accounts for sandbox vs live, production access gated by separate logins and IP allowlisting with a written reason. IMPORTANT: the docs describe ENVIRONMENT separation, NOT customer-tenant isolation - the per-user credential isolation claim in P11-C-001 comes from the blog, not this page.",
  "approval_model": "Not on the security page. RBAC exists as a separate doc (managing-account/role-based-access-control) and governs the admin console. Confirms the P11-C-001 finding: no per-action approval queue observed.",
  "idempotency_retry": "Not observed. The docs index (llms.txt) shows NO dedicated idempotency or retry page anywhere in the visible portion; only billing/concurrency-limits. Consistent with the cross-vendor gap in P11-C-018.",
  "receipts_audit": "Confirmed richer than the blog suggested and now traceable to docs: monitoring/event-logs, monitoring/event-destinations with concrete SIEM sinks (Datadog, New Relic, Sentry, Slack), actionkit/actionkit-logs, monitoring/users. This is the strongest audit surface of the embedded-iPaaS cohort.",
  "limitations": "THE CONTRADICTION, and it cuts AGAINST the vendor: the marketing blog asserts SOC 2 Type II, GDPR and HIPAA coverage; the actual docs security page documents NO compliance certification at all - no SOC 2, no ISO 27001, no HIPAA - and no penetration testing, no vulnerability scanning, no bug bounty, and no data-retention policy. Its compliance section covers only a DPA available by emailing [email redacted]. Self-hosting IS real and well documented (on-premise/hosting-paragon-on-premise, infrastructure-architecture, costs, per-cloud configure guides for AWS/Azure/GCP), which is the genuine isolation answer. VERDICT: upgrade P11-C-001's evidence from marketing to docs for CREDENTIAL STORAGE and AUDIT, but DOWNGRADE its compliance line - SOC 2 Type II / HIPAA remain unverified vendor claims not present in the docs. Do not repeat them to Cena as fact.",
  "disposition": "top10"
}

{
  "id": "P11-C-022",
  "evidence_class": "observed",
  "source": "https://www.anon.com/ (200) + DNS: docs.anon.com has NO A/CNAME records (dig +short returns empty; curl: Could not resolve host)",
  "observed": "2026-08-27",
  "name": "Anon (flag (b) resolution - UNVERIFIED)",
  "category": "browser-automation",
  "claim": "RESOLVES EVIDENCE-HONESTY FLAG (b) from P11-C-017 as NEGATIVE. The 'never stores credentials' claim CANNOT be verified and must stay labelled marketing.",
  "tenancy_isolation": "UNVERIFIED. No technical documentation reachable.",
  "approval_model": "UNVERIFIED. No technical documentation reachable.",
  "idempotency_retry": "UNVERIFIED. No technical documentation reachable.",
  "receipts_audit": "UNVERIFIED. No technical documentation reachable.",
  "limitations": "HARD NEGATIVE EVIDENCE, re-run from source on 2026-08-27: docs.anon.com does not merely 404 - it HAS NO DNS RECORDS AT ALL (`dig +short docs.anon.com` returns empty; curl fails with 'Could not resolve host'). The marketing site www.anon.com returns 200. A targeted web search for Anon's credential-storage architecture returned no Anon-authored documentation, only third-party agentic-auth commentary. CONCLUSION: the 'never stores credentials' line is a marketing claim with ZERO corroborating technical documentation, and the absence of a docs subdomain is itself a maturity signal. RECOMMENDATION: do not cite Anon's credential posture in any client-facing Actionist material; if Anon matters to the design, the claim must come from the vendor under NDA or direct technical diligence. This row exists specifically so the negative result is recorded rather than silently dropped.",
  "disposition": "rejected"
}

{
  "id": "P11-C-023",
  "evidence_class": "observed",
  "source": "https://developer.tryfinch.com/ + https://developer.tryfinch.com/llms.txt",
  "observed": "2026-08-27",
  "name": "Finch",
  "category": "unified-api",
  "claim": "Unified API for HR and payroll; one access token per employer connection. Notable as a HIGH-CONSEQUENCE write surface (payroll deductions, benefit enrolment) with NO idempotency key.",
  "tenancy_isolation": "Strong and explicit. A Connect session (POST /connect/sessions, basic auth with client_id:client_secret) yields a connect_url; after end-user authorisation an auth code is exchanged at /auth/token for a bearer access_token returned alongside company_id, account_id, connection_id, provider_id and customer_id - so one token is scoped to exactly one employer connection. Redirect URIs must be pre-registered or code generation fails. Docs require a backend server for all API traffic (implementation-guide/Backend-Application/Backend-Security) and provide Store-Tokens and Disconnect-Connections guidance. RBAC for multi-tenant callers is documented at Backend-Application/Control-Access.",
  "approval_model": "Consent is the Finch Connect grant at connect time, scoped by the `products` array (e.g. ['directory','individual','employment']) which is echoed back in the token response - a genuine scope-narrowing primitive at connect time, not per action. Data Access Controls allow suppressing fields from responses; ssn is a separately requested product scope. Some providers (Gusto, TriNet) require a one-time security review before connection. Reauthentication is a documented first-class flow.",
  "idempotency_retry": "NO IDEMPOTENCY KEY - confirmed by reading the full docs index; no idempotency page exists anywhere in the documented set. The only dedupe-adjacent semantics are endpoint-level: enrolment is documented as 'an overwrite operation' where repeating a request does not create duplicate enrolments - i.e. safety is a property of the specific endpoint, not a contract the caller can rely on generally. Retry/backoff guidance lives in api-reference/development-guides/Handling-API-Responses. Webhooks cover account update, job completion and data change events.",
  "receipts_audit": "NO dedicated audit-log product. Nearest substitutes are Monitor Usage (implementation-guide/Backend-Application/Monitor-Usage) and Introspect (api-reference/management/introspect) which inspects the account behind a token. Rate limits are documented (api-reference/development-guides/Rate-Limits) including per-IP limits; Batch Requests is offered to reduce rate-limit risk.",
  "limitations": "Sandbox is a real strength and better than most of this cohort: a sandbox client_id/client_secret is issued at signup, `\"sandbox\": \"finch\"` is passed in the session request, and mock provider credentials are documented (ADP Workforce Now with good_user/good_pass), plus a full set of sandbox write endpoints for connections/accounts/payments/individuals/companies/jobs. Scope caveats observed: pay statements are READ-ONLY (only pay-statement RULES are writable); Benefits and Documents endpoints are read-only AND in beta ('is in beta and may change'), with enrolment writes routed through the Deductions API instead. Request Forwarding lets callers push/pull directly against the underlying provider API - a powerful escape hatch that also bypasses whatever normalisation Finch provides, so it inherits the raw provider's (undocumented here) retry semantics. THE RISK TO NAME FOR ACTIONIST: deduction create/update/enrol/unenrol are money-affecting payroll writes with no caller-supplied idempotency key; a network timeout on 'enroll individuals in deductions' is genuinely indeterminate.",
  "disposition": "register"
}

{
  "id": "P11-C-024",
  "evidence_class": "observed",
  "source": "https://docs.kombo.dev/ + https://docs.kombo.dev/llms.txt",
  "observed": "2026-08-27",
  "name": "Kombo",
  "category": "unified-api",
  "claim": "Unified API for HR tech (HRIS, ATS, LMS, ATS-Assessment), Europe-oriented, with a broad write surface across all four verticals.",
  "tenancy_isolation": "NOT DOCUMENTED in the public docs index. No page on the index is dedicated to auth, API keys, token handling, or security; the nearest references are a help-center Implementation page described as covering setup 'from API keys to your first sync' and a Best practices page mentioning 'Scopes, sync strategies, error handling, and scaling tips'. A security portal exists at https://security.kombo.dev (not fetched). INFERRED, not observed: a per-end-user connection token model comparable to Merge/Finch is likely given the category, but nothing on the index confirms it.",
  "approval_model": "Not observed. No consent, approval, or human-in-loop documentation on the index.",
  "idempotency_retry": "NO IDEMPOTENCY DOCUMENTATION AT ALL. The only repeat-safety semantics are endpoint-level upsert descriptions: for skill proficiency ratings, 'Re-sending the same skill and source overwrites the existing rating', and the staffing-entity skill endpoint 'updates the expectation in place'. LMS offers an async bulk upsert (post-courses-bulk) with a task-status poll (get-courses-bulk-task-id), which is a job-handle pattern - the closest thing to retry-safety on offer. Everything else (create absence, create application, create candidate, add attachment, add note, reject application, create interview) is a plain POST with no documented dedupe.",
  "receipts_audit": "NO audit-log documentation. Only changelog.kombo.dev and status.kombo.dev exist, and neither is an access-tracking audit log. Webhooks exist but only two are documented on the index (assessment:order-received, AI Apply status updates) with no delivery-guarantee, backoff, or signature-verification detail.",
  "limitations": "NO rate-limit page and NO sandbox/test-mode page anywhere in the docs index - a significant gap for a write-capable API and worse than Finch on both counts. IMPORTANT HONESTY CAVEAT: the fetched index is PARTIAL - its header points to a 'Developer documentation (650 pages)' index at /_llms/developer-documentation.md and instructs recursive following, so auth, rate-limit, idempotency and sandbox docs may exist one level deeper and were NOT ruled out. The correct statement is 'not surfaced in the top-level index', not 'does not exist'. Write surface is broad and consequential: creating applications, rejecting applications, moving applications between stages, deleting absences and removing candidate tags are all irreversible-ish actions against a customer's ATS/HRIS with no observed idempotency contract. An OpenAPI schema at https://api.kombo.dev/openapi.json is the right next artefact to settle auth headers and any idempotency header definitively.",
  "disposition": "register"
}

{
  "id": "P11-C-025",
  "evidence_class": "observed",
  "source": "https://www.hotglue.com/ (docs at https://docs.hotglue.com not fetched)",
  "observed": "2026-08-27",
  "name": "Hotglue",
  "category": "embedded-ipaas",
  "claim": "Embedded ETL/iPaaS for SaaS vendors shipping integrations to their own users; built on the open connector ecosystem (Singer spec and Airbyte YAML).",
  "tenancy_isolation": "NOT DOCUMENTED on the marketing site. No statement on where end-user OAuth tokens or API keys are stored, how they are encrypted, or whether tenant credentials are logically or physically separated. The one adjacent claim is about PAYLOAD data, not secrets: Hotglue 'never stores your customer data - we process it securely and deliver it directly to you'. Do not let that be read as a credential-custody claim; it is not one.",
  "approval_model": "Not observed. End-user connection is a hosted magic-link flow or an embeddable widget; consent is the OAuth grant at connect time.",
  "idempotency_retry": "Not observed. A REST API exists for managing connectors, triggering syncs and configuring settings, and structured logs plus webhook events are advertised, but no idempotency or retry contract is documented on the pages read.",
  "receipts_audit": "Structured logs and webhook events, with observability forwarding to Datadog and Heap. Depth unverified - advertised as features, not documented as contracts.",
  "limitations": "Deployment topology is an OPEN QUESTION: no self-hosted, BYOC or VPC option is stated anywhere, and the page reads as hosted SaaS, but the no-retention claim hints at pass-through processing on Hotglue infrastructure. Pricing is genuinely differentiated and worth noting for Actionist: PER-TENANT (a tenant = one of your users who has connected at least one integration), explicitly NOT usage- or volume-based - 'no unexpected spikes in your bill' - which is the opposite risk profile to Composio's per-tool-call metering. Claims 600+ connectors, all open-source and forkable, which is a real escape-hatch advantage over closed catalogues. SOC 2 Type II and GDPR are vendor claims with a displayed seal, NOT inspected reports; no HIPAA, ISO 27001, PCI, pen-test cadence, encryption specifics, subprocessor list or data residency detail. EVIDENCE LIMIT, stated honestly: this row rests on the marketing site only; docs.hotglue.com and /security were not fetched, so credential storage and isolation remain unassessed rather than assessed-and-found-absent.",
  "disposition": "register"
}

{
  "id": "P11-C-026",
  "evidence_class": "observed",
  "source": "https://openai.com/index/introducing-agentkit/ + https://labs.zenity.io/post/analyzing-the-security-risks-of-openai-s-agentkit (independent security analysis)",
  "observed": "2026-08-27",
  "name": "OpenAI AgentKit",
  "category": "agent-actions",
  "claim": "OpenAI's first-party agent-building stack: Agent Builder (visual multi-agent workflow canvas with versioning), ChatKit (embeddable agent UI), Connector Registry (central admin control of data/tool connections), and expanded Evals.",
  "tenancy_isolation": "Connector Registry is the isolation primitive: a single admin panel governing data sources ACROSS ChatGPT and the API, spanning multiple workspaces and organizations, with prebuilt connectors (Dropbox, Google Drive, SharePoint, Microsoft Teams) plus third-party MCP servers. IMPORTANT ACCESS GATE, observed: Connector Registry rolled out only to SELECTED API, Enterprise and Edu customers, and Global Admin Console access is a PREREQUISITE - so the governance layer is not available to an ordinary developer account. Credentials are custodied by OpenAI within that registry; no BYO-KMS or self-hosted option observed.",
  "approval_model": "STRONGEST OBSERVED APPROVAL PRIMITIVE OF THE AGENT-ACTIONS COHORT, and directly relevant to Actionist: Agent Builder exposes logic nodes including If/else conditionals, While loops, and a first-class USER APPROVAL node that halts the flow and requires a human approval before continuing. This is a graph-level, declarative human-in-the-loop gate rather than a bolted-on webhook - the pattern worth stealing. Guardrails are a separate open-source modular node that inspects its input for PII, prompt injection/jailbreak and misuse, with PII masking and jailbreak detection.",
  "idempotency_retry": "NOT OBSERVED. No idempotency-key contract documented for AgentKit workflows. A workflow with a While loop and tool calls but no idempotency contract is a duplicate-side-effect risk by construction - the approval node gates AUTHORISATION, not EXACTLY-ONCE EXECUTION. These are orthogonal safety properties and AgentKit currently supplies only the first.",
  "receipts_audit": "Evals expanded with datasets, TRACE GRADING, automated prompt optimization and third-party model support. Agent Builder provides full workflow versioning and preview runs. Trace grading is an evaluation surface rather than a tamper-evident audit log; do not conflate the two.",
  "limitations": "EVIDENCE CAVEAT, stated honestly: the canonical doc URLs 404'd on direct fetch (platform.openai.com/docs/guides/agentkit redirects to developers.openai.com/api/docs/guides/agentkit which returned 404), so this row rests on OpenAI's own launch announcement plus independent security analysis, NOT on retrieved reference documentation. Treat component details as launch-announcement-grade. Launch status at announcement (DevDay, 2025-10-06): ChatKit and Evals GA, Agent Builder BETA, Connector Registry limited rollout. Independent analysis (Zenity Labs) argues guardrails alone are insufficient; recommended compensating practice is to use Connector Registry for least privilege - avoid granting write or delete access where read-only suffices - and to place guardrail nodes both before input use and before output release. Core usage bills as standard OpenAI model pricing, with MCP server usage, chat session retention and Guardrails deployment as additional cost lines. STRATEGIC NOTE for Cena: this is the incumbent platform risk - OpenAI shipping the approval-node pattern first-party compresses the differentiation available to a third-party action layer.",
  "disposition": "top10"
}

{
  "id": "P11-C-027",
  "evidence_class": "observed",
  "source": "https://www.skyvern.com/docs/introduction + https://api.github.com/repos/Skyvern-AI/skyvern (licence read from repo LICENSE body) + https://www.skyvern.com/docs/sdk-reference/credentials/create-credential",
  "observed": "2026-08-27",
  "name": "Skyvern",
  "category": "browser-automation",
  "claim": "LLM-driven browser automation - a Playwright Page augmented with AI methods (act, extract, validate, prompt) plus an agent task loop. Available self-hosted and as cloud (app.skyvern.com / api.skyvern.com).",
  "tenancy_isolation": "Each cloud run gets its own Chromium instance with a distinct browser_session_id. NO statement about tenant separation, sandboxing or network egress controls in the docs read - isolation is per-session by construction, not documented as a security boundary. Self-hosting is a genuine escape hatch: `skyvern quickstart`/`skyvern init` with PostgreSQL and any LLM provider (OpenAI, Anthropic, Azure, Gemini, Ollama, or OpenAI-compatible), and the docs state the same code runs in both.",
  "approval_model": "NOT OBSERVED - no approval or intervention gate. The nearest feature is live viewing of the session URL to watch the browser in real time, which is OBSERVATION, not intervention. For an agent taking real-world actions in a browser, this is the notable gap.",
  "idempotency_retry": "NO idempotency key. What exists instead is an explicit async run state machine, which is the useful primitive: POST /v1/run/tasks returns a run_id, then poll GET /v1/runs/{run_id}. States observed: created, queued ('waiting for an available browser'), running, completed, and the non-success terminal states failed, terminated, timed_out, canceled. Webhooks are offered as an alternative to polling. Config knobs include MAX_SCRAPING_RETRIES, MAX_STEPS_PER_RUN (default 50) and BROWSER_ACTION_TIMEOUT_MS. A run_id handle plus explicit terminal states is a weaker but real substitute for idempotency: the caller can always re-read authoritative status rather than guess after a timeout.",
  "receipts_audit": "BEST-IN-COHORT RECEIPTS, observed: 'Every run is recorded.' Post-run the Runs dashboard shows a Recording tab, step-by-step actions WITH SCREENSHOTS, and the AI REASONING behind each decision. Self-hosted writes recordings and logs to the working directory (VIDEO_PATH, LOG_LEVEL). Caveat: the docs frame this as a debugging aid, and there is no stated retention period, tamper-evidence, export format or immutability - so it is a rich forensic trail, not a compliance-grade audit log.",
  "limitations": "LICENCE - MATERIAL AND VERIFIED FROM THE LICENSE BODY, NOT A BADGE: Skyvern is AGPL-3.0 (GNU Affero General Public License v3.0), confirmed by reading the LICENSE file at raw.githubusercontent.com/Skyvern-AI/skyvern/main/LICENSE, not by trusting a shield. AGPL's network clause means offering modified Skyvern as a network service triggers source-disclosure obligations - this is a genuine blocker for embedding in a proprietary hosted Actionist product and must be flagged to Cena explicitly. 22,857 stars, actively developed (last push 2026-08-27). Credentials: stored in 'Skyvern's vault' with a vault_type parameter of type CredentialVaultType implying MULTIPLE vault backends exist, though the reference page does not enumerate them; credential_type is required with 'password' (username/password) shown, and the intro mentions TOTP secrets. Referenced by ID in tasks rather than passed inline - good indirection - BUT the docs make NO statement about whether the LLM ever sees plaintext, no encryption-at-rest detail, and no explanation of runtime injection into the browser session. For a browser agent that types credentials into pages, 'does the model see the secret' is the load-bearing unanswered question; record it as unanswered.",
  "disposition": "register"
}

{
  "id": "P11-C-028",
  "evidence_class": "observed",
  "source": "https://hyperbrowser.ai/docs",
  "observed": "2026-08-27",
  "name": "Hyperbrowser",
  "category": "browser-automation",
  "claim": "Hosted cloud-browser infrastructure for AI agents and scraping, plus a separate sandbox compute primitive (volumes, images, snapshots).",
  "tenancy_isolation": "NOT DOCUMENTED. A 'Session Management' page exists (/docs/sessions/lifecycle) but the docs landing page explains no isolation, tenancy or sandboxing boundary.",
  "approval_model": "Not observed.",
  "idempotency_retry": "Not observed. No task lifecycle, idempotency or retry semantics on the pages read.",
  "receipts_audit": "NOT OBSERVED - no session recording, replay, logging or audit trail mentioned anywhere on the docs landing page. This is a clear contrast with Skyvern and Browserbase, both of which lead with recordings.",
  "limitations": "EVIDENCE LIMIT, honest: the fetched page is a docs LANDING page that advertises capability areas without documenting them - four of six target questions (isolation, profiles/credentials, pricing, audit) have NO coverage at all. Where credentials or cookies would live is unstated; the sandbox CLI references volumes and snapshots implying persistent storage exists, but the docs do not connect that to browser credential state - flagged as INFERENCE TO VERIFY, not fact. Stealth and proxy features are confirmed only by page title (/docs/sessions/stealth), with no detail on fingerprinting, residential vs datacenter proxies, geo-targeting or CAPTCHA handling. No pricing anywhere in the docs tree. VERDICT: insufficiently documented to assess for a client deliverable; ranks below Browserbase (P11-C-010) and Skyvern on every dimension P11 cares about. The llms.txt index is the next artefact if this surface is revisited.",
  "disposition": "rejected"
}

{
  "id": "P11-C-029",
  "evidence_class": "observed",
  "source": "https://docs.browser-use.com/cloud/quickstart + https://docs.browser-use.com/cloud/llms.txt",
  "observed": "2026-08-27",
  "name": "Browser Use Cloud",
  "category": "browser-automation",
  "claim": "Hosted arm of the popular Browser Use OSS project: two products - Agents ('give an agent a task and get the result') and Browser Infrastructure (a cloud browser you drive over CDP).",
  "tenancy_isolation": "NOT ADDRESSED as a security boundary. Sessions are described functionally ('continue one conversation across multiple V4 runs') and Workspaces persist files across runs, but whether tenants, profiles or browsers are isolated from one another is not discussed in the docs read. Auth is an API key (bu_ prefix) in the X-Browser-Use-API-Key header.",
  "approval_model": "Not observed. A live preview/recording feature allows watching a run in real time - observation, not intervention. No approval gate.",
  "idempotency_retry": "NO idempotency key and NO enumerated run lifecycle states in the pages read - notably weaker than Skyvern, which at least publishes its state machine. POST /api/v4/runs creates a run addressed by run.id with a wait_for_completion helper; browsers are created via POST /api/v4/browsers and stopped explicitly via PATCH /api/v4/browsers/{id} {'action':'stop'}. OPERATIONAL TRAP worth recording: the docs warn that closing Playwright/Puppeteer or dropping the CDP connection does NOT stop the browser - only the explicit stop does, and that is what 'stops billing and refunds unused browser time'. A crashed client therefore leaks a billed browser.",
  "receipts_audit": "Live preview and recording exist ('watch an API V4 run in real time or record its browser'), plus an Observability surface described as 'poll ordered V4 events to monitor a run or build a custom UI' - ordered events are a genuinely useful receipt primitive. No retention periods, storage location, access controls or audit guarantees are stated. Public share links exist but are marked legacy v2.",
  "limitations": "Secrets handling is the weakest documented area and matters most here: the Secrets page ('pass domain-scoped credentials to the agent securely') and the 1Password/2FA integration ('auto-fill passwords and TOTP codes from 1Password during agent tasks') are BOTH filed under LEGACY (v2), so their applicability to v4 is NOT established by the docs; a separate v4-relevant 2FA page and a Profiles page ('reuse cookies and browser state in API V4 runs') exist. Domain-scoped credentials and 1Password-sourced secrets are the right patterns - the concern is that they appear to be trailing the v4 migration. No statement on how secrets are stored, encrypted, retained or redacted. No pricing figures in docs (a separate pricing doc covers credits, browser/proxy rates and model token prices). V4 is positioned for 'hard, high-accuracy tasks' with V2 cheaper but 'substantially lower' accuracy. The v4 OpenAPI spec (docs.browser-use.com/cloud/openapi/v4.json) is the artefact that would settle lifecycle states and idempotency definitively.",
  "disposition": "register"
}

{
  "id": "P11-C-030",
  "evidence_class": "observed",
  "source": "https://developer.hashicorp.com/hcp/docs/vault-dedicated",
  "observed": "2026-08-27",
  "name": "HCP Vault Dedicated",
  "category": "credentials",
  "claim": "HashiCorp-operated hosted Vault Enterprise. Included specifically to test whether the lease/dynamic-secret invariant that made P11-C-014 valuable survives in the managed form - it does.",
  "tenancy_isolation": "GENUINELY SINGLE-TENANT, documented: 'HashiCorp manages the cloud provider you select in an account dedicated to your organization.' Runs on AWS or Azure across North America, Asia and Europe. This is a materially stronger isolation posture than the multi-tenant default of the unified-API cohort (cf. Merge, whose default is three shared AWS regions with single-tenant as a paid add-on).",
  "approval_model": "Control Groups and Sentinel are documented as available at the HCP Vault Dedicated Standard tier - Control Groups being Vault's native request-authorisation gate requiring additional approvers before a secret is released. This is the one credential-layer product in the survey with a real, native, per-request human approval primitive.",
  "idempotency_retry": "Not applicable in the request-dedupe sense. The relevant invariant is the LEASE: every dynamic secret carries a lease with a TTL and is revocable, so the safety property is time-bounded automatic expiry rather than replay suppression. Customers explicitly own 'the logical lifecycle of data stored in Vault' including tokens, leases, KV secret versions and unused secrets.",
  "receipts_audit": "Audit devices are a customer responsibility under the shared-responsibility model - customers handle monitoring via metrics and audit logs; HashiCorp handles infrastructure monitoring, cluster health, storage, backups/snapshots, upgrades, HA operations and platform recovery.",
  "limitations": "PARITY IS NEAR-COMPLETE BUT NOT TOTAL - the exceptions are exactly the high-assurance features: entropy augmentation, FIPS 140-2 and seal wrap, and HSM auto-unseal are UNAVAILABLE on Dedicated (auto-unseal is instead a HashiCorp-managed per-cluster KMS key). Azure clusters additionally lack the Oracle Database secrets plugin and the KMIP secrets engine (both listed as planned). Workload identity federation requires a cluster with a public interface. Other deltas: storage is fixed to Integrated Storage; super-user access grants a 6-hour `admin` token rather than a `root` token; the top-level namespace is `admin` not `root`. Lease/dynamic-secret parity is INFERRED rather than explicitly guaranteed - the doc's basis is the binary-parity claim that Dedicated 'uses the same binary as self-hosted Vault Enterprise' with the same CLI, API and UI, plus leases being listed as a customer-managed concern; the page makes no direct statement about dynamic secrets. Mark as strong inference, not observed guarantee. The page does not mention HCP Vault Secrets (the multi-tenant offering) at all, so no dedicated-vs-multi-tenant comparison could be drawn from it.",
  "disposition": "register"
}

{
  "id": "P11-C-031",
  "evidence_class": "observed",
  "source": "https://www.truto.one/ (trust center https://trust.truto.one not fetched; no developer docs linked from the site)",
  "observed": "2026-08-27",
  "name": "Truto",
  "category": "unified-api",
  "claim": "Unified API positioned for SaaS products AND AI agents; claims 700+ integrations across 50+ categories, declarative config-driven connectors ('connectors as data, not code'), launched 2023.",
  "tenancy_isolation": "NOT DOCUMENTED. No detail on OAuth token storage, encryption, per-tenant key separation or credential rotation. The available claims concern PAYLOAD data, not secrets: Truto 'doesn't store your customer's data on its platform' and data flows 'directly from source to you'. As with Hotglue, do not read a no-data-retention claim as a credential-custody claim. A CASA Tier 2 verification for their Google OAuth app (Gmail, Calendar, Drive) is noted.",
  "approval_model": "Not observed as a per-action gate. RapidForm provides end-user forms letting customers 'choose exactly what to sync' - a connect-time scoping feature, not an approval queue.",
  "idempotency_retry": "NOT OBSERVED - no idempotency keys, no dedupe guarantees. The only adjacent feature is RapidBridge, 'intelligent rate-limit handling and data sync to your database', with no documented backoff strategy or retry semantics. Architecturally notable: Truto proxies in real time rather than caching ('Truto makes the API call to the underlying API as you make it. No stale caches'), which means it inherits each upstream API's retry behaviour directly and adds no dedupe layer of its own.",
  "receipts_audit": "NOT OBSERVED. SOC 2 Type II, ISO 27001, GDPR, HIPAA and CCPA are listed as compliance badges; those frameworks imply internal logging but NO customer-facing audit trail is described.",
  "limitations": "Two features are genuinely interesting for Actionist and worth noting despite thin evidence: (1) MCP servers can be generated from any integration 'with one API call', SCOPED BY METHOD, TAG AND TIME-TO-LIVE - a TTL-scoped generated MCP server is a real capability-narrowing primitive and the only TTL-bounded tool exposure seen in this survey; (2) unified models are fully customisable via JSONata, covering field mappings rather than only custom-field passthrough. Self-hosting is offered ('Cloud or on-prem', claimed setup 'within an hour') with no architecture, requirements or version-parity detail. NO PRICING disclosed. EVIDENCE LIMIT, honest: this is marketing copy, not technical documentation - no developer docs are linked from the site at all, which is itself a signal. Compliance badges are vendor claims, not inspected reports. Competitive context observed: customers described as migrating from Merge, Codat, Carbon, Apideck and Ampersand, with Sprinto and BalkanID reportedly running Truto alongside Merge. Next artefacts: trust.truto.one and the security blog post at /blog/security-at-truto.",
  "disposition": "register"
}

{
  "id": "P11-C-032",
  "evidence_class": "observed",
  "source": "https://www.vessel.dev/ (200) + https://docs.vessel.dev returns HTTP 404 + https://app.vessel.dev fails TLS (curl exit, http=000) though DNS resolves to cname.vercel-dns.com",
  "observed": "2026-08-27",
  "name": "Vessel",
  "category": "unified-api",
  "claim": "Developer-first native integration platform with unified APIs across CRM, Sales Engagement, Chat, Marketing Automation and Dialer, plus an Action API of prebuilt actions and managed data pipelines.",
  "tenancy_isolation": "Not documented. 'Drop-in authentication' is advertised with no description of how tokens or secrets are stored, rotated or encrypted. Generic claim only: data 'encrypted in transit and at rest using industry-standard encryption protocols'. No multi-tenant isolation architecture described; nearest signals are 'fine-grained permissions', selective sync and white-labeling.",
  "approval_model": "Not observed.",
  "idempotency_retry": "NOT OBSERVED. 'Standardized error handling' and 'Rate limit Retries' are advertised, but retries are NOT idempotency guarantees and no dedupe contract is described. Notable given the product ships an Action API - prebuilt write actions - which is precisely where an idempotency contract would matter.",
  "receipts_audit": "Not observed. SOC 2 is claimed; no audit-log, change-history or event-trail feature is named.",
  "limitations": "PRODUCT APPEARS ABANDONED - verified from source on 2026-08-27, not inferred from vibes: docs.vessel.dev returns HTTP 404, and app.vessel.dev RESOLVES (cname.vercel-dns.com -> 66.33.60.67/76.76.21.98) but FAILS TLS NEGOTIATION entirely (curl returns http=000 with a certificate error) - i.e. the application host is misconfigured or expired, not merely empty. The marketing site still returns 200 but carries dead anchor (#) footer links including 'Docs', four product links all resolving to the same generic docs root, and 2023-dated asset filenames. Copyright is attributed to 'Kinit Inc.', not Vessel, suggesting a parent or renamed entity. RECOMMENDATION: exclude from any Actionist build-vs-buy comparison and do NOT present to Cena as a live option. Recorded here so the surface is closed with evidence rather than left as an unexamined gap - a competitor's dead product is useful signal about the unified-API category's consolidation.",
  "disposition": "rejected"
}