Tenant Isolation
Customer-level separation across application data, workflows and integration access.
Security and trust
AI execution with security at every layer.
Bexara AI is designed around controlled access, protected data handling, governed model execution and visibility into operational activity. Authorization and critical business rules are enforced in the execution layer — not only through instructions to a model.
Controls in action
Follow a document through the control path.
Switch to “Unauthorized action” to see an instruction embedded in a document get blocked by execution policy — and a review event created instead.
Endorsement_0518.pdfTenant: Agency A · arriving via carrier portal
Simulation- Customer boundary—Waiting
- Identity & permissions—Waiting
- Processing environment—Waiting
- Scoped agent—Waiting
- Validation controls—Waiting
- Execution policy—Waiting
- Audit trail—Waiting
Agent scope for this workflow
Data
- This document
- Account NW-20418 policies
Tools
- Extract fields
- Attach to AMS account
Not permitted
- Other tenants' data
- Send external email
- Edit policy records without approval
Audit trail
- Events appear as the document moves through each control.
Ready
Security capabilities
Security as architecture, not an afterthought.
Identity and Access
Authentication, role-based permissions and least-privilege access, with enterprise identity integration where implemented.
Encryption and Key Management
Defined encryption requirements for data in transit and at rest, with key-management controls appropriate to each deployment.
Credential Protection
Carrier portal, AMS and API credentials held in secrets management — never placed in prompts, logs or analytics.
Controlled Agent Execution
Each agent is restricted to authorized tools, data sources and operations. Configured sensitive actions require approval.
Auditability
Records of workflow execution, access, administrative changes, exceptions and relevant actions.
Data Residency and Retention
Where data is stored and processed, how long it is kept and how deletion works — documented for each deployment.
Model Governance
Which models are used, whether external providers process customer data and what is transmitted — disclosed, not assumed.
AI-specific risks
How the platform is designed to address AI risks.
Language models can be wrong, and documents can contain hostile content. The platform is designed so that neither leads to an unauthorized action.
| Risk | Design approach |
|---|---|
| Prompt injection through documents or web pages | Document and page content is treated as data. Instructions found in content cannot grant tools or permissions; allowed actions are defined per workflow in the execution layer. |
| Unauthorized tool execution | Each agent has an explicit allowlist of tools and operations. Calls outside that list are rejected by the execution layer and recorded. |
| Data leakage across tenants | Data, workflows, credentials and integration access are scoped to the tenant. Agents receive only the data for the task at hand. |
| Sensitive information exposure | Access is role-based and least-privilege. Sensitive fields can be restricted from views, exports and external model calls by configuration. |
| Incorrect model output | Outputs are validated against required fields, configured rules and cross-source consistency before any action is taken. |
| Low-confidence extraction | Results below configured confidence thresholds are routed to review instead of proceeding. |
| Conflicting policy information | Conflicts between sources are surfaced with evidence and routed for review rather than resolved silently. |
| Unauthorized downstream updates | Writes to agency systems require a validated result and, for configured sensitive actions, human approval. Policy is enforced in code. |
| Sensitive information in execution logs | Credentials are never logged. Logging policies redact configured sensitive fields; logs are access-controlled. |
Core principle
Models propose; the execution layer decides. Permissions, tool access, approval requirements and critical business rules are enforced in code, so a model output — or text inside a document — cannot expand what a workflow is allowed to do.
Trust Center
Documentation you can review.
We share security documentation with customers and prospects as part of evaluation. We don't publish claims we can't document.
Architecture & data flow
Diagrams of components, trust boundaries and how documents move through each deployment model.
Deployment documentation
What runs where for managed cloud, private cloud and on-premises, including external connections.
Access control
Authentication, roles, permissions, administrative access and support access procedures.
Data processing & retention
Where data is stored and processed, retention periods and how deletion is handled.
Model governance
Models in use, whether external providers process customer data, what is transmitted and under what terms.
Incident response
How security incidents are detected, escalated, contained and communicated to customers.
Business continuity
Backup, recovery and continuity arrangements for each deployment model.
Certifications & assessments
Independent certifications and assessments, listed only once they are complete and verifiable.
Certifications. This site does not claim any security certification or compliance attestation. When an independent certification or assessment is completed, it will be listed here with its scope and date.
Customer data and model training. How customer data may be used — including any use for model training — is defined in your agreement and in our model provider terms. We will publish a public commitment only when architecture, contracts and operating policies all support it.
See How Bexara Fits Your Agency.
Explore connected insurance workflows, flexible deployment, and AI-assisted operations with human oversight.
Each demonstration is shaped around your agency's workflows, systems and security requirements.