Arbis

If third-party validation and mature security documentation are required immediately

• Arbis appears to be in an early commercial stage with limited public reviews and no publicly documented SOC 2/ISO attestations. Organizations that require immediate SOC 2 Type II and mature vendor security documentation may prefer more established vendors.

If the primary need is prevention of prompt injection or data leakage rather than audit evidence

• Vendors focused on guardrails and security filtering (e.g., Lakera Guard, Aporia Guardrails) may deliver faster operational value for preventing prompt attacks and data loss.

If strict pre-execution, capability-based control at the tool boundary is required

• Organizations that require guaranteed pre-execution blocking of disallowed tool calls should validate whether enforcement is implemented pre-execution or is primarily post-execution verification and escalation. Runtime-enforcement-first products may be better suited in those cases.

If storing reasoning traces is not acceptable

• Organizations that prohibit storing model reasoning traces or that have policy against storing chain-of-thought should validate exactly what the product captures and stores prior to adoption.

Current limitations indicated by the vendor

• Vendor material describes a staged go-to-market with design partners and early access, implying that feature completeness, documentation depth, and platform maturity may still be evolving.

Publicly visible limitations/gaps (from accessible information)

• No published pricing
• No publicly documented SOC 2 / ISO 27001 attestations
• No publicly available customer case studies with independently verifiable metrics
• Limited public developer documentation surfaced in the sources reviewed beyond marketing content

Roadmap uncertainty

• Statements that the product "works with multiple enterprise AI platforms" should be treated as vendor positioning until validated with reference integrations and production deployments.

Vendor-stated differentiators (require validation):

• Per-decision capture and verification (vendor states captures are not sampled)
• Multi-agent call-chain lineage
• Versioned, executable policy artifacts intended to support audit needs
• Reporting functions mapped to regulatory frameworks such as the EU AI Act and COSO ICIF
• Cryptographic verification option for individual decisions (offered in design partner tier)

Important skepticism / validation notes

• Claims of tamper verification and cryptographic proof vary in technical approach and rigor. Independent protocol efforts and standards work highlight challenges including coverage denominators and the need for independent verification. Buyers should confirm whether captured evidence can be independently verified, what trust assumptions remain, and how the vendor protects integrity of records.

• The product is early and not broadly deployed
• Deployments are private or in regulated environments where references are not public
• The product has not yet achieved significant market penetration

• Named reference calls (ideally in similar regulated verticals)
• Documentation of how reasoning trace capture works and how it aligns with regulatory frameworks
• Evidence of incident response and audit workflows under real-world conditions

• The raw event capture format
• Policy versions applied during the capture
• The evidence chain and any tamper-verification mechanism
• Replayability and independent verification claims

• Changes in audit preparation time
• Reduction in policy violations or time to detect violations
• Mean time to detect and resolve agent incidents

• Per-decision capture of AI decisions with contextual data (vendor states this is not sampled)
• Real-time policy evaluation for each decision
• Multi-agent call-chain tracing
• Verification logs that the vendor describes as tamper-evident and an optional cryptographic verification mechanism for individual decisions (design partner tier)
• Reporting functions aligned to frameworks such as the EU AI Act and COSO ICIF